SiliconForgeExamples / Questions worth testing
RTL examples and verification walkthroughs
Run a self-contained ready/valid example, then explore two retained engineering case studies. Each asks a specific question about behavior, source changes and the evidence needed for a decision.
Runnable first project ↓ · Telemetry stream ↓ · Packet storage ↓ · Evidence checklist ↓
Start here / Reproducible source
Simulate a stream register
The first-project guide includes the Verilog source, testbench, Icarus commands and expected output. Download the same two source files or copy them from the guide. Run the check and inspect the VCD in native Verify. No proprietary source or AI request is required for this simulator exercise.
- Inputs
stream_register.sv,tb.svand Icarus Verilog withvvp.- Expected result
PASS: reset and stalled transfer, plusstream.vcd.- Check the checker
- Break reset deliberately; expect
reset did not clear validand a nonzero exit. - Scope
- One directed reset/stall test—not exhaustive traffic, formal proof or production-qualified IP.
Download the first-project ZIP · SHA-256 checksum · Install and get started
The telemetry and packet-storage sections below explain retained engineering cases. They are case studies, not a claim that their complete source and evidence bundles ship with the application.
01 / Measurement processing
What happens when the consumer stalls?
The telemetry case is a single-clock digital-IP prototype: accept signed samples, apply calibration, buffer temporary downstream stalls and expose configuration and status. The engineering question is whether the complete path preserves accepted measurements under the specified workload.
1. Establish the interface contract
Before changing the design, identify which clock edge accepts an input and which emits an output. The producer must honor ready/valid backpressure. Reset discards the queued epoch; a reset-discarded sample must not be counted as unexplained data loss.
2. Trace the source-grounded path
- In Architecture, follow
sample_processing→buffering→ output. - Inspect calibration: signed 17-bit addition is followed by signed 16-bit saturation. Calibration occurs before enqueue, so later register writes must not change already accepted values.
- Inspect the fixed 32-entry queue. Output must remain the oldest accepted sample during a stall; simultaneous pop/push at full capacity is a separate boundary case.
- Inspect
control_statusand counters. APB exposes configuration and occupancy; counters represent accepted/emitted handshakes, not attempted transfers. Disabling input preserves queued output.
3. Challenge the capacity assumption
At one offered sample every four cycles, a 96-cycle consumer blackout creates demand for 24 additional entries. Whether a 32-entry buffer is enough still depends on initial occupancy and service after the blackout. Do not extrapolate that one scenario to arbitrarily long stalls.
Run the matching testbench against the exact source and inspect accepted inputs, emitted outputs, occupancy, saturation and reset. Use available waveform artifacts to follow the handshake cycle by cycle.
4. Decide what the evidence permits
The retained engineering review reports ordering, saturation, stalls, occupancy, configuration-change and reset checks for this fixed configuration. That is a bounded engineering result—not a qualification of every parameter value or target device.
Known limitations you should keep in the review
- The assessed queue depth is 32. Occupancy uses a six-bit field; changing the declared depth alone does not establish correct parameterization.
- Generic synthesis does not establish block-RAM inference, FPGA resource usage, frequency or timing closure.
- No physical sensor interface or clock-domain crossing is established by this case.
- Register defaults, watermark truncation/clamping, counter wrap and interrupt service need an explicit integration contract before reuse.
A useful next task: specify a supported capacity range, repair width-dependent behavior in a new candidate and rerun boundary tests across that range. Do not reuse the original fixed-depth evidence as proof of the modified design.
Read simulation and waveform results → · Navigate the design →
02 / Reconstruction in context
Review a packet-storage replacement
The packet case reconstructs a missing frame-storage implementation while retaining the surrounding packet-protection application. The replacement is evaluated by externally observable behavior—not textual resemblance to the original.
1. Separate the three snapshots
The comparison uses original, removed and replacement snapshots. The removed version establishes the missing implementation boundary; it is not a second working reference. Source identities distinguish snapshots from a timeline of unrelated AI attempts.
2. Review the storage interface in context
- Open the supplied design comparison using the Design toolbar's comparison importer, or review the corresponding retained revisions in Changes.
- Inspect the storage block and its connected producer, decision logic and consumer in Architecture. Compare original-only and replacement views when an overlay becomes ambiguous.
- Follow completion and output control into RTL/source. Changed internal names do not automatically imply changed application behavior.
- Inspect the associated application evidence and waveform, including its source binding. An imported comparison is inspection material; it does not authorize applying a candidate.
3. Investigate a contract disagreement
A reference can disagree with the requirement
The recorded reconstruction exposed a difference in frame_done: the written contract requested a one-cycle pulse, while the reference could hold it waiting for a decision. A visually similar implementation could preserve the wrong contract; a different implementation could satisfy the intended one.
Use a delayed-decision waveform to observe the completion signal and connected consumer. Record whether the mismatch lies in the written requirement, reference or replacement. Resolve that question before declaring equivalence or changing the acceptance test.
4. Exercise the whole application
Challenge accepted and rejected packets, downstream stalls, delayed decisions, reset and capacity boundaries. Read the declared workload and formal assumptions. Match source, tool configuration and stimulus when comparing the original and replacement.
5. Keep the result bounded
The retained reconstruction documents application checks for the original and replacement, alongside scoped formal safety and generic synthesis. CRC, policy and leakage checks under declared workloads are not an unbounded proof over every possible frame. This case does not establish device timing closure or universal sequential equivalence.
A useful next task: add an independent delayed-decision regression for the agreed completion contract, demonstrate that it distinguishes the disputed behaviors, then review any repair as a new candidate.
Compare revisions and staged proposals → · Apply or reject a reviewed candidate →
What to keep with any example
| Record | Question it answers |
|---|---|
| Source and configuration identity | Which design, top, parameters and defines were checked? |
| Requirement and testbench | What behavior was required and which scenarios were exercised? |
| Tool command, version and output | What actually ran, and what did it report? |
| Logs, traces and failure cases | Can the result be investigated rather than merely summarized? |
| Known limitations | What remains untested, unsupported or dependent on integration assumptions? |
These walkthroughs describe retained engineering cases. They do not grant third-party IP rights or imply that every referenced project/evidence bundle ships with the application. For your own design, reproduce the relevant steps with source and tests you are authorized to use.