SV Arch View

See a SystemVerilog design as nested blocks, straight from its file list: each instance is a rectangle that holds its children. There are no ports or wires. The view shows what is inside what, and each block jumps to its source.

• Point it at a file list and the top is found for you. Verilator elaborates the design (--json-only), so generate loops are unrolled and parameters resolved, as they are in a real build.
• Hierarchy side panel. The SV Arch view in the activity bar lists every instance under the top. Click one to show it in the diagram. Use the inline buttons to zoom the diagram into it or open its module definition.
• Save it, reopen it. Save writes a .svarch file with the file list, tops, defines, zoom and expanded blocks, plus the elaborated hierarchy. Opening that file brings back the diagram and the side panel at once, with no elaboration step.

Requirements

Verilator 5.x on PATH, or set svArch.verilator.

Use

In the diagram, click a block to expand or collapse it and double-click to zoom into it. Click the grey module name to open its definition, and alt-click a block to open the line that instantiates it. Repeated instances of one module (gen_tile[0..83].i_core) show their first three side by side and then a …+81 chip; click it to draw them all, and less to fold them again. depth ±, group arrays and find are in the header. Clicking a block also selects it in the side panel.

In the side panel, click an instance to reveal and outline it in the diagram. The inline buttons zoom the diagram into it and open its definition. The context menu adds Open Instantiation and Copy Instance Path. Arrays of the same module (gen_tile[0..83].i_core ×84) fold into one node, the same way the diagram groups them.

Lists that are fragments

Many lists name a single module and leave out what it depends on. npu_dma.f, for example, names npu_dma.sv but none of the packages it imports. When Verilator reports something missing (a package, a module, an include or a macro), SV Arch finds where the workspace defines it, adds that file and runs Verilator again. This repeats until the list elaborates. It follows chains of dependencies, such as a package that imports another package.

• Several definitions of one name. Some names are defined in more than one file, such as a config package with one variant per configuration. The pick goes to the definition nearest the list, and the rest are kept as alternatives. The diagram's status line shows "+N files from workspace". Click it, or use Found Dependencies…, to switch to another definition. The switch is saved in the .svarch. The svArch.prefer setting (e.g. ["dense64x64"]) picks a variant without switching each time.
• Fragments that fail for other reasons. A fragment can still fail because of file order or configuration, not a missing file. It is then retried inside the nearest checked-in lists that include it with -f, keeping its own top. For example, clusters.f is elaborated inside clusters_attention4x128.f. Context… picks that enclosing list yourself.

Turn these off with svArch.autoResolve / svArch.autoContext.

What a list can say about itself

Two header comments in the list you open take priority over any guessing:

// Top module: cva6, npu_cvxif_top            tops to draw, side by side
// Top module: cheshire_soc #(.Cfg(cheshire_pkg::DefaultCfg))
// Context: ../../local_verif2x2.f             the list this one compiles inside

• A Top module: with #(...) is elaborated through a one-line wrapper that SV Arch writes into its own work directory, so no RTL is added to your repo.
• With Context:, the tops are elaborated inside that list. If a top still cannot elaborate on its own there, for example because its type parameters only make sense when a parent sets them, the context's own top is elaborated instead. The drawing then starts at the first instance of the module, exactly as that parent instantiates it.
• A trailing (reason) on a directive line is ignored.
• A list with no modules is linted, and its packages are drawn as blocks.
• A list with no sources at all (only include directories and defines) says so instead of failing.

How the top is chosen

With no Top module: line, a candidate is any module in the list that no other source in the list names. Each candidate is scored on two things: how many -f levels below the list you opened its file is named, and how many of the list's modules it reaches through textual instantiation.

• The candidates the list was written for sit near it. Leftover modules from vendored IP sit deeper. The non-leaf candidates at the shallowest level, plus the substantial ones one level below, are drawn side by side. This covers a die list of cluster blocks with no die top. At most svArch.maxAutoTops are drawn this way (default 6).
• If there are more than that, the likeliest single candidate is used. If it fails to elaborate, the next substantial candidate is tried. A failed real top is reported as an error rather than replaced by a stray leaf.

Top… lists every candidate with its depth and reach.

.svarch format

This is JSON. The settings are at the top and easy to read (flist, tops, defines, view, savedAt). The cached model follows on one line. A path near the .svarch file is stored relative to it, so the file can be checked in next to the list. A path that climbs far out stays absolute. To see the raw file, use Reopen Editor With… → Text Editor.

Settings

The Output ▸ SV Arch channel logs each elaboration: which top was tried and Verilator's errors.

Develop

npm install          # jsdom, for the webview test only
npm test             # fixture design; or: node test/run.js path/to/list.f
npm run package      # builds sv-arch-view-<version>.vsix
code --install-extension sv-arch-view-<version>.vsix

There is no build step. The extension is plain JavaScript under src/, and the diagram page is media/view.html.