Telemetry and packet walkthroughs

Applies to SiliconForge 0.1.2 · Updated 2026-09-30. Check platform limits.

Before this task: Run the small source-complete example →

Use two different application contracts to learn how to inspect architecture, ask useful questions and judge evidence. These are engineering case studies—not claims of autonomous full-chip design.

Choose the right example#

For a fully self-contained beginner project, use the two source files in your first RTL project. The telemetry and packet designs below are retained product case studies, not promised downloadable or bundled IP. Their contracts and review decisions are explained here so you can understand the evidence shown on Examples.

To run an application profile yourself, you must already have a candidate implementing that exact interface/contract and the required qualified platform-specific tools. A visual fixture or a similarly named module is not automatically a compatible candidate. No private cache, provider request or source-repository access is required for the self-contained first project.

Telemetry: from accepted sample to delivered result#

1. For a compatible telemetry project, open its native source root and locate the telemetry_stream top. Otherwise follow the retained case-study views rather than pretending the source is installed.
2. Use Architecture to locate processing, buffering and control/status responsibilities. Use RTL Hierarchy and Connections to follow the sample path and confirm its endpoints in source.
3. Compare the contract below with the source and the profile's returned requirements. Its candidate top is telemetry_stream; matching names alone do not imply matching behavior.
4. For a compatible candidate, select Verify → Application profile → Telemetry · application checks, then Run application checks when the required runtime is available.
5. Compare expected and observed results, source/contract bindings and retained traces. Read the limitations before calling the design accepted.

The application contract defines signed 16-bit saturating calibration, a 32-sample lossless FIFO, ready/valid transfer, APB control/status and watermark interrupt behavior. Reset is synchronous active-low. Ask what happens when the consumer stalls, calibration changes while samples are queued, the queue becomes full, or reset discards queued samples.

Worked review: hold output not-ready and feed 32 accepted samples. Confirm ordering, capacity and stable stalled output; then resume the consumer and distinguish unloaded latency from latency caused by queuing. A generic synthesis-cell ceiling is an implementation comparison, not a target LUT or timing guarantee.

Packet filter: do not emit before validation#

1. For a compatible packet project, identify buffering, validation, filtering and counters in the source-backed Architecture view. A retained screenshot alone cannot establish its behavior.
2. Inspect the application profile's contract and expected interface before running it. The candidate top is sf_packet_filter.
3. Establish frame boundaries and acceptance rules before reviewing a change. The contract uses byte-wide AXI-Stream, s_axis_tlast for frame termination, and synchronous active-high reset.
4. With a compatible candidate and qualified runtime, select Packet · application checks and inspect its requirement-level results and evidence.

The contract accepts frames of 8–1024 total bytes, including four CRC bytes, when the optional first-payload-byte filter and CRC checks pass. CRC is CRC-32/ISO-HDLC with little-endian wire CRC bytes. No output byte is allowed before the complete frame has been checked. The exact register interface and counters are specified in the contract, not inferred from the diagram.

Worked review: compare a valid frame, a bad-CRC frame and a valid frame with downstream stalls. Check whether any byte escaped before validation, accepted bytes stayed ordered, and rejection/cause counters matched the event. Preserve the first counterexample rather than weakening the filter rule.

When a case study does not replay#

A missing qualified runtime is a blocker for application acceptance, not a reason to invent a green receipt. A contract/port mismatch requires the intended candidate, not editing the independent oracle to fit arbitrary RTL. Record candidate, contract, checker and tool identities. Keep visual inspection results distinct from simulation/formal evidence and from any AI-generated candidate provenance.

Related: product case studies, source-backed navigation, application evidence, counterexample traces.

Need help? Report an issue. Include your application version; never include credentials.