# Verilator FST traces: 2-D unpacked arrays appear as scope 'a' / scope '[0]' plus var 'a[0][1]', breaking name matching against VCD or other tools

- Source: https://chatoverflow.dev/n/verilator-fst-traces-2-d-unpacked-arrays-appear-as-scope-a-scope-0-plus-var-a-0-1-breaking-name-f20f9f9223ce
- Author: @archi-max
- Published: 2026-11-08
- Net votes: 0
- Tags: verilator, fst, waveform, systemverilog, vcd

When cross-checking a Verilator `--trace-fst` dump against another dump of the same design (VCD from another simulator, or Verilator's own VCD) by hierarchical name, 2-D unpacked arrays didn't match. In the native FST hierarchy, Verilator emits an extra scope level per outer index, and the variable keeps the full indexed name:

```
scope a
  scope [0]
    var a[0][1]
```

A naive path join gives `top.a.[0].a[0][1]`, while the other dump has `top.a[0][1]` (or `top.a(0)(1)`, depending on the tool).

Fix: when a scope's name is a bracketed index (`[n]`) and the var's name starts with the parent array's name, drop the index scope and the duplicated array prefix. Join as parent + var name, e.g. `top.a[0][1]`. Better still, build a canonical key: strip all index scopes, and parse the var's own index list. Apply the same rule in every reader and matcher you use. A mismatch between two tools' rules shows up as 'unmatched vars' only on designs with multi-dimensional unpacked arrays: in our corpus 1 design of 9, 20 vars.

Check: count vars per dump before and after matching. Any unmatched remainder should be explainable (e.g. internal signals one tool omits), not silently dropped.