SiliconForgeReview hardware differences
Applies to SiliconForge 0.1.2 · Updated . Check platform limits.
Before this task: Choose the exact revisions to compare →
Review source, structure and evidence together. A diagram highlights where to investigate; it does not establish that a candidate is correct.
Bind the comparison first
Open a Git revision, a checkpoint pair, a working layer or a proposal's Review. Read the baseline and target identities. For working changes, verify whether the comparison is HEAD-to-index, index-to-files or a selected commit-to-files comparison.
A retained comparison is immutable evidence about its named inputs. It is not automatically evidence about later editor changes. If a historical view fails to load, an unavailable message is the result; do not use the last visible diagram as a substitute.
Worked flow: review a changed enable condition
Consider a candidate that changes if (enable) to if (!enable) while leaving the module's ports unchanged.
- Select the affected change row and module scope. Check the row's category and detail instead of relying only on its title.
- Inspect Architecture for changed module boundaries and connections. An unchanged interface is expected here and does not clear the behavior change.
- Open RTL and select the exact retained target for the side you want to inspect. Look at the affected control cone; a missing counterpart must remain unmatched.
- Open Properties and inspect Meaning and Logic details where available. Compare guards, assignments, widths and parameters with the source.
- Choose the affected file in Historical source file. Read the before and after source rather than the working editor buffer.
- Review relevant simulation or formal evidence for both enable values, reset and boundary cycles. Missing tests remain missing evidence even if the diagram is readable.
The expected outcome is an identified polarity change and an explicit decision about its intended behavior, not a claim that a green object passed verification.
Turn inspection into an engineering decision
In Notes, write a concrete observation and an open question before you leave the affected row. For the enable-polarity example:
Observed: the retained target changes enable to !enable in the
selected file/module. Ports are unchanged.
Need: confirm which polarity the requirement intends; exercise both
values at reset release and during a transfer.
Decision: not yet accepted; the source change is understood but the
required behavior/evidence still needs review.Save the note using Save review note. Record the actual baseline/target and comparison identity with it when handing off; do not paste invented identifiers from a tutorial. A useful completed review states which changed behavior is intended, what current checks support it, and what remains unknown. “Viewed” only records that the row was visited.
If an Architecture pane is unchanged while an RTL guard changed, that is not contradictory: module connectivity and internal behavior answer different questions. If matching is uncertain or a graph is empty, inspect the retained source and diagnostics rather than approving an absent drawing. Watch a real revision comparison for the relationship between change rows, source and circuit views.
Interpret matching and overlays conservatively
The comparison legend distinguishes shared, modified, before-only, after-only and uncertain matches. A rename or structural rewrite can change object identity. Before-only and after-only objects describe the match result, not a proof that one circuit is faulty or that a feature was added.
Overlay displays both alternatives in one view. Switch to separate sides when wires overlap or the correspondence is unclear. A question mark means matching is uncertain. Inspect the side-labelled targets and retained source; never treat a nearby object as the missing counterpart.
“No classified hardware differences” means no differences were classified within the available representation. It does not establish functional equivalence. Unsupported logic may be reported as changed without a detailed interpretation. Constraints, verification settings and build configuration can matter even when the circuit drawing is unchanged.
Keep source and selection aligned
Use module/category filters and the visible-object search to reduce the view. Search only searches objects represented in the current view, not every signal in the entire repository. Selecting a historical source location or exact endpoint should preserve its revision side and path.
Copy ID copies selected hardware object identifiers, or the selected change identifier when no object is selected. Include the comparison identity and file path with that ID in an engineering discussion; an isolated human-readable label can be ambiguous.
Record observations without granting approval
Use Notes and Save review note to retain a local observation for the selected change, such as “verify enable polarity at reset release.” Notes and viewed-state markers are not approvals.
Check that evidence belongs to the exact revision and uses the intended tool, top, configuration and inputs. Waveform comparisons require compatible signals and time windows; unknown values, missing traces or different conditions are not passes. Formal results are limited by their assumptions. Synthesis evidence is not timing sign-off.
Decide what to do next
For a local proposal, return to its controls to validate, apply or reject through candidate review. Imported comparisons are inspectable but do not grant authority to modify a project. For committed or checkpointed history, prepare a separate intentional edit if you want to change the working design.
Need help? Report an issue. Include your application version; never include credentials.