Introduction

ChipVerify brings the full chip design flow to your browser — the same flow used in the semiconductor industry. Design in Verilog, verify with simulation, synthesize to SkyWater 130nm standard cells, and run the full backend flow all the way to a placed-and-routed GDSII layout with DRC and LVS sign-off — all without installing a single tool.

What Can You Do?

Quick Start

Get up and running in under 5 minutes:

1. Create a Project

   Click File → New Project, give it a name, and a source file is created for you.

2. Write Your Design

   Use the Monaco editor. Load a template via Code Templates or write from scratch.

3. Add a Testbench

   Create a file with tb or test in its name for automatic testbench detection.

4. Run Simulation

   Simulate tab → enable "Dump Waveform (VCD)" → click Run Simulation, or press Alt+R.

5. View Waveforms

   Press Alt+W to open the Surfer waveform viewer.

6. Synthesize (Optional)

   Synth tab → load a template → click Run Synthesis for gate-level netlist, schematic, and PPA metrics.

Site Tour

ChipVerify includes an interactive guided tour (powered by Intro.js) that auto-launches on first login. It takes about 2 minutes and covers every major panel.

Tour Steps (10 total)

1. Welcome to ChipVerify — Overview of the RTL flow platform
2. File Explorer — Create, rename, group, and manage Verilog files
3. Code Editor — Monaco editor with syntax highlighting, auto-complete, and inline lint
4. File Menu — New project, save/load, download as ZIP, browse examples
5. Simulation Tools — Icarus Verilog and Verilator simulator configuration
6. Synthesis & Analysis — Yosys synthesis, schematic viewer, PPA metrics
7. Daily Quota Display — Track your FREE tier limits (resets at midnight UTC)
8. Misc Features — Ask AI, share links, keyboard shortcuts
9. Help & Resources — User guide, feedback, About menu
10. Ready to Start — Launch straight into the IDE

Restarting the Tour

To replay the tour at any time: click the About menu in the top toolbar → Take Site Tour.

Interface Overview

Layout

Left Sidebar Tabs

Right Panel Tabs

Layout Menu

The Layout button in the navbar (PRO only) lets you switch between workspace presets without losing panel contents or editor state. Three built-in presets are available:

The Layout menu also contains the Panels submenu where you can show or hide individual panel tabs without destroying their state.

Panel Details

All panels live inside the resizable Golden Layout workspace. Drag panel tab bars to rearrange, or use Layout → Panels to show/hide tabs without losing their state.

Left Sidebar Panels

Files FREE

Add, delete, rename, and group .v / .sv / .sdc files. Drag files to reorder. Right-click a file for options (rename, delete, set as testbench).

Simulate FREE

Configure and trigger simulation runs. Options include simulator choice (Icarus / Verilator), compilation flags, VCD waveform generation, code coverage, and compile order.

Synth FREE

Configure synthesis: standard cell library (hd / hs / ms / ls / hvl), process corner (typical / fast / slow), SDC template selection, and synthesis cache control.

Lint FREE

Configure and run Verilator lint checks. Catches type errors, sensitivity list issues, and other common RTL problems before simulation.

Formal FREE

SymbiYosys Bounded Model Checking. Select an engine, set a depth, write inline SVA assertions, and click Run. Returns PASS, FAIL, or ERROR. On FAIL, a counterexample waveform is generated and can be opened directly in the Waveform Viewer.

STA PRO

Configure Static Timing Analysis: set clock period and process corner, then launch an OpenSTA run. SDC constraints are read from constraints.sdc in the editor. Results appear in the STA panel on the right.

Ask AI PRO

Context-aware AI assistant (BYOK). Requires a PRO subscription and your own provider API key. See the Ask AI section for setup details.

Code Intelligence Panels

Outline FREE

Real-time symbol browser for the active file. Parses client-side — no server round-trip.

• Modules — instances, parameters, variables, always/initial blocks, tasks, functions
• Classes — fields, parameters, tasks, functions; child classes nested under parents
• Interfaces, Packages, Properties — full SystemVerilog support
• Click to jump — navigates to that line in the editor
• Filter bar — type to filter symbols; auto-refreshes 400 ms after you stop typing

UVM Hierarchy FREE

Scans all project files and builds a cross-file class inheritance tree. Essential for UVM testbenches.

• Full chain from UVM base classes to your leaf classes
• Classes with multiple children highlighted in red; duplicate definitions flagged in yellow
• Click any class to jump to its declaration; hover for parent, file:line, fields, tasks

FSM FREE

Extracts and visualizes Finite State Machines from case statements. See the FSM Analyzer section for full usage.

Run Output Panels

Console FREE

• Real-time output — compilation and simulation logs stream live
• Search — click the search icon to filter output text
• Queue badge — shows count of pending and running jobs

Lint Results FREE

Parsed Verilator lint output grouped by severity. Click any issue to jump to the offending line.

Coverage FREE

HTML coverage report generated by the Covered tool after a simulation run with "Generate Coverage Report" enabled. Displays line, toggle, and combinational coverage percentages with colour-coded source annotations. See the Code Coverage section for full usage.

Synthesis & Analysis Panels

Netlist FREE

Synthesized gate-level Verilog rendered as a clickable list. Click instance names or net names to highlight the corresponding element in the Schematic panel.

Schematic FREE

Interactive SVG schematic of the synthesized netlist rendered by NetlistSVG. Click cells to highlight them; click wires to trace connectivity. See the Interactive Schematic section for full details.

Waveform Viewer FREE

Embeds the Surfer VCD waveform viewer. Load the VCD generated by a simulation run, zoom in/out, and inspect signal values at any timestep.

Hierarchy PRO

Module instantiation tree showing cell counts per module after synthesis. Click any module to navigate to it in the Schematic panel.

Cell Info PRO

Click any cell in the schematic to populate this panel with:

• Instance name, cell type, and boolean function
• Input/output ports and connected net names
• Fanin / fanout cells
• Liberty characteristics: area, leakage power, drive strength, timing delays
• Setup/hold timing paths and slack values

Connectivity PRO

Click any net (wire) in the schematic to see every driver and load connected to it. Click Clear to reset the highlight.

PPA PRO

Power, Performance, and Area metrics extracted by OpenSTA after synthesis. See the PPA Analysis section for details.

PPA History PRO

Chart and table comparing PPA metrics across multiple synthesis runs. See the PPA History section for details.

STA PRO

Full OpenSTA timing report: critical paths, slack, worst negative slack, and total negative slack. Timing paths can be clicked to highlight them in the Schematic panel. After synthesis, a Re-run Timing button appears here to re-analyze with updated SDC constraints without re-synthesizing.

Backend Flow Panels

PnR Config PRO

Configure and submit a Place & Route job: standard cell library, process corner, target utilization, clock period, and TinyTapeout tile size. Progress streams live in the Console panel during the run.

PnR Layout Viewer PRO

Interactive chip layout viewer that appears after a PnR job completes:

• Pan / Zoom — mouse drag to pan, scroll wheel to zoom
• Layer Toggles — show/hide individual metal, via, active, poly, and boundary layers
• Click to Identify — click any shape to identify the standard cell under the cursor by name, type, and location
• Schematic Button — loads the post-route netlist into the Schematic panel with full Cytoscape renderer
• Timing Button — toggles the pre-route vs post-route timing comparison strip
• DEF / GDS Download — download the routed DEF or the full GDSII file

DRC Results PRO

Design Rule Check summary showing total violation count, clean/fail status, and a per-category breakdown (FEOL, BEOL, offgrid). See the DRC section for details.

Showing and Hiding Panels

Click Layout → Panels in the navbar to toggle any panel tab without destroying its state.

• Hiding a panel preserves all output — unhide to see it again instantly
• Preferences are saved to localStorage and restored on next page load

Panel Groups in the Menu

• Code Intelligence — Outline, UVM Hierarchy, FSM
• Run Output — Console, Lint Results, Coverage
• Synthesis & Analysis — Netlist, Schematic, Hierarchy, Connectivity, PPA, PPA History, STA

File Management

Adding Files

Click the + button in the Files panel or drag & drop .v / .sv files into the browser.

Organizing Files

File Grouping:

1. Select multiple files (hold Ctrl and click)
2. Right-click → "Create Group"
3. Name your group (e.g., "ALU", "Control Logic")

Reordering: Drag and drop files to change compilation order.

File Actions

• Rename: Right-click → Rename
• Delete: Right-click → Delete
• Download: Save/Load → Download options

GitHub Integration

Connect your GitHub account to import repositories and sync projects.

Connecting

1. Open Settings — click your profile icon → Settings
2. Click "Connect GitHub" — in the GitHub Integration section
3. Authorize ChipVerify — on GitHub's authorization page
4. Done — your GitHub username and connection date appear in Settings

Importing from GitHub

1. Click Save/Load → Import from GitHub
2. Select repository and branch
3. Verilog files (.v, .sv) are imported into a new project

Syncing Projects

Code Editor

Features

• Syntax Highlighting — Verilog and SystemVerilog, plus SDC (TCL) for constraint files
• Auto-completion — Monaco IntelliSense for keywords and signal names
• Multi-file Tabs — open and switch between multiple files
• Auto-save — saves changes every 30 seconds when signed in
• Inline lint markers — errors and warnings appear in the gutter

Keyboard Shortcuts in Editor

Code Templates

Click Code Templates in the Files panel to load pre-built modules including gates, flip-flops, counters, FSMs, and testbench skeletons.

Simulation

Simulator Choice

Daily Quota

Running a Simulation

1. Prepare Files — at least one design file and one testbench
2. Configure — Simulate tab:
   • Select simulator (Icarus or Verilator)
   • Set compilation args (-g2005 -Wall for Icarus, --timing for Verilator)
   • Enable "Dump Waveform (VCD)" for signal viewing
   • Adjust Compile Order if module dependencies require it
3. Run — click Run Simulation or press Alt+R
4. Review — compilation and simulation output stream live in the Console panel

Compilation Order

The Compile Order panel in the Simulate tab lets you drag files to control compilation sequence. Modules must be compiled before the files that instantiate them. The order used is echoed in the Console at the start of each run.

Simulation Cache

Results are cached by SHA-256 hash of your source files (1-hour TTL). If you see stale results, click Clear Simulation Cache in the Simulate tab.

Testbench Requirements

`timescale 1ns/1ps

module tb;
    reg clk, rst;

    initial begin clk = 0; forever #5 clk = ~clk; end

    initial begin
        $dumpfile("dump.vcd");  // Required for waveforms
        $dumpvars(0, tb);
        rst = 1; #20 rst = 0;
        // test cases here
        #1000 $finish;          // Required to end simulation
    end
endmodule

SRAM Macros (sky130 OpenRAM)

ChipVerify includes precompiled sky130 SRAM macros generated by OpenRAM. These are hard macros — you instantiate them by name in your Verilog, and both the simulator and the synthesizer handle them natively:

• Simulation — a functional behavioral model is automatically included in every compile. No extra setup needed.
• Synthesis — the macro is treated as a blackbox. Yosys preserves the instantiation in the output netlist instead of synthesizing it into flip-flops.

Available Macros

Open the IP Library button in the IDE toolbar () to browse all macros, view the full port reference, and copy a ready-to-use instantiation template.

Port Interface

All macros share the same 1 read-write + 1 read-only port topology. Both ports are synchronous — read data appears one clock cycle after the address is presented.

Example — Write on Port 0, Read on Port 1

// 1 KB data memory using sky130_sram_1rw1r_32x256_8
module cpu_dmem (
    input         clk,
    input         wen, ren,
    input  [7:0]  waddr, raddr,
    input  [31:0] wdata,
    output [31:0] rdata
);
    sky130_sram_1rw1r_32x256_8 u_sram (
        // Port 0: write
        .clk0   (clk),
        .csb0   (~wen),
        .web0   (~wen),
        .wmask0 (4'b1111),   // all bytes
        .addr0  (waddr),
        .din0   (wdata),
        .dout0  (),
        // Port 1: read
        .clk1   (clk),
        .csb1   (~ren),
        .addr1  (raddr),
        .dout1  (rdata)
    );
endmodule

Testbench Tips

• Drive csb0 = 1 and csb1 = 1 (deselect) when not accessing the SRAM — leaving them low can cause unintended reads or writes.
• Read data is registered: after asserting csb1 = 0 on the rising edge, the valid data appears on dout1 on the next rising edge.
• Simultaneous access to the same address from both ports in the same cycle produces undefined results — use arbitration logic if your design requires it.
• The behavioral model initialises all memory to zero at simulation start. Use $readmemh on a wrapper register array if you need pre-loaded content for test.

Code Coverage FREE

Code coverage measures how much of your Verilog design is exercised by your testbench. ChipVerify uses the open-source Covered tool to generate a detailed HTML report after a simulation run.

Coverage Types

Enabling Coverage

1. Open the Simulate tab in the left sidebar
2. Enable "Dump Waveform (VCD)" — coverage requires a VCD file
3. Check "Generate Coverage Report"
4. Click Run Simulation
5. When the run completes, open the Coverage panel on the right to see the report

Reading the Coverage Report

The Coverage panel shows an HTML report with:

• Summary bar — overall line, toggle, and combinational percentages at a glance
• Per-file breakdown — click a file name to see annotated source code
• Colour-coded lines — green = covered, red = not covered, yellow = partially covered
• Toggle detail — each signal shows which transitions occurred (0→1, 1→0)

Click the download icon in the Coverage panel header to save the HTML report locally.

Improving Coverage

• Add test vectors that exercise edge cases and corner conditions
• Check uncovered lines — they often reveal untested error paths or reset conditions
• Uncovered toggles on control signals usually mean a reset or enable is never deasserted in the testbench
• Aim for >90% line coverage before moving to synthesis

FSM Analyzer FREE

The FSM Analyzer automatically extracts Finite State Machines from your Verilog source code and renders an interactive state-transition diagram. It works by parsing case statements that drive a state register, without requiring simulation.

How to Use It

1. Open the FSM panel in the right panel tab bar
2. Use the file selector dropdown to choose a specific file, or leave it on "All files" to analyze the whole project
3. Click Analyze FSM
4. The panel renders the state diagram — zoom and pan to explore it

Diagram Features

• States — each state value is a node; the current state is labelled with its constant name if defined
• Transitions — labelled arrows show the condition that causes each state change
• Click a state — highlights all transitions entering and leaving it
• Zoom / Pan — mouse wheel to zoom, click-drag to pan
• Multiple FSMs — if the file contains more than one state machine, each is rendered as a separate diagram

Supported Coding Patterns

The analyzer recognizes the standard two-always-block FSM pattern:

// State register (sequential)
always @(posedge clk or posedge rst) begin
    if (rst) state <= IDLE;
    else     state <= next_state;
end

// Next-state logic (combinational)
always @(*) begin
    case (state)
        IDLE:  next_state = (start) ? WORK : IDLE;
        WORK:  next_state = (done)  ? IDLE : WORK;
        default: next_state = IDLE;
    endcase
end

Limitations

• Implicit FSMs (if/else chains without a dedicated state register) may not be detected
• Very large state machines (>50 states) can be difficult to navigate — zoom in on specific regions
• The analyzer performs static analysis only; runtime-dependent transitions are shown with their static conditions

Synthesis

What is Synthesis?

Synthesis converts your RTL Verilog into a gate-level netlist using actual standard cells from the SkyWater 130nm open-source PDK — the same PDK used for real chip tapeouts.

Synthesis Workflow

1. Select Library

   Choose a SkyWater cell library in the Synth tab:

   Library	Full Name	Characteristic
   hd	High Density	Most compact — best for learning
   hs	High Speed	Faster cells, more area
   ms	Medium Speed	Balanced
   ls	Low Speed	Lower power
   hvl	High Voltage	High-voltage I/O cells

2. Select Process Corner

   Corner	Conditions	Use For
   TT (Typical)	25°C, 1.8V	Normal operating conditions
   FF (Fast)	−40°C, 1.95V	Best-case performance, highest leakage
   SS (Slow)	125°C, 1.65V	Worst-case timing — use this to validate

3. Load a Template PRO

   PRO users can load custom synthesis.ys and constraints.sdc templates from the Synth tab dropdown.

4. Enable Options
   • Run PPA Analysis — power/performance/area metrics via OpenSTA
   • Generate Schematic — NetlistSVG visual diagram
5. Run Synthesis — click Run Synthesis button
6. View Results
   • Console — Yosys log with cell statistics
   • Netlist — gate-level Verilog (clickable)
   • Schematic — interactive visual diagram
   • PPA — metrics if enabled

Interactive Schematic NEW

After synthesis, the Schematic panel shows a full IEEE-style visual representation of your design. Every element is interactive — click to highlight, trace signals, and explore connectivity.

Module Boundary Box

• Blue dashed rectangle marks the module boundary
• Module name shown in a header at the top of the boundary
• Input ports (green pentagon symbols) relocated to the left edge
• Output ports (blue pentagon symbols) relocated to the right edge
• Orthogonal wire extensions connect relocated ports back to internal nets

Navigation

• Pan — click and drag
• Zoom — scroll wheel
• Hierarchy — double-click a module cell to descend into it
• Fit — use the fit button to reset to full view

Clickable Cells

Click any standard cell in the schematic to:

• Highlight the cell and its connections in blue
• Populate the Cell Info panel with instance name, cell type, ports, timing, and Liberty data PRO
• Auto-highlight the corresponding instance in the Netlist panel

Clickable Nets (Wires)

Click any wire to:

• Highlight the net across all connected cells
• Show drivers and loads in the Connectivity panel PRO
• Auto-highlight the net name in the Netlist panel

Netlist ↔ Schematic Cross-Highlight

The Netlist and Schematic panels stay in sync:

• Click an instance name in the Netlist → highlights that cell in the Schematic
• Click a net/wire name in the Netlist → highlights that wire in the Schematic
• Wire declarations and constant values are styled differently — constants (e.g. 1'h0) are not clickable

STA Timing Path Highlighting

After running STA, click any timing path in the STA report to:

• Highlight the critical path through the schematic with gradient coloring
• Color intensity reflects timing delay — darkest cells are the slowest

Regex Pattern Highlighting

Use the search field in the Schematic toolbar to enter a regex pattern. All matching cell or net names highlight simultaneously — useful for tracing clock trees, reset nets, or bus structures.

Cell Category Colors (Post-PnR)

When the schematic is loaded from a PnR job (via the PnR panel's Schematic button), cells inserted by the PnR tool are automatically colour-coded by category:

Category Legend & Filtering

A colour legend appears below the schematic toolbar when a post-PnR schematic is loaded. Each row has a checkbox and a colour swatch:

• Check a box — that category is fully visible
• Uncheck a box — cells in that category dim to ~8% opacity (not hidden). They stay in place so you can see spatial context while focusing on other categories.

A common workflow: uncheck Filler and Tap cells to focus on logic cells and CTS buffers without removing the structural context those rows provide.

Verilator Lint

What it Checks

• Unused signals — declared but never used
• Undriven nets — wires without drivers
• Multiple drivers — signals driven from multiple sources
• Width mismatches — assignment size issues
• Combinational loops — feedback without registers
• Case statement issues — missing defaults, overlapping cases
• Blocking vs non-blocking — improper assignment in clocked blocks

Running Lint

1. Go to Lint tab in left sidebar
2. Optionally add args (e.g. -Wall --lint-only)
3. Click Run Verilator Lint or press Alt+L
4. View results in the Lint panel on the right

Reading Results

%Warning-UNUSED: design.v:15: Signal is not used: 'temp_data'
%Warning-WIDTH: design.v:23: Operator ASSIGN expects 8 bits, got 4

Static Timing Analysis

What is STA?

STA verifies that your design can run at a target clock frequency. OpenSTA traces every data path from flip-flop to flip-flop and measures delay. The longest path — the critical path — determines maximum frequency.

STA Workflow

1. Run Synthesis — with your chosen library and corner
2. STA Tab — set Clock Period (ns) and Process Corner to match synthesis
3. Edit SDC (Optional) — open constraints.sdc in the editor and modify clock definitions, I/O delays, or timing exceptions
4. Run STA — click "Run STA Analysis"
5. Read Report — view critical paths and slack in the STA panel

Re-run Timing PRO

After a successful synthesis, the Re-run Timing button appears in the STA panel. Use it to re-run OpenSTA with updated SDC constraints without repeating synthesis.

• Progress streams live in the Console panel
• The STA panel shows a header with the job ID and corner when the report loads
• If a learning session is active, the re-run is recorded in Run History
• Click Analyze on any STA run in history to restore the full report and SDC file

Understanding Slack

Path 1: MET  (slack: +2.34 ns)
  Data arrival time:   5.62 ns
  Data required time:  7.96 ns
  Slack:              +2.34 ns  ✅

Fixing Timing Violations

1. Reduce clock frequency — easiest fix
2. Pipeline the critical path — add register stages to break long combinational paths
3. Switch to a faster library — e.g. hs instead of ls
4. Restructure RTL — reduce logic depth in the critical path
5. Try FF corner — fastest cells, best-case timing

Formal Verification

Formal verification uses mathematical solvers to prove or disprove assertions about your design — no testbench required. ChipVerify uses SymbiYosys in Bounded Model Checking (BMC) mode: the solver unrolls your design for N clock cycles and checks whether any assertion can be violated within that window.

Quick Start

1. Open the Formal panel in the layout
2. Make sure your DUT is open in the editor
3. Click Generate formal_props.sv — a property harness is created and opened
4. Edit the assertions in formal_props.sv, then switch back to your DUT
5. Choose an engine (Boolector is fastest for most designs) and set a depth
6. Click Run Formal Verification — live solver output streams to the console
7. Read the result: PASS, FAIL, or ERROR

Writing Assertions

Assertions live in a separate property harness file called formal_props.sv. This file uses a SystemVerilog bind directive to attach SVA properties to your top module without modifying your original design — no port wiring needed.

1. Open your DUT (design-under-test) in the editor
2. Click Generate formal_props.sv in the Formal panel — this creates a ready-to-edit harness file and opens it in the editor
3. Replace the placeholder assert (1'b1); with your real properties
4. Switch back to your DUT file, then click Run Formal Verification

The generated harness looks like this:

// formal_props.sv
module counter_props (
    input clk,
    input rst,
    input [7:0] count
);
    initial assume (rst == 1'b1);   // start in reset

    always @(posedge clk) begin
        if (!rst) begin
            // replace with real assertions:
            assert (count <= 8'hFF);
        end
    end
endmodule

bind counter counter_props u_props (.*);

Common assertion patterns:

// Output never unknown
always @(posedge clk)
    if (rst) assert (!$isunknown(out));

// Counter never overflows
always @(posedge clk)
    if (rst) assert (count <= 8'hFF);

// Handshake: valid only when ready
always @(posedge clk)
    if (rst && valid) assert (ready);

// Load takes effect one cycle later
always @(posedge clk)
    if (rst && $past(load) && !load) assert (out == $past(data_in));

Yosys SVA Limitations

ChipVerify uses Yosys as the front-end parser. Yosys implements a useful subset of SystemVerilog Assertions (SVA), but not the full IEEE 1800 standard. Understanding what is and isn't supported will save you debugging time.

✅ Supported

• assert(...) inside always @(posedge clk) blocks — the standard pattern
• assume(...) inside always @(posedge clk) — constraining inputs
• cover(...) — reachability checks
• $past(sig), $rose(sig), $fell(sig), $stable(sig)
• initial assume(...) — constraining the initial state
• assert property (seq) at module level without an explicit clocking event (clock inferred from the design)

❌ Not Supported

• assert property (@(posedge clk) ...) — explicit clocking events inside assert property are full IEEE 1800 SVA and are not parsed by Yosys. Use an always @(posedge clk) block instead:

  // ❌ does NOT work in Yosys
  assert property (@(posedge clk) disable iff (!rst) count <= 4'hF);
  
  // ✅ works — put assertions inside an always block
  always @(posedge clk) begin
      if (rst) assert (count <= 4'hF);
  end

• disable iff (...) — use a guarding if (rst) condition inside the always block instead
• Overlapping implication |->` and `|-> inside assert property — replace with if/else and $past():

  // ❌ not supported
  assert property (@(posedge clk) $past(load) && !load |-> count == $past(data));
  
  // ✅ equivalent using always + $past
  always @(posedge clk) begin
      if (rst)
          if ($past(load) && !load) assert (count == $past(data));
  end

• Named sequences / properties — sequence s; ... endsequence and property p; ... endproperty blocks are not supported
• Simulation-only constructs — $display, $finish, delays (#5), and fork/join
• Unbounded proof — only Bounded Model Checking (BMC) is available; PASS means no violation within N cycles, not a full proof

Engines

Depth Limits

The depth is the number of clock cycles the solver unrolls. Higher depth finds bugs that take more cycles to manifest, but takes longer to run.

• FREE tier — depth 1–10
• PRO tier — depth 1–100

Reading Results

✅ PASS

No assertion violation was found within the specified depth. This is a bounded guarantee — the solver checked every possible input sequence up to N cycles.

❌ FAIL — Counterexample Found

The solver found a concrete sequence of inputs that violates an assertion. The exact cycle number is shown in the result banner. An Open CEX in Surfer button appears — click it to load the counterexample waveform directly in the Waveform Viewer and inspect every signal at every cycle.

SBY [engine_0] FAIL
SBY engine_0: counterexample found at step 4

⚠️ ERROR

Common causes:

• Syntax error — "unexpected '@'" — you used assert property (@(posedge clk) ...); Yosys does not support explicit clocking events inside assert property. Move assertions into an always @(posedge clk) block. See Yosys SVA Limitations above.
• Syntax error in assertions — check for missing semicolons, unsupported SVA constructs (disable iff, |->), or simulation-only keywords
• Undefined top module — the auto-detector couldn't find a module declaration; check your code compiles cleanly first
• Solver timeout — the job exceeded 5 minutes; reduce depth or simplify the design
• Unsupported construct — SymbiYosys requires synthesisable RTL; remove $display, $finish, delays (#), and other simulation-only constructs

Using the CEX Waveform

1. When a FAIL result appears, click Open CEX in Surfer
2. The Waveform Viewer opens with the counterexample trace loaded
3. Step through cycles to see exactly which input combination triggered the assertion
4. Use the signal list to identify the offending value
5. Fix the RTL or tighten the assertion and re-run

Tips & Best Practices

• Lint first — run Verilator lint before formal; undriven nets confuse the solver
• One assertion at a time — isolate failing assertions to identify which property is broken
• Label your assertions — add a Verilog label before the assert for clearer solver output: overflow_check: assert (count <= 8'hFF);
• Constrain inputs with assume — if your design requires valid input protocols (e.g. a FIFO that's never written when full), add assume statements to limit the solver's input space
• Initialise registers — add initial blocks or reset logic; the solver starts from an arbitrary state unless you constrain it
• Result is cached — identical code + assertions + engine + depth returns instantly from cache for 1 hour

Formal vs Simulation

RTL to GDSII — Backend Flow PRO

The backend flow takes your synthesized gate-level netlist and turns it into a physical chip layout — a GDSII file that a silicon foundry can use to manufacture your design. ChipVerify runs the full flow using OpenROAD (place, route, CTS, STA), KLayout (GDS generation, DRC), Magic (transistor extraction), and Netgen (LVS comparison) — all targeting the open-source SkyWater 130nm PDK.

The Full Pipeline

What You Get

• layout.gds — foundry-ready GDSII with all metal layers and vias
• layout.def — routed DEF for inspection or re-import into EDA tools
• layout.v — post-route gate-level Verilog including CTS buffers and antenna diodes
• layout.sdf — Standard Delay Format for timing-accurate gate-level simulation
• drc_report.json — sky130A design rule check results
• lvs_report.json — layout vs schematic comparison result
• sta_report.txt — full post-route setup and hold path report
• power_report.txt — post-route power breakdown: internal / switching / leakage by cell group
• congestion_report.txt — per-layer routing overflow percentage for every metal layer

Congestion Analysis

After global routing, OpenROAD reports the overflow percentage for each routing layer — the fraction of routing tracks that were over-demanded. The PnR panel shows this as a per-layer summary with colour coding:

• 0 % overflow — no congestion; routing is clean
• 1–5 % overflow — minor congestion; likely resolves in detailed routing
• > 5 % overflow — severe congestion; consider reducing utilization or widening the floorplan

High congestion on met1/met2 usually means your core utilization is too high. Try reducing it from the default 40 % to 30–35 % in the PnR config panel.

Post-Route Power Analysis

After routing, OpenROAD runs OpenSTA with real RC parasitics to compute activity-based power. The PnR panel displays a breakdown by cell group:

Power is reported in µW or mW and split into three components: internal (short-circuit current within a gate), switching (capacitive load charging), and leakage (static subthreshold current). At sky130nm, leakage is negligible compared to dynamic power for most designs.

Sky130 Standard Cell Libraries

All five SkyWater libraries are supported for PnR (same choice as synthesis):

Place & Route PRO

Place & Route (PnR) takes the gate-level netlist from synthesis and physically arranges the standard cells on silicon, then routes the metal wires between them. ChipVerify uses OpenROAD — the same engine behind the open-source ORFS tapeout flow.

Running PnR

1. Run Synthesis First

   PnR starts from your synthesized netlist. Make sure synthesis has completed and the netlist is available. Match the library and corner across both steps.

2. Open the PnR Tab

   In the left sidebar, click the PnR tab.

3. Configure

   Setting	Description
   Library	Must match the library used for synthesis (hd / hs / ms / ls / hvl)
   Corner	Process corner for timing analysis (typical / fast / slow)
   Target Utilization	Fraction of die area used by cells (0.3–0.6 is typical; higher = denser but harder to route)
   Clock Period (ns)	Target clock constraint for CTS and post-route STA; leave empty if your design has no clock

4. Submit

   Click Run Place & Route. The job queues in the PnR worker (one job at a time). Progress streams live in the Console panel — you can watch the OpenROAD log as placement, CTS, global route, and detailed route complete.

5. View Results

   When the job completes, the PnR panel shows:

   • Result banner with WNS, TNS, total cells, chip area, antenna violations, DRC status, and LVS status
   • Interactive layout viewer (pan/zoom, layer toggles, click-to-identify)
   • Download buttons: DEF, GDS
   • Schematic button — loads post-route netlist into the Schematic panel
   • Timing button — shows pre-route vs post-route comparison strip

Understanding PnR Results

Layout Viewer

The interactive layout viewer renders the chip using the sky130 GDS layer stack. Each metal layer is color-coded:

Use the layer toggle checkboxes in the viewer header to show or hide individual layers. Click anywhere on the layout to identify which standard cell is under the cursor.

TinyTapeout Mode

When submitting via TinyTapeout Mode, a fixed tile footprint is used instead of a free die size:

Design Rule Check (DRC) PRO

After routing, ChipVerify automatically runs a sky130A DRC using KLayout. DRC checks that every polygon in the layout obeys the foundry's physical manufacturing rules — minimum spacing, minimum width, overlap requirements, and grid alignment. A DRC-clean layout is required before tapeout.

What Gets Checked

Reading DRC Results

The DRC panel shows:

• Total violation count — 0 means clean
• Per-category table — rule name, human-readable description, violation count
• A CLEAN or VIOLATIONS badge in the PnR result header

What to Do if DRC Fails

• Small violation count (1–5) — usually boundary issues or density rule violations from a slightly unusual floorplan; try re-running with a slightly different utilization target
• Many violations in one category — often a routing congestion issue; reduce utilization (more routing room) and re-run
• Offgrid violations — rare; typically indicates a PDK or tech file inconsistency in the tool flow rather than something in your RTL

Layout vs Schematic (LVS) PRO

LVS verifies that the routed layout is electrically equivalent to the gate-level schematic. It answers the question: "Does the physical chip I generated actually implement the circuit I designed?" ChipVerify runs Magic for transistor extraction from the GDS and Netgen for netlist comparison.

How LVS Works

1. Magic extracts the layout

   Magic reads the GDSII, recognizes transistor geometries (N-FETs and P-FETs), and produces a SPICE netlist (lvs_extracted.spice) listing every transistor and its connections.

2. Schematic CDL is assembled

   OpenROAD's write_cdl produces a hierarchical CDL of your design (layout.cdl). This is combined with the volare PDK library CDL — which contains the transistor-level description of every standard cell — to produce the complete schematic reference (lvs_schematic.cdl).

3. Netgen compares them

   Netgen flattens both netlists and performs a bijective cell/net matching. It reports "Circuits match uniquely" (MATCH) or detailed device/net mismatches (NO MATCH).

Reading LVS Results

Library Support

All five sky130 libraries (hd, hs, ms, ls, hvl) are supported for LVS. The transistor-level CDL comes from the volare PDK inside the LVS container, so no additional configuration is needed when changing libraries.

Gate-Level Simulation PRO

Gate-Level Simulation (GLS) replaces your RTL with the actual synthesized or placed-and-routed netlist so you can verify gate-level behavior and, after layout, observe real propagation delays. ChipVerify supports two GLS modes, selected automatically based on what jobs you have completed:

The GLS checkbox in the Simulate panel shows a badge indicating which mode is active and which job it is linked to. After a hard refresh, the linked job is restored from session storage — you do not need to re-run synthesis or PnR.

Synthesis GLS — Functional Verification

Synthesis GLS is the first step after synthesis. It checks that your gate-level netlist is logically equivalent to your RTL — all cells are connected correctly, reset and clock behavior is preserved, and there are no synthesis bugs. No timing is modeled; every gate switches at time 0.

How to Run

1. Run Synthesis

   Complete a synthesis job. The Simulate panel will show the GLS checkbox with a blue synthesis badge and the linked job ID.

2. Write a testbench

   Your testbench instantiates your top-level module by name. The synthesized netlist is added automatically — you only need the testbench file.

   `timescale 1ns/1ps
   module tb;
       reg clk, rst_n;
       wire [3:0] q;
   
       // Module name must match the top-level synthesized module
       my_design dut (
           .clk(clk), .rst_n(rst_n), .q(q)
       );
   
       initial begin
           $dumpfile("dump.vcd");
           $dumpvars(0, tb);
           clk = 0; rst_n = 0;
           #20 rst_n = 1;
           #1000 $finish;
       end
       always #5 clk = ~clk;   // 100 MHz
   endmodule

3. Enable Gate-Level Simulation

   Check Gate-Level Simulation in the Simulate panel. The library is set automatically to match the synthesis job. Leave SDF Scope empty — it is not used in synthesis GLS.

4. Run

   Click Run Simulation. The compiler receives: the SKY130 cells_sim.v functional model, the synthesis netlist (netlist.v), and your testbench. Because there is no timing, all transitions are instantaneous — the waveform confirms logic correctness.

Post-Layout GLS — Timing-Accurate Simulation

After Place & Route, you can run a timing-accurate gate-level simulation that shows real propagation delays — flip-flop CLK→Q latency, combinational cell delays, and the effect of clock-tree buffers inserted by OpenROAD.

How It Works

OpenROAD writes a layout.sdf file after routing with RC-extracted delays. ChipVerify reads this SDF and builds a patched version of cells_sim.v where each wrapper cell module has an assign #(rise, fall) statement on its output, using the average delay values from the SDF. This lets Icarus Verilog produce sub-nanosecond transitions without requiring simulator support for SDF annotation on structural models.

Typical delays you will see in the SKY130 medium-speed (ms) library:

These delays stack across the combinational path: a flip-flop output passing through a clock buffer and a mux before reaching the next register can accumulate 400–600 ps of total delay — visible in the waveform at picosecond resolution.

How to Run

1. Complete a PnR job

   The PnR job must succeed and generate layout.sdf (requires a clock port). The Simulate panel will automatically switch to the post-route + SDF badge and show the linked PnR job ID.

2. Write a testbench

   Use `timescale 1ns/1ps — the 1 ps precision is required to resolve the sub-nanosecond delays. The post-route netlist (layout.v) is added automatically; you only supply the testbench.

   `timescale 1ns/1ps
   module tb;
       reg clk, rst_n;
       wire [3:0] q;
   
       // Same module name as your RTL top-level
       my_design dut (
           .clk(clk), .rst_n(rst_n), .q(q)
       );
   
       initial begin
           $dumpfile("dump.vcd");
           $dumpvars(0, tb);
           clk = 0; rst_n = 0;
           #20 rst_n = 1;
           #1000 $finish;
       end
       always #5 clk = ~clk;
   endmodule

3. Set the SDF Scope

   The SDF Scope field specifies the hierarchical path from the simulation root to your DUT instance. This must match the instance name you used when instantiating the design in the testbench.

   Testbench structure	SDF scope to enter
   Module tb, DUT instantiated as dut	tb.dut
   Module tb, DUT instantiated as u_top	tb.u_top
   DUT is the simulation top (no testbench wrapper)	leave empty

4. Run

   Click Run Simulation. The console will report SDF statistics and confirm that cell models have been patched:

   ⓘ Gate-level simulation: using sky130_fd_sc_ms cell models
   ⓘ Using post-route netlist from PnR job <id>
   ⓘ SDF paths: 35 interconnect, 39 cell IOPATH, CLK→Q 0.226–0.244ns, 8 setup / 8 hold checks
   ⓘ Cell models patched with propagation delays — CLK→Q and combinational delays active
   ⓘ Timescale: 1ns/1ps ✓ (sufficient for SDF delays)

Reading the Waveform

Open the waveform in Surfer. You will see that output signals no longer change exactly at the clock edge — they transition a few hundred picoseconds later. This reflects the real silicon behavior:

• The clock edge (e.g. at 45 000 ps) triggers the flip-flop.
• The flip-flop CLK→Q delay means Q changes at ~45 240 ps.
• Any combinational logic after the flip-flop adds further delay — a path through a MUX and inverter adds another 130–200 ps.
• The total path delay seen at the next register's input is the sum of CTS buffer delays, CLK→Q, and the combinational cone delay.

Synthesis GLS vs Post-Layout GLS — Quick Reference

Post-Route Schematic PRO

After PnR, click the Schematic button in the PnR panel header to load the post-route netlist into the interactive Schematic panel. This shows the actual circuit that was placed and routed — including all the extra cells OpenROAD inserted during the flow.

What's Different from the Synthesis Schematic

The synthesis schematic shows your RTL mapped to gates. The post-route schematic shows the same netlist plus ECO (Engineering Change Order) cells OpenROAD added automatically:

How to View It

1. Complete a PnR job successfully
2. In the PnR result panel header, click the Schematic button (purple)
3. The Schematic panel opens showing the post-route netlist
4. Use the same navigation, tracer, and cross-probe features as the synthesis schematic

Features Available

• BFS Fan-in / Fan-out tracing — right-click any cell → Show Fan-In Cone or Fan-Out Cone
• Hierarchy navigation — double-click module cells to descend into sub-modules
• Regex highlighting — type a pattern in the search box to highlight matching cells (e.g. clkbuf highlights all CTS buffers)
• Click to identify — click any cell to see its type, ports, and connectivity

Post-Route Timing Comparison PRO

After PnR, click the Timing button in the PnR panel header to see a pre-route vs post-route timing comparison. This answers the key question: "Did my timing get better or worse after place and route?"

The Comparison Strip

The timing strip shows four metrics side by side — post-synthesis (estimated) vs post-route (actual):

Typical Post-Route Patterns

Full Post-Route STA Report

For the complete setup and hold timing paths (not just WNS/TNS), click the Timing button to expand the strip, then click View Full Report. This loads the sta_report.txt file — the same full-clock-expanded path report format that OpenSTA produces, showing every input pin arrival time, cell delay, and net delay along each path.

Using Post-Route Timing to Improve Your Design

• If WNS is negative post-route: increase the clock period (lengthen constraint), reduce utilization to allow better placement, or pipeline the critical path in RTL and re-synthesize
• If hold violations appear: they are usually fixed automatically by OpenROAD's repair_timing. If they persist, reduce the clock period slightly (tighter constraint → more hold margin budget)
• If area grew unexpectedly: check the post-route schematic for large numbers of CTS buffers — this indicates high clock fanout in your design; use clock-gating or partition the clock tree in your RTL

Waveform Viewer

The waveform viewer is powered by Surfer — a high-resolution, browser-native waveform viewer.

Opening Waveforms

1. Enable "Dump Waveform (VCD)" in the Simulate tab
2. Run simulation successfully
3. Press Alt+W or click the waveform button

Navigation

• Scroll — move along the timeline
• Ctrl+Scroll — zoom in/out
• Zoom-to-fit — see the full simulation in one view
• Cursor A — click to place; shows time and value
• Cursor B — right-click; delta time between A and B shown in toolbar

Signal Display

• Bus signals (a[3:0]) shown with hex/decimal value labels — click to expand individual bits
• Right-click a bus to change format: binary, hex, decimal, or unsigned
• Right-click any signal to hide it; use the signal search box to add signals back

initial begin
    $dumpfile("dump.vcd");
    $dumpvars(0, tb);
end

PPA Analysis

What is PPA?

Performance, Power, Area — the three metrics chip designers optimize for.

Enabling PPA

1. Synth tab → check "Run PPA Analysis"
2. Use Technology-Mapped synthesis (requires Liberty files)
3. Run Synthesis
4. View results in the PPA panel

Metrics

Area

• Total Cells — number of standard cells
• Chip Area — physical silicon area (µm²)
• Cell Breakdown — which gate types are used most

Performance (Timing)

• Critical Path Delay — longest path through the design (ns)
• Max Frequency — highest achievable clock speed (MHz)
• Logic Levels — combinational depth of critical path

Power

• Dynamic Power — power when actively switching
• Leakage Power — static power when idle
• Total Power — dynamic + leakage

PPA History PRO

Track PPA metrics across multiple synthesis runs to understand how your design evolves across different libraries, corners, and optimization strategies.

Enabling

1. Check "Run PPA Analysis" in the Synth tab
2. Check "Compare with Past Runs"
3. Each synthesis run is automatically saved

What Gets Tracked

• Timestamp, library, and corner
• Cell count, wire count, and chip area
• Critical path delay, max frequency, slack
• Dynamic and leakage power
• Whether setup/hold constraints were met

Trend Charts & Sparklines

With 2+ runs, trend charts appear for frequency, area, and power. Color-coded arrows show improvement (green) or regression (red) vs the previous run. Sparkline summary cards show the latest value and % change from baseline at a glance.

Availability

SDC Constraints

What are SDC Files?

Synopsys Design Constraints define timing requirements for STA. Create or open constraints.sdc in the Files panel — it is edited directly in the Monaco editor like any other source file.

Common SDC Commands

1. Create Clock

# 100 MHz clock (10 ns period)
create_clock -name clk -period 10.0 [get_ports clk]

2. Input / Output Delays

set_input_delay  -clock clk 2.0 [all_inputs]
set_output_delay -clock clk 2.0 [all_outputs]

3. Clock Uncertainty

# 100 ps margin for jitter
set_clock_uncertainty 0.1 [get_clocks clk]

4. False Paths

# Async reset — don't check timing
set_false_path -from [get_ports reset]

5. Multicycle Paths

set_multicycle_path 2 -setup -from [get_pins mult/*]
set_multicycle_path 1 -hold  -from [get_pins mult/*]

Ask AI PRO

Ask AI is a context-aware AI assistant built directly into the IDE. It knows what you're working on — your Verilog source, the last simulation output, synthesis warnings, lint errors, and timing reports — so you can ask questions in plain English without copying and pasting anything.

Requirements

• PRO subscription — upgrade at chipverify.com/pricing
• An API key from Anthropic, OpenAI, or Google Gemini — any one provider is enough

Setting Up Your API Key

1. Click your avatar in the top-right → Settings → Ask AI — API Keys
2. Choose your provider (Anthropic, OpenAI, or Gemini) and paste your key
3. Click Save Key — the key is validated live before being stored
4. The Ask AI panel header will now show BYOK Active

Supported Providers

Token Usage & Budget

Go to Account Settings → Ask AI — API Keys to see how many tokens you've used this month across all Ask AI conversations. Because AI providers don't expose your remaining credit balance via API, you can set a self-declared monthly budget:

1. Enter a token limit in the Monthly Token Budget field (e.g. 1000000 for 1 M tokens)
2. Click Save
3. A progress bar appears showing tokens used / budget (% used) for the current month

The budget is for your own awareness only — it does not hard-stop requests when the limit is reached. Click Clear to remove the budget and show raw usage instead.

Opening Ask AI

Click the gradient Ask AI button in the right-panel tab bar. A fresh chat opens immediately — no setup needed beyond your API key.

Quick Actions

When the chat is empty, five one-click buttons let you jump straight in:

Job Context — What the AI Knows

Every time you complete a simulation, synthesis, PnR, or lint run, that job is automatically loaded as the AI's active context. A coloured pill appears below the chat input showing which job is active:

• SIM — simulation job
• SYNTH — synthesis job
• PNR — place & route job
• LINT — lint job

Only the most recent job is auto-loaded — so if you run synthesis after a simulation, the synthesis job becomes the active context and the previous simulation pill is cleared. This keeps the AI focused on what you just did.

Adding More Jobs to Context

Sometimes you need the AI to look at two jobs at once — for example, to compare simulation output with synthesis warnings, or to understand a timing discrepancy between pre-route and post-route STA. Click the icon next to the job pills to open the job search panel:

1. Browse or search your recent jobs — grouped by type (SIM / SYNTH / PNR / LINT)
2. Click + Add on any job to add it to the active context
3. Jobs already in context are marked ✓ In context
4. Click × on a pill to remove a job from context without clearing the conversation

With multiple jobs in context you can ask things like:

• "My simulation passes but synthesis warns about a latch — why?"
• "Compare the timing from my pre-route and post-route runs"
• "Did the PnR utilization change between these two runs?"

Pulling in Older Runs

Open the job search panel and scroll to find any past run — your full job history is always available. You can ask: "How did I fix the timing violation in my run from yesterday?" and the AI will walk through that specific job's report.

What the AI Sees Automatically

Beyond the active job, every query also includes:

• Your Verilog source — the file currently open in the editor
• Simulation output — stdout and stderr from the active simulation job
• Synthesis log — Yosys warnings and statistics from the active synthesis job
• Lint errors — Verilator warnings from the active lint job
• STA / PPA data — timing and area metrics when a synthesis or PnR job is in context

A small context hint below each response tells you exactly what was included so you can understand why the AI answered the way it did.

What You Can Ask

Debug Simulation Failures

• "My testbench is failing at time 40 ns — what's wrong?"
• "cout is 0 when a=1 b=1 cin=1 but I expect 1 — explain why"
• "What does this error mean: reg 'q' has already been declared"

Understand Synthesis Results

• "Why is Yosys inferring a latch for this always block?"
• "Which of my recent synthesis runs had the best worst-negative slack?"
• "My cell count jumped by 40% — what changed?"

Interpret Timing Reports

• "Explain the critical path from my last synthesis run"
• "Why is the slack negative on this path and how do I fix it?"
• "Compare pre-route and post-route timing for my PnR job"

Learn Verilog Concepts

• "What's the difference between blocking and non-blocking assignments?"
• "When should I use always @(*) vs always @(posedge clk)?"
• "Explain what clock tree synthesis does"

Code Review

Ask "Review this module for common RTL problems" — the AI checks for incomplete sensitivity lists, missing case defaults (latch risk), uninitialized registers, and combinational loops.

Chat History

Each job has its own conversation — switching the active context pill switches the chat. Click the clock icon in the panel header to browse all past conversations. Click any entry to restore it. Click New Chat to start fresh without losing history.

Responses include syntax-highlighted code blocks — Verilog, Python, Bash, and C are all detected automatically.

Tips for Better Answers

• Use quick actions first — they pull exactly the right context automatically
• Be specific about symptoms — describe what value you got vs what you expected, not just "it's broken"
• Ask follow-ups — conversations have memory; "why does that work?" or "show me an example" continue naturally
• Edit a message — hover any of your messages and click the edit icon to refine and resend
• Add context for cross-run questions — use the job search panel to add multiple jobs before asking a comparison question

Removing Your API Key

Go to Account Settings → Ask AI — API Keys and click Remove API Key. The encrypted key is deleted immediately and Ask AI becomes unavailable until a new key is saved.

Learning Sessions

Learning Sessions help you track your progress while working on a design. Every simulation and synthesis run is automatically captured so you can compare "before" and "after" results and understand what each code change did.

Starting a Session

1. Open the Sessions menu — click the Learn item in the navbar and choose "Start New Session"
2. Enter Details — title (required), description, learning objectives, course/assignment IDs
3. Work Normally — run simulations and syntheses; the session records everything automatically

Active Session Indicator

When a session is recording, a centered pill appears in the top navbar showing:

• A pulsing red dot
• REC label in red
• The session name
• An End button to stop recording immediately

This indicator is always visible at the top of the screen regardless of which panel is open, so it's impossible to forget a session is running.

Session Badge in Files Panel

The Files panel header also shows a compact badge with the session name and an × close button as a secondary reminder. Click × to end the session from there too.

Run Gate — Preventing Accidental Runs

When you click Simulate or Synthesize with an active session, a small banner appears confirming that this run will be recorded:

• Continue ▶ — records the run to the session (auto-continues after 3 seconds)
• End Session — stops recording first, then runs normally

This prevents unintentional runs from being logged to a session you forgot was open.

Comparing Runs

Open the Run History panel to see all recorded runs. Each card offers:

• Files — line-by-line diff showing exactly what changed between runs
• Log — full compilation/simulation/STA log for any run
• Compare — two logs side by side
• Analyze — restore that run's full state: editor files, schematic, waveform, and STA report (including constraints.sdc)

STA re-runs are recorded as their own run entries. Clicking Analyze on an STA run restores the timing report in the STA panel and the constraints.sdc file in the editor, so you can see exactly which constraints produced that result.

Ending a Session

You can end the active session from any of these places:

• The End button in the navbar pill (center of toolbar)
• The × button in the Files panel session badge
• The End Session button in the Run History panel header
• The run gate banner that appears when clicking Simulate/Synthesize

Session Actions (Run History Panel)

Challenges

RTL Challenges at chipverify.io/challenges give you a hardware specification and a hidden test harness. Your job: write the Verilog that satisfies it. Submit when your simulation passes — the harness runs a broader suite of vectors to validate your design.

Difficulty Levels

How to Work Through a Challenge

1. Read the specification

   Each challenge page shows the module interface (port list) and a functional description. Read it completely before opening the IDE — understanding the expected behavior up front saves debugging time.

2. Open the challenge in the IDE

   Click Open in IDE to load the challenge stub into a new project. The stub contains the module skeleton with the correct port list — fill in the logic.

3. Write your RTL

   Implement the design. Use Ask AI → Give me a hint if you get stuck — it gives a nudge without revealing the solution.

4. Run lint first

   Press Alt+L to catch width mismatches, sensitivity list issues, and combinational loops before simulation.

5. Simulate against the provided testbench

   Each challenge includes a starter testbench. Run it and confirm your design passes the visible test vectors in the Console output.

6. Submit

   Click Submit Solution on the challenge page. The hidden harness runs edge cases and corner conditions. If it fails, the feedback shows which category of test failed — use that to guide your next iteration.

Tips for Debugging Submissions

• Check reset behavior — many hidden tests start with an asserted reset; ensure your reset logic is synchronous or asynchronous as specified
• Test edge cases manually — add your own test vectors for boundary conditions (zero, max value, overflow) before submitting
• Use Learning Sessions — start a session before you begin; the run history lets you compare your first attempt vs your passing solution
• Run at SS corner — if the challenge includes a timing constraint, validate at the Slow-Slow corner to catch near-miss timing violations
• Check bit widths — a common source of subtle bugs; use Verilator's strict width checking alongside Icarus

Exercises

Guided exercises at chipverify.io/exercises are the structured learning path of ChipVerify. Unlike open-ended challenges, exercises walk you through a concept step by step — each step builds on the last and includes explanation, code to try, and automated checking. Start here if you're new to Verilog or RTL design.

Topic Coverage

How Exercises Work

Each exercise is a self-contained module in the exercises browser. When you open one:

• Concept explanation — what the circuit does and why it matters
• Schematic or timing diagram — visual reference for the expected behavior
• Starter code — a partially-complete module loaded into the IDE for you to fill in
• Step-by-step instructions — numbered tasks that build toward the complete design
• Automated checking — submit to see which test vectors pass or fail
• Worked solution — revealed after you pass (or after three attempts)

Exercise Workflow

1. Browse exercises

   Go to chipverify.io/exercises and filter by topic or difficulty. Completed exercises are marked with a green checkmark.

2. Read the concept page

   Before touching the code, read the explanation and look at the timing diagrams. Understanding the expected waveform is the fastest path to a correct implementation.

3. Open in IDE

   Click Start Exercise. The IDE opens with the starter file pre-loaded in a fresh project — no setup required.

4. Complete each step

   Follow the numbered instructions. Each step is a small, testable increment — don't skip ahead. Run simulation after each step to confirm you're on track.

5. Check your work

   Click Check to run automated tests. Partial credit is shown per step. Use Ask AI → What's wrong? if a test fails unexpectedly.

6. Synthesize (optional)

   For sequential exercises, run synthesis to see your design as a gate-level schematic. Check the PPA — compare a ripple-carry vs carry-lookahead adder to see the area/speed trade-off directly.

Exercises vs. Challenges

Code Examples

The examples library at chipverify.io/examples is a collection of complete, working reference designs. Every example is immediately runnable — click Load in IDE and hit Run Simulation. No editing required. Use them as a starting point, a debugging reference, or just to see how a real design is structured.

Example Categories

Loading an Example

1. Browse the library

   Go to chipverify.io/examples. Use the category filter or search bar to find what you're looking for.

2. Preview

   Click an example card to see the module description, port list, and a snippet of the design before loading.

3. Load in IDE

   Click Load in IDE. This opens the IDE with all files pre-loaded in a new project — the design file, the testbench, and any SDC constraints.

4. Run it

   Press Alt+R. The simulation runs immediately. For examples with waveform data, press Alt+W to open the waveform viewer.

5. Explore and modify

   Change parameters, add test vectors, or restructure the RTL. Because examples load into a fresh project, the original is always available — reload from the examples page anytime.

Using Examples Effectively

Read Before Running

Before clicking Run, read the design file top to bottom. Note the module hierarchy, parameter names, and any comments that explain non-obvious choices. Then run the simulation and match what you see in the waveform to what you expected from reading the code.

Modify and Re-run

The fastest way to understand a circuit is to break it deliberately, then fix it:

• Remove the default from a case statement — see if Verilator catches the latch
• Change a non-blocking assignment (<=) to blocking (=) in an always @(posedge clk) block — observe the race condition
• Shrink a counter width and watch it overflow in the waveform
• Adjust the clock period in constraints.sdc and re-run STA to see when timing fails

Synthesize and Inspect

After simulating, synthesize the example (Synth tab → Run Synthesis). Then:

• Open the Schematic panel — compare the gate-level diagram to the RTL you read
• Click the PPA panel to see cell count, chip area, and estimated frequency
• Double-click a submodule node in the schematic to drill into its hierarchy
• Right-click a flip-flop cell → Show Fan-In Cone to trace the combinational logic feeding that register

Ask AI to Explain

With an example loaded, open Ask AI and use: Explain the concept — it reads the active file and explains the design pattern, why certain constructs are used, and common variations you might encounter. Great for moving from "I can run it" to "I understand it."

Featured Reference Designs

For Instructors

ChipVerify includes a full teaching suite — roster management, assignments with deadlines, an auto-graded gradebook, and engagement alerts — designed to let you run a real lab course with zero infrastructure. Students sign up for a free account and can run simulations, synthesis, and the full RTL-to-GDSII flow from any browser within seconds.

Beyond assigning from the public catalog, you can author your own material from scratch: correctness-graded exercises (your own problem statement, starter code, and testbench) and performance-graded PPA challenges (scored on area, power, and timing — the same style as our built-in Button Debouncer challenge). Anything you create this way stays private to your course by default — visible only to you and students enrolled in a class you've assigned it to.

Once enabled, a My Classes link appears under the Learn menu in the top navigation (in addition to chipverify.com/classes directly). Your dashboard there gives you everything in one place: a My Content area for building your own exercises and challenges, plus four tabs per class — Roster, Assignments, Gradebook, and Engagement.

Creating a Class

Each class gets its own invite code and roster. Create one class per section or semester so you can track students independently.

Step-by-step

1. Go to My Classes from the top navigation
2. Click New Class and enter a name (e.g. "ECE 3150 — Fall 2026") and an optional description or timezone
3. An invite code is generated automatically (format: ABCD-1234)
4. Click Copy join link to get the full enrolment URL
5. Post the link on your LMS, Slack, or email — students click it, sign in (or create a free account), and are added to your roster instantly

Duplicating a Class for a New Semester

At the end of a semester, click Duplicate on any class. This creates a new class with all the same assignments and due dates copied over, but with an empty roster and a fresh invite code. You don't need to rebuild your assignment list from scratch each semester.

Archiving a Class

When a semester ends, click Archive to remove the class from your active list. The roster, gradebook, and all assignment data are preserved — you can un-archive at any time.

My Content — Custom Exercises & Challenges

The My Content area (in the My Classes sidebar) is where you author your own course material instead of picking only from the public catalog. Everything you create here is private — visible only to you and students enrolled in a class you've assigned it to. It supports two kinds of content: correctness-graded exercises and performance-graded (PPA) challenges.

Custom Exercises

Exercises are organised the same way as the public catalog: modules containing individual exercises, graded on whether the simulation output matches a pass pattern.

1. Click Add New Module and give it a name (e.g. "Week 1")
2. Inside the module, click Add Exercise and set a title, difficulty, and point value
3. Click the Edit icon on the new exercise to open the full editor
4. Write the problem statement (rich text, with drag-and-drop image support), starter code, and — importantly — the testbench code
5. Optionally set a custom pass pattern (regex); otherwise the exercise fails on any ERROR/FAIL in simulation output

Custom PPA Challenges

Click New Challenge under Custom Challenges to open the same rich editor used for platform-curated challenges (Quill for the problem description, Monaco for code). You set:

• Design template and testbench (or leave testbench-less for a synthesis-only challenge)
• Target library and clock period for synthesis
• Area and power limits, plus the scoring weight given to each
• Difficulty, points, and tags

New challenges start as a Draft (hidden badge). Use Publish on the card once you're happy with it — you can still edit a published challenge at any time.

Using an Existing Public Challenge Instead

You don't have to build from scratch — when assigning to a class, the challenge picker shows both your own challenges and the public catalog (e.g. Button Debouncer) grouped into separate sections, so you can assign either.

Roster & TAs

Viewing Your Roster

Open a class and go to the Roster tab. You'll see every enrolled student with:

• Username and email
• Role — Student or TA
• Enrolled on — date they joined the class
• Last active — the last time they used the platform

Removing a Student

Click the remove icon next to any student's name. They lose access to class assignments but their ChipVerify account and personal projects are not affected.

Adding a TA

TAs must already have a ChipVerify account. To add one:

1. Go to the Roster tab and click Add TA
2. Enter the TA's email address (must match their ChipVerify account)
3. Click Add — they're immediately granted TA access to this class

TAs can view the full roster and gradebook and see all assignment progress. They cannot create or edit assignments, and they cannot delete the class.

Assignments & Due Dates

The Assignments tab is where you build the work list for your class. It's a single unified table covering both exercises and PPA challenges — each row is tagged with a colored Type badge so you can tell them apart at a glance. You can assign content from the public catalog, or anything you built yourself in My Content.

Adding an Exercise

1. Go to the Assignments tab inside your class
2. Click Add Exercise — a browser opens in a two-column layout
3. Browse by course on the left; exercises appear on the right grouped by module. Click a module header to expand or collapse it
4. Click an exercise to select it, then set a due date
5. Click Assign — it's immediately live for all enrolled students

Adding a Challenge

1. Click Add Challenge next to Add Exercise
2. The picker groups options into My Challenges (your own, including drafts) and Public Challenges (the curated catalog)
3. Pick one, set a due date, and click Assign

Viewing Assigned Work

The Assignments table lists everything you've assigned — name, type, difficulty, points, due date, and a direct link to open it. Click a column header to sort, or use the search box to filter by title.

What Students See

Enrolled students see both exercises and challenges together on their class page (via My Classes), each with its type, due date, and current status (Not Started, In Progress, Completed). Clicking an assignment launches directly into the exercise IDE or the challenge solve page, whichever applies.

Removing an Assignment

Click the remove icon next to an assignment to unassign it. It's removed from the student's list, but any progress they already made is kept.

Gradebook

The Gradebook tab gives you a live view of every student's progress across everything you've assigned — exercises and PPA challenges together. No manual collection needed — scores update automatically as students complete work.

Class Overview (default view)

The default view shows one row per assignment, with a Type badge distinguishing exercises from challenges. Each row shows:

• Name and point value
• Due date
• Completed — a progress bar + count (e.g. "22/30") showing how many students finished
• Avg Score — average points earned across all students
• Not Started — number of students who haven't attempted it yet
• In Progress — number of students who started but haven't passed

Per-Student Drill-Down

Use the student picker dropdown at the top right of the gradebook to switch to a single student's view. This shows:

• Every assigned exercise and challenge (with its Type badge), status, score, and number of attempts
• A total score at the bottom (e.g. "87/100") summing everything assigned

This view is useful for checking a specific student's standing before a one-on-one or grading meeting.

Exporting Grades

Click Export CSV (top right of the gradebook) to download a spreadsheet with one row per student containing their score on each exercise and challenge, total earned, and maximum possible. The CSV can be imported directly into Canvas, Blackboard, or any grade management system.

Score Calculation

Each exercise and challenge has a point value you set when building it. A student earns full points for an exercise when they pass all its test cases, and for a challenge when their submission meets the area/power/timing thresholds you configured. Scores update live — if a student completes something after you export, re-export to get the latest data.

Engagement & Alerts

The Engagement tab surfaces the students and assignments that need your attention — without requiring you to manually check each student's profile.

Inactive Students

At the top you'll see a list of students who haven't logged into ChipVerify in the last 7 days, sorted by how long they've been away. Each entry shows their username and the date they were last active. Use this before a deadline to send a reminder to students who may have fallen behind.

Assignment Roadblocks

This table covers both exercises and challenges together (each row tagged with a Type badge), ranked by which ones have the most students stuck. Each row shows:

• Name and Type (Exercise / Challenge)
• Completed — how many students passed
• Stuck — how many started but are still working
• Avg attempts (stuck) — average number of failed attempts for stuck students. A high number (e.g. 8+) suggests the exercise may need a hint added, the testbench may need clarification, or (for a challenge) the area/power limits may be too tight
• Avg attempts (completed) — how many tries it took students who did pass

Sort by Stuck descending to immediately see which assignment is blocking the most students right now. As with the gradebook, only submissions that actually compiled count toward these attempt numbers.

Students Needing Help

Below the roadblocks table, each student's summary shows how many assignments they've completed out of the total assigned, how many they're stuck on, and their total failed attempts — combined across exercises and challenges — sorted with the most-struggling students first.

Reviewing Student Work

Beyond the gradebook, you can review a student's Learning Session — a time-boxed record of every simulation and synthesis run they made, with full code snapshots, console output, and run-to-run diffs. Students share a session link with you and you get a read-only replay of exactly what they tried.

How Students Share a Session

1. Student starts a Learning Session from the IDE toolbar (the icon)
2. They work — every run is captured automatically
3. When done, they open the Session panel and click Share
4. A unique share link is generated: chipverify.com/?view=TOKEN
5. They paste that link into an LMS submission, email, or chat

What You Can See

When you open a shared session link you can review:

• Every run in sequence — simulation or synthesis, with timestamp
• The code at each run — exactly what the student submitted
• Console output — compilation errors, simulation output, warnings
• Run-to-run diff — what changed between attempt N and N+1, making it easy to trace the student's debugging process

What to Look For

• Runs before first pass — a proxy for how stuck the student got
• Compilation errors they repeated — signals they're not reading tool output
• Diff size — small targeted edits = debugging. Wholesale rewrites between runs = guessing
• Console output — check whether their testbench is actually catching the error they think it is

Teaching Tips & Workflows

First Day of Class

Post the class join link on your LMS on day one. Ask students to enrol, open the IDE, run the "Hello World" simulation from the Exercises page, and confirm it works. You'll immediately know who has a working environment — before your first assignment is due.

Structuring a Lab Around Exercises

Assign a set of exercises from the Assignments tab (e.g. "complete AND gate, OR gate, MUX before Thursday"). Students see the due dates on their exercise page and work through them at their own pace. The gradebook updates in real time — no submission collection needed.

Using the Engagement Tab Weekly

Check the Engagement tab once a week, two or three days before a deadline. Look at the Inactive Students list and send a reminder email to anyone who hasn't logged in. Look at the Assignment Roadblocks table to see which exercise or challenge is blocking the most students — that's the one to go over in class or add a hint to.

Building a Custom PPA Challenge for a Lab

If your course covers low-power or performance-driven design, build a custom challenge in My Content around whatever circuit you're teaching that week — set area/power limits appropriate for the students' skill level, keep it private to your class, and assign it alongside your regular exercises. It shows up in the same gradebook and engagement views as everything else.

Demonstrating the Full Chip Design Flow

Use the platform live in class. Write a counter or shift register, run simulation, open the schematic, run PnR, and show DRC violations. Students follow along in their own browsers simultaneously — no VMs, no licenses, no setup.

Sharing a Starter Project

Build a partially complete module + testbench in the IDE and use Share Code to generate a read-only link. Students fork a copy to their own account and continue from where you left off. No file distribution needed.

Code Examples as Lecture Material

The Code Examples library includes complete reference designs (UART, SPI, I²C, FIFO, priority arbiter). Load any example into the IDE, run it, and walk through the waveform — under 30 seconds, no setup.

Projects

Saving

1. Sign in with your account (required)
2. Click Save or press Ctrl+Shift+S
3. Enter a project name

What Gets Saved

• ✅ All Verilog files (.v, .sv, .sdc)
• ✅ Project description
• ✅ File groups and ordering
• ❌ Simulation results (temporary)
• ❌ Waveform data (too large)

Project Limits

Downloading

Click Save/Load → Download as ZIP to get all files locally — includes Verilog, synthesized netlist, STA report, and VCD if available.

Share Code

Create a permanent shareable link to your code, simulation results, and waveforms.

Creating a Link

1. Click the Share button in the top toolbar
2. Choose what to include: code files, simulation output, waveform data, synthesis results
3. Click Generate Link and copy the URL

Privacy

Account Settings

Access settings via your profile icon → Settings, or navigate to chipverify.io/settings.

Account Information

• Email Address — the email on your account
• User ID — unique identifier (useful for support requests)
• Account Type — FREE or PRO

Appearance

Subscription & Billing

FREE vs PRO

Upgrading

1. Settings → Subscription section → click Upgrade to PRO
2. Complete payment on the secure Stripe checkout page
3. Account upgrades immediately after payment

Keyboard Shortcuts

Code Templates

Verilog Templates

Click Code Templates in the Files panel:

Basic Logic

• AND Gate — 2-input AND
• 2:1 Multiplexer — parameterized

Sequential Logic

• D Flip-Flop — positive edge-triggered with reset
• 4-bit Counter — up counter with reset

State Machines

• Simple FSM — case-statement template with state and next-state logic

Testbenches

• Testbench Skeleton — clock generation, reset, VCD dump, and $finish

Synthesis Templates PRO

In the Synth tab, PRO users can load pre-written synthesis.ys Yosys scripts and constraints.sdc files:

• Technology-Mapped — full synthesis with SkyWater PDK liberty files
• Generic — no library, faster results for quick iteration
• Speed-Optimized — maximize frequency at the cost of area
• Area-Optimized — minimize chip size at the cost of speed
• Fast Synthesis — quick results, minimal optimization passes

Troubleshooting

Simulation

❌ "No testbench found"

Ensure your testbench filename contains test or tb (e.g. counter_tb.v).

❌ Compilation errors

• Check Console for %Error lines — they show file and line number
• Ensure all instantiated modules are defined and compiled in the right order
• Verify port connections match module definitions

❌ Simulation never finishes

Add $finish; to your testbench initial block.

❌ No waveform data

Add to your testbench:

initial begin
    $dumpfile("dump.vcd");
    $dumpvars(0, tb);
end

❌ Still seeing old results after changing code

Click Clear Simulation Cache in the Simulate tab to force a fresh compilation.

❌ Verilator fails but Icarus works

Verilator requires synthesizable RTL. Check for:

• Delay statements (#n) in non-testbench files
• Non-synthesizable constructs (initial blocks in design modules)
• Bit-width mismatches — Verilator is very strict

❌ Module not found / undefined reference

Files may be compiled in the wrong order. Use the Compile Order panel in the Simulate tab to drag modules above the files that instantiate them.

Synthesis

❌ "Failed to generate netlist"

• Check Yosys log in Console for the specific error
• Run lint first — synthesis errors often trace back to RTL issues
• Try the Generic template to isolate whether the issue is RTL or library-related

❌ "No PPA data"

PPA requires Liberty files — use Technology-Mapped synthesis and enable "Run PPA Analysis".

STA

❌ "No synthesized netlist found"

Run synthesis before STA.

❌ "Corner mismatch"

Set the STA corner to match the synthesis corner (both TT, both FF, or both SS).

❌ All slack values are zero

SDC constraints are missing. Create a constraints.sdc file or let STA auto-generate them.

FAQ

General

Q: Do I need to install anything?

A: No. Everything runs in the browser — Icarus Verilog, Verilator, Yosys, and OpenSTA all run on our servers.

Q: Is my code private?

A: Yes. Signed-in users' projects are private. Only code you explicitly share via a Share link is public.

Q: What file size limits apply?

A: Individual files under 1 MB. Total project under 10 MB.

Features

Q: What synthesis tool is used?

A: Yosys with the SkyWater 130nm open-source PDK — the same PDK used in real tapeouts.

Q: What simulators are supported?

A: Icarus Verilog (event-driven) and Verilator (cycle-accurate). Choose in the Simulate tab.

Q: What's the difference between simulation and synthesis?

A: Simulation tests functionality (does your logic produce the right values?). Synthesis maps your RTL to real hardware gates and tells you area, power, and timing.

Q: Why does STA require synthesis first?

A: STA analyzes delays through actual standard cells. RTL code has no gate-level timing information.

Q: Can I download my synthesized netlist?

A: Yes — Save/Load → Download as ZIP includes the netlist, PPA report, STA report, and all source files.

Q: Is this suitable for real chip tapeout?

A: ChipVerify is designed for learning and prototyping. The backend flow uses the same open-source tools (OpenROAD, Magic, Netgen, KLayout) and real SkyWater PDK used by community tapeouts like TinyTapeout and Google MPW. For production tapeout, use commercial EDA tools with your foundry's official PDK.

Backend Flow

Q: What is the difference between synthesis and place & route?

A: Synthesis converts your RTL to a gate-level netlist (which cells, which connections) but doesn't decide where on silicon those cells go. Place & Route physically positions the cells and routes metal wires between them, producing a GDSII file a foundry can manufacture.

Q: Do I need to run synthesis before PnR?

A: Yes. PnR starts from the gate-level netlist produced by synthesis. Run synthesis first, then use the same library and corner for PnR.

Q: Why does the post-route area differ from the synthesis area estimate?

A: Synthesis reports the sum of standard cell areas only. PnR adds filler cells (to fill the core area to 100%), clock tree buffers, hold-fix buffers, and antenna diodes — all of which add area. A 5–15% increase is typical.

Q: Why might post-route timing be better than pre-route timing?

A: Pre-route STA uses wire-load models — statistical estimates of wire length. These tend to over-estimate delay, especially for short wires in dense placements. Post-route STA uses actual extracted RC parasitics from the routed wires, which are often faster.

Q: Why is the SDF scope important for gate-level simulation?

A: VVP uses the scope string to locate the module in the simulation hierarchy where SDF timing should be applied. If the scope is wrong, the SDF is silently ignored and simulation runs at zero delay. If your testbench is module tb and the DUT is instantiated as dut, the scope must be tb.dut.

Q: Can I view the GDSII in a third-party viewer?

A: Yes. Download the GDSII file (DEF button → GDS Download in the PnR panel) and open it in KLayout, Magic, or any other GDSII viewer. The sky130 layer definitions are available from the SkyWater PDK repository.

Q: Why does the GDSII in KLayout look different from the PnR layout viewer?

A: They show the same data but in different visual styles. The in-browser layout viewer draws simplified coloured bounding boxes from the DEF placement file (one rectangle per cell) plus GDS routing layers. KLayout shows the actual transistor-level GDS geometry: nwell, active regions, poly gates, contacts, local interconnect, and all metal routing. Standard cells alternate between N (normal) and FS (flip-symmetric) orientation in adjacent rows — this looks asymmetric in KLayout but is correct physical layout.

Q: What are the coloured extra cells added by PnR that weren't in my RTL?

A: OpenROAD inserts several types of cells automatically:

• Filler cells (grey) — fill_1/2/4/8 placed to complete power/ground rails across the row.
• Tap cells (grey) — tapvpwrvgnd inserted every ~25 µm to prevent CMOS latch-up.
• CTS buffers (green) — clock tree buffers and inverters inserted by Clock Tree Synthesis to balance clock skew.
• Hold-fix buffers (orange) — delay cells inserted to fix hold violations caused by short paths.
• Antenna diodes (violet) — diode cells inserted near long metal wires to prevent gate oxide damage during fabrication.

These are all visible and colour-coded in the post-PnR schematic view.

Q: Can Ask AI compare results across multiple synthesis or PnR runs?

A: Yes. Ask AI uses on-demand tool calls to retrieve job data — it is not limited to the currently visible job. You can ask questions like "which of my synthesis runs had the best setup margin?" or "compare the post-route WNS between my last three PnR jobs" and Ask AI will automatically list and fetch the relevant jobs to answer the question. No copying of job IDs is required.

Q: What does LVS check and why does it matter?

A: LVS (Layout vs Schematic) checks that the routed chip is electrically identical to your gate-level design. It catches open circuits, shorts, or missing connections that can occur if routing fails to connect a net or creates an unintended short between adjacent wires. A DRC-clean design can still fail LVS — both must pass before tapeout.

Account

Q: Why should I sign in?

A: Sign-in enables saving/loading projects, auto-save, synthesis access, and advanced features like Learning Sessions and PPA History.

Q: How long are projects stored?

A: Indefinitely for active accounts. Accounts inactive for 1+ year may be archived.

Q: How do I control the compile order?

A: In the Simulate tab, the Compile Order panel shows all files. Drag them to reorder. Module definitions must come before the files that instantiate them.

Q: Why am I seeing stale simulation results?

A: Results are cached by file hash. The cache should auto-invalidate on code changes. If not, click Clear Simulation Cache in the Simulate tab.