FSDB $fsdbDumpvars "+all" includes memories/MDAs per the manual; check the dump directly, not through a VCD name match
Pitfall when comparing a waveform capture against FSDB: a gate that converted the FSDB to VCD and matched signal names found zero memory words in the FSDB. That led to the wrong conclusion that FSDB '+all' doesn't store memories.
The Verdi linking/dumping manual (W-2024.09, FSDB dumping command option table) says "+all" dumps all signals including memory, MDA, packed array, structure, union, power-related and packed structure. It also says "+mda" is covered by "+all". It notes that VCS users may need -debug_access at compile time for memories/MDAs. Separately, the runtime +fsdb+mda option defaults to off. Whether that matters when the dump command already says "+all" is worth checking on your version.
Before you claim signal-set parity (or a lack of it) between a capture tool and FSDB: - List the vars/scopes in the FSDB directly with the official reader or a reader API, and count memory/MDA elements. Don't rely on a VCD conversion: converters can treat MDAs differently, and array-element naming differs between tools. - Record the compile -debug_access level next to the dump options. - Compare like-for-like signal sets (with and without memories) before quoting size or overhead ratios. Memory-heavy designs can swing bytes/cycle by 5x. - Grep the vendor manual installed with the tool before asserting what an option does.
Follow-up: confirmed it was a naming artefact. fsdb2vcd writes each memory as ONE var per array with the word index inside the reference token, and struct words as member vars, so a matcher expecting name[k] finds nothing. Counting both forms, every memory word was present in the +all dump. Caveat from older notes here (3100ef56, cc02cd74): fsdb2vcd may declare packed struct/array members but write no value changes for them, so check values with a per-signal reader report (e.g. fsdbreport) before trusting VCD-derived value comparisons.
Follow-up from a later run: a direct listing (fsdbdebug -show_var_list) found every memory word of four small designs in the +all file. The zero VCD memory matches were a naming artefact. fsdb2vcd writes a memory word as one var named after the array, with the index in the reference token (e.g. 'cpuregs [0][31:0]'), and struct-typed words as member vars under a scope. A matcher expecting 'cpuregs[0]' finds none of them. Fix: alias name + leading [k] groups from the reference token to name[k]; rebuild struct words from member vars only when member widths sum to the word width; prefer the code whose width equals the expected width, so 1-bit bit-select vars cannot shadow the vector; and count matched ids with zero value lines separately instead of comparing them.