Your first RTL project

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

Before this task: Install and verify the application →

Open real SystemVerilog, understand one path through it, then review one bounded change. You do not need to ask a model to invent an entire chip.

What you will finish: a local two-file RTL project, a passing directed test, and a deliberate failing test that proves the checker is active. Source navigation and this simulator exercise need no AI request. The later Ask and Plan steps are optional.

New to the application? Use the start checklist to choose and verify your installer, then return to this exercise.

Want to see the interface before starting? Watch the native review and verification walkthrough, then return here for the complete runnable source.

Install, activate, then make your own copy#

Install the supported application and launch it from the Windows Start menu or open AppRun from your extracted Linux application folder. At the welcome screen choose Subscription… to activate or inspect your paid access before creating a project. No AI account is needed for this exercise. New engineering work requires a paid subscription; see activation and offline access. Keep projects outside the application installation directory.

Choose a safe starting copy#

The easiest route is Try an example… in the application. It creates your own copy without overwriting an existing project. You can also download the first-project ZIP and its SHA-256 checksum, compare the complete hash, then extract into a new user-owned folder. The source is published below for inspection. The example is provided under the existing SiliconForge product license, and does not grant a free-use or open-source entitlement. The ZIP does not contain the telemetry or packet-filter case-study projects.

1. Create or open the project in the application#

1. In the welcome screen choose Try an example…. Give the project a name and choose a user-owned parent folder, then select Create and open. To open an extracted ZIP or your own source instead, choose Open project… and select the folder containing the RTL files, not an empty outer folder.
2. For an empty starting folder choose Create project…. In an existing workbench use ＋ Project or Open another project… to return to the project choices.
3. Wait for the reported core startup and indexing stages. Read any error before relying on a partial diagram; retry after correcting the cause. A window opening is not proof that indexing or checks finished.
4. In Project → Files open stream_register.sv and tb.sv. Confirm the project location in Settings → Projects & files. Keep stream_register as the design top and tb as the simulation top.

Expected result: your own two-file source project is open in the native application. The testbench has a dut instance; it is not the synthesizable design top. Nothing has been uploaded to an AI provider.

2. Run the first check without a terminal#

Checks need a recorded source baseline. In the check-configuration dialog, use Create initial project history only for a new project whose source you have inspected, and provide your own author name and email when requested. This records the initial source explicitly; it does not silently stage an existing project or publish it anywhere. Existing repositories keep their own history. See the Git workflow before changing a shared project.

Open the application menu and choose Configure checks…. Set RTL files to stream_register.sv, Design top to stream_register, Testbench files to tb.sv and Testbench top to tb. Review the detected engineering tools, then choose Save check configuration. See the verification setup guide; a missing-tool diagnostic means the run is not yet qualified, not that the source passed.

1. Open the source in Project → Files and save with Ctrl+S before checking it.
2. Choose Run checks, wait for completion and inspect the individual results and diagnostics. A queued or cancelled run is not a pass.
3. The original simulation should report PASS: reset and stalled transfer. Open the run's waveform artifact to inspect stream.vcd, including clock, reset, valid, ready and data.
4. Confirm the result belongs to the saved source you just checked. A previously green result must not stand in for a new edit.

3. Inspect one data path#

1. Use Architecture for major blocks and interfaces. Select a block to inspect its source and instance identity.
2. Switch to RTL Hierarchy for containment; use Connections for exact module wiring. Two instances of the same module remain distinct instances.
3. Follow one input through the design. Identify its clock/reset, the condition under which data is accepted, where it is buffered, and the condition under which output is consumed.
4. Open linked source and confirm the relationship. A picture is a navigation aid, not proof of behavior or physical implementation.

In this example the useful object is stream_register, with clk, rst and the input/output handshake signals. The testbench may also appear among indexed modules. There is no multi-block application architecture to discover in this tiny design; the interesting behavior is the enable condition and stored output. Confirm those in source rather than expecting the telemetry diagram shown elsewhere on the website.

4. Save a change and prove the checker catches it#

1. Make a separate copy of stream-demo and work only in that disposable copy. Keep the passing original unchanged.
2. In the reset branch of stream_register.sv, change out_valid <= 1'b0; to out_valid <= 1'b1;. Leave the testbench unchanged.
3. Save the edited source with Ctrl+S, then choose Run checks again. Inspect this new run, not a stale result from before the edit.
4. Expect compilation to succeed but simulation to fail with reset did not clear valid and a nonzero exit status. A valid output immediately after reset violates this example's contract.
5. Restore the original reset assignment, save with Ctrl+S, run Run checks again and confirm the PASS marker returns. Keep the failing diagnostic with your learning notes; it explains what the test actually detects.

If the broken design still passes, check the current directory, input filenames and whether you ran stale output. Do not weaken the assertion. Continue with the longer traffic-and-reset exercise when this loop is understood.

5. Optional: ask a read-only question#

Configure the route in AI settings, inspect attached context, then send a bounded question:

Explain how stream_register accepts and delivers one byte.
Identify reset behavior and ready/valid conditions. Cite the source
locations you inspected. Do not modify files. List any unknowns.

Compare the answer with source. A plausible answer without source evidence is not a design finding. Remove unnecessary pinned files before the next request.

6. Optional: plan, approve and review#

1. Choose one small task, such as adding a reset/backpressure test. Switch the composer to Plan and ask for affected files, expected behavior and checks.
2. Review the proposed context, interfaces and scope. Approve execution only when they match your intent.
3. Inspect the returned candidate in Changes → AI proposals. Read actual diffs and Verify evidence, including missing checks.
4. Apply or reject explicitly using the review workflow. Re-review if working source or candidate content changes.

Expected result: a reviewed change with known source/configuration bindings, or a clearly rejected candidate. An AI summary alone never completes the workflow.

Keep the source versions separate#

Original source

The exact two files above should print PASS: reset and stalled transfer and produce stream.vcd.

Deliberately broken source

Changing reset to assert out_valid should fail with reset did not clear valid. Save the diagnostic separately; it is a negative control, not a proposed repair.

Restored source

Restore the original reset, recompile and rerun. The passing result belongs to that restored source and test, not to a later AI candidate.

This exercise tests synchronous reset, acceptance of one byte, a three-cycle output stall and consumption. It does not establish all traffic cases, parameter configurations, timing or equivalence. Continue with consecutive traffic and a pending reset to add specific coverage.

Know when this task is complete#

• The intended source folder opens and stream_register can be inspected in source.
• The original RTL passes the directed test, and the deliberately broken reset fails for the stated reason.
• You know which source and testbench produced stream.vcd. The run belongs to the saved source and testbench you inspected. Optional terminal results stay separate from application-custodied Verify receipts.
• If you used AI, its candidate was explicitly reviewed and either applied or rejected. If you did not, the deterministic learning task is still complete.

Save the source, close the application, launch it normally and open this project from Recent projects. Confirm your saved edit is still present and inspect the retained result before running a fresh check.

Keep RTL and testbenches; treat *.vvp and *.vcd as regenerable local outputs. Before making further edits, learn how to record a local Git baseline or preserve a scoped checkpoint.

When progress stops#

If indexing fails, use Retry indexing after correcting the diagnosed source/configuration issue; Open project files keeps source accessible. If tools are missing, preserve the evidence gap rather than accepting an untested change. If AI stops, inspect its candidate status before retrying; a stopped request does not undo changes already explicitly applied.

Continue with project inputs, design navigation, verification and the example walkthroughs.

Optional: inspect the complete example source#

Save this exact text as stream_register.sv in stream-demo. It is a one-byte, one-stage ready/valid buffer with synchronous active-high reset. Input is accepted when in_valid && in_ready; output is consumed when out_valid && out_ready.

`timescale 1ns/1ps
module stream_register (
  input logic clk, rst,
  input logic [7:0] in_data,
  input logic in_valid,
  output logic in_ready,
  output logic [7:0] out_data,
  output logic out_valid,
  input logic out_ready
);
  assign in_ready = !out_valid || out_ready;
  always_ff @(posedge clk) begin
    if (rst) begin
      out_valid <= 1'b0;
      out_data <= '0;
    end else if (in_ready) begin
      out_valid <= in_valid;
      if (in_valid) out_data <= in_data;
    end
  end
endmodule

Save the following as tb.sv in the same folder. The checker resets the buffer, accepts one byte, holds output stalled for three cycles and consumes it. It intentionally drives inputs away from the sampling edge.

`timescale 1ns/1ps
module tb;
  logic clk = 0, rst = 1;
  logic [7:0] in_data = 0, out_data;
  logic in_valid = 0, in_ready, out_valid, out_ready = 0;
  stream_register dut(.*);
  always #5 clk = !clk;
  initial begin
    $dumpfile("stream.vcd");
    $dumpvars(0, tb);
    repeat (2) @(posedge clk);
    #1;
    if (out_valid !== 0) $fatal(1, "reset did not clear valid");
    @(negedge clk); rst = 0; in_data = 8'h2a; in_valid = 1;
    @(posedge clk); #1;
    if (out_valid !== 1 || out_data !== 8'h2a)
      $fatal(1, "accepted byte missing");
    @(negedge clk); in_valid = 0;
    repeat (3) begin
      @(posedge clk); #1;
      if (out_valid !== 1 || out_data !== 8'h2a || in_ready !== 0)
        $fatal(1, "stalled output changed");
    end
    @(negedge clk); out_ready = 1;
    @(posedge clk); #1;
    if (out_valid !== 0) $fatal(1, "consumed byte remained valid");
    $display("PASS: reset and stalled transfer");
    $finish;
  end
endmodule

In a terminal in stream-demo, run these standalone simulator commands after installing that tool:

Optional terminal replay#

This is an independent simulator exercise, not a required step to open or edit the project in SiliconForge. It needs Icarus Verilog and vvp on your terminal PATH; a tool available to the app may not be on PATH. A terminal result is not automatically an application-custodied verification receipt.

iverilog -g2012 -s tb -o stream.vvp stream_register.sv tb.sv
vvp stream.vvp

Run the second command only if compilation succeeds. In PowerShell inspect $LASTEXITCODE immediately after each command; in a POSIX shell inspect echo $?. Do not run an older stream.vvp left by an earlier successful compile after a new compile fails.

Expected result: exit status 0, PASS: reset and stalled transfer, and stream.vcd. A compile error, missing PASS marker or failed assertion is not success. This is a directed teaching example, not complete protocol verification; next add consecutive transfers, reset during traffic and longer stalls. The generated VCD and simulator executable are outputs, not native RTL.

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