Re: [Iverilog-devel] Dumping SV structs and viewing them with gktwave

[<by...@nc...>]

Hi Chris,

gtkwave treats them as different hierarchy types so there's no special delimiter character.  Simulators are going to dump them however they dumped them.  I tried to do things the FSDB way so I could use the same gtkwave save files between FSDB and FST.

FST loads/initializes much faster and is smaller than VCD so I'd say go with FST.  Writer speed is more-or-less the same in Icarus.  If anyone needs VCD, fst2vcd can always be run.

-Tony


-rw-rw-r--.  1 bybell bybell   60319666 Aug 21 16:56 verilog.fsdb
-rw-rw-r--.  1 bybell bybell   20412599 Aug 20 15:22 verilog.fst
-rw-rw-r--.  1 bybell bybell 1590425383 Aug 21 16:47 verilog.vcd


521:/tmp/q> time gtkwave verilog.fst --exit

GTKWave Analyzer v3.3.62 (w)1999-2014 BSI

FSTLOAD | Processing 365208 facs.
FSTLOAD | Built 256310 signals and 108898 aliases.
FSTLOAD | Building facility hierarchy tree.
FSTLOAD | Sorting facility hierarchy tree.
Exiting early because of --exit request.
0.518u 0.149s 0:00.89 73.0%	0+0k 21864+15800io 83pf+0w

522:/tmp/q> time gtkwave verilog.vcd --exit

GTKWave Analyzer v3.3.62 (w)1999-2014 BSI

Warning! File size is 1516 MB.  This might fail in recoding.
Consider converting it to the FST database format instead.  (See the
vcd2fst(1) manpage for more information.)
To disable this warning, set rc variable vcd_warning_filesize to zero.
Alternatively, use the -o, --optimize command line option to convert to FST
or the -g, --giga command line option to use dynamically compressed memory.

[0] start time.
[18199000] end time.
Exiting early because of --exit request.
130.007u 9.674s 2:24.69 96.5%	0+0k 1415704+0io 6pf+0w


---- Christopher Batten <cb...@co...> wrote: 
> 
> Hi Tony,
> 
> Great -- so it sounds like gtkwave has support for hierarchy in structs when reading both VCD (using some kind of hierarchy delimiter?) and FST. So the issue is not with gtkwave but instead with iverilog.
> 
> So I guess the question is then, can iverilog generate dumping the hierarchy in structs? or maybe this is planned for the future?
> 
> Thanks!
> Chris
> 
> ps -- Also sounds like we should either use VCD for portability or FST as our primary dump formats ...
> 
> On Aug 21, 2014, at 3:44 p, by...@nc... wrote:
> 
> > ---- ive...@li... wrote: 
> > 
> >> These other file formats have the same issue. They do not show the
> >> hierarchy. I did notice this in the gtkwave ChangeLog:
> >> 
> >> 3.3.48? 04aug13 ...
> >> ? ? ? ? ? ? ? ?  Added support for SV structures, unions, classes,
> >> ? ? ? ? ? ? ? ?  packages, programs, and interfaces.
> >> ? ? ? ? ? ? ? ?  ...
> > 
> > Chris,
> > 
> > Your simulator needs to support dumping them.  For example, for my day job I use VCS and it writes those hierarchy types to an FSDB file.  If I convert it to FST using vcd2fst (with the FsdbReader libraries linked in), they're visible exactly the same as in the FSDB.  I used FSDB's support as a model for FST's.
> > 
> > Note that the VCD parsers in gtkwave do support additional (non-1364 architected) hierarchy types and they all have their own special icons in the SST:
> > 
> > case 'm':       ttype = TREE_VCD_ST_MODULE; break;
> > case 't':       ttype = TREE_VCD_ST_TASK; break;
> > case 'f':       ttype = (GLOBALS->yytext_vcd_recoder_c_3[1] == 'u') ? TREE_VCD_ST_FUNCTION : TREE_VCD_ST_FORK; break;
> > case 'b':       ttype = TREE_VCD_ST_BEGIN; break;
> > case 'g':       ttype = TREE_VCD_ST_GENERATE; break;
> > case 's':       ttype = TREE_VCD_ST_STRUCT; break;
> > case 'u':       ttype = TREE_VCD_ST_UNION; break;
> > case 'c':       ttype = TREE_VCD_ST_CLASS; break;
> > case 'i':       ttype = TREE_VCD_ST_INTERFACE; break;
> > case 'p':       ttype = (GLOBALS->yytext_vcd_recoder_c_3[1] == 'r') ? TREE_VCD_ST_PROGRAM : TREE_VCD_ST_PACKAGE; break;
> > 
> > ...forget about support in LXT, LXT2, etc.  They're old formats well over 10 years old not really worth extending.  FST can store a lot more useful information.  Looking at fstapi.h shows what is possible.  It supports VHDL as well (e.g., for the nvc compiler) so it is more flexible than the other formats.
> > 
> > -Tony
>