SiliconForgeEstablish the baseline
Run the relevant check against the original source. If the baseline already fails, label that failure rather than attributing it to the new candidate.
Workflow / A deliberate RTL revision
Investigate a failure and review the proposed fix
A downstream stall exposes a handshake problem. You need to understand the source, make a bounded repair and hand over evidence another engineer can follow. Here is the workflow.
Understand · Plan · Execute · Review
Before you start
Install a compatible application build, open the project and configure the engineering tools needed for your checks. If you will use AI, configure a supported route and review its data boundary first. Keep a known baseline and preserve unrelated edits.
01 / Ask
First, understand the behavior.
State interfaces, clocks, reset, allowed traffic, capacity, error handling and observable results. For an existing design, begin with a read-only explanation and check the cited implementation.
Explain the ready/valid path from input to output.
Identify where a sample is accepted, transformed and buffered.
Cite the source locations. Do not modify files.
List assumptions and anything you cannot establish.Expected result: a source-grounded explanation you can challenge. Check attached context before sending; do not assume the provider needs the entire repository or unrelated private files.
If the answer conflicts with the source: investigate the mismatch before requesting a repair. A confident explanation is not a test result.
02 / Plan & approve
Agree on the repair and its test.
Ask for a bounded change and a plan covering affected source, interface compatibility and verification. Resolve disagreements between a requirement and the existing implementation before approving execution.
Plan a repair for the demonstrated stall-handling failure.
Preserve the top-level interface and reset contract.
Identify affected files and the smallest reproducible failing test.
Include sustained stalls, simultaneous input/output and reset.
Do not implement until I approve the plan.- Scope: is every proposed file change necessary for the requirement?
- Compatibility: do connected producers and consumers still agree on the interface?
- Checks: which test fails before the change, and what would establish the intended fix?
- Limits: which properties, tools or environments will remain untested?
Expected result: an explicit plan you can approve, revise or reject. A plan approval is not final approval to apply its eventual candidate.
03 / Execute
Run the candidate against the baseline.
After approval, execution works on an isolated candidate. Read the actual tool command, input revision, configuration, exit status and artifacts—not just the assistant's summary.
Inspect the candidate
Run matched checks on the candidate. Examine failed assertions and waveforms; confirm that the stimulus exercises the intended boundary.
Keep missing checks visible
An unavailable tool or interrupted run is not a pass. Fix setup or retain the limitation. Never disable a safety check to make a run look successful.
stream_register example: an actual Icarus trace from the first-project guide, opened in native Verify. It illustrates evidence inspection, not the result of the hypothetical repair above.If execution is interrupted: preserve the candidate and recorded outputs. Inspect their state before continuing; do not assume partial work was applied or verified. See recovery and safe diagnostics.
04 / Review
Review the exact change before applying it.
- Open Changes or the candidate handoff. Confirm baseline, candidate and source identifiers.
- Review file changes, module interfaces, connections and internal logic. Compare before and after separately when an overlay is ambiguous.
- Read verification evidence for that candidate. Check missing, unsupported and failed results alongside passes.
- Resolve stale-source warnings. If the project changed since approval, refresh and review again rather than overwriting newer edits.
- Apply explicitly only when the evidence is sufficient for your purpose; otherwise reject or request another bounded revision.
- Inspect the resulting project and post-apply checks. Commit the intended source changes separately when ready.
Expected result: a deliberate apply/reject decision tied to the reviewed source. A Git commit, a local checkpoint and a candidate approval are distinct records; none substitutes for the others.
Version-control and candidate-review guide → · Read tool results →
Two larger engineering questions
These retained case studies extend the review questions; they are not downloadable projects. Start with the reproducible stream-register exercise if you want to follow along now.
Telemetry under downstream stalls
Trace accepted samples through calibration and a fixed-depth buffer. Check ordering, saturation, backpressure and reset accounting before proposing a capacity change.
Follow the telemetry walkthrough →A packet-storage replacement
Compare a replacement with its surrounding application. Inspect the completion contract under a delayed decision instead of using source similarity as an acceptance test.
Follow the packet walkthrough →Try the workflow with a small project
Keep requirements, source identity and evidence together so you—or the next engineer—can pick up the work with confidence. Production qualification remains a separate engineering responsibility.
Run the complete first-project guide →