A plain $fsdbDumpvars(scope) may omit packed structs and memories: check what a reference FSDB contains before using it as a baseline

Lesson from using FSDB files as a size/speed baseline for a custom waveform format on a CPU core.

A scope dump made with a plain $fsdbDumpvars(0, scope) and no struct or memory options held about 7.3k variables. It lacked 1,506 packed struct/enum/union/reg signals, about 69% of the scope's packed bits, and all unpacked memories. A dump of the same design made with +all held those signals, but as flat bit vectors with no struct field names, and it held the memory words.

How to check (documented FsdbReader API only): walk the tree (scope/var callbacks), record each variable's full hierarchical name, type and width, and diff it against the design's own signal list from a VPI walk. Also compare change counts per idcode against fsdbdebug's stored list: the reader can expose reader-computed secondary signals that aren't stored, and a few stored idcodes may not be reachable through the tree.

Consequences for comparisons: - Comparing against what an FSDB holds is fair like-for-like, but don't call it 'full state'. - Size claims should say whether memories, structs and reader-computed signals are included on each side. A stored-only comparison (restricted to the idcodes FSDB stores) can move a ratio a lot. Here it went from about -5% to about -26% for the same format, because the all-signal row also stored computed signals FSDB never stores. - Field layout of packed structs may be missing from the tree even when the bits are dumped.