Menu
▾
▴
iverilog-devel
|
From: <by...@nc...> - 2014-08-21 19:44:24
|
---- 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 |
|
From: Christopher B. <cb...@co...> - 2014-08-23 18:26:37
|
Thanks Cary! Chris > Hi Chris, > > Welcome to the list. > > > A brief overview of the development branch. Snapshots are usually fairly stable and directly from the git master is also usually stable though there are occasionally short periods of time when a major addition can create stability issues. We usually fix any instability very quickly. Many people use the latest development release as their primary simulator. > > As I remember Icarus does not currently support interfaces or passing unpacked arrays. The later should be relatively easy to add, but I have not looked at it and there can always be unforeseen implementation complications. > > I believe the current implementation (compiler) just flattens structs and packed arrays so the run time is likely missing the information that we would need to get the FST dump file to support things like you want. LXT2 certainly will not support this and I don't know if the latest VCD specification has enhancements to support this or not. It may not be too complicated to add this to the run time, but like I said earlier often things can get more complicated than expected. > > Cary |
|
From: Christopher B. <cb...@co...> - 2014-08-23 18:29:00
|
Thanks Steve, We are definitely going to continue to use iverilog in the class. We will just come up with some work arounds to enable us to gradually leverage SV support in iverilog as it develops. Thanks for all of your (and the rest of the iverilog contributors) hard work on iverilog -- I am a big fan of using opensource tools in undergraduate education, so it is nice to have access to such a full-featured opensource verilog simulator. Best, Chris > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > I don't think we support dumping things like structs broken > out. They show up in the trace in packed form. Sorry. > > The other thing on your list that is not supported is interfaces. > That is on my list of things to be addressed eventually, but I > (personally) have other more pressing things in front of it. > > It'd be awesome if you choose to use iverilog in your class, > we'll do what we can to support. > > On 08/23/2014 06:55 AM, Christopher Batten wrote: > > > > This is great info -- I think we will definitely move to FST. I > > guess I am still wondering if iverilog supports dumping the > > hierarchy in structs (and interfaces). Maybe one of the iverilog > > developers can chime in? > > > > It is not a show stopper. We can create little helper modules that > > take the struct on an input port essentially "break out" the fields > > internally. We can then liberally instantiate these for debugging > > purposes ... but of course this is less convenient. > > - -- > Steve Williams "The woods are lovely, dark and deep. > steve at icarus.com But I have promises to keep, > > http://www.icarus.com > and lines to code before I sleep, > > http://www.picturel.com > And lines to code before I sleep." > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.19 (GNU/Linux) > > iEYEARECAAYFAlP4qxEACgkQrPt1Sc2b3ikz8ACgji2UWkV5Dar6Vzja65CYr2Sl > YM4AoL7CZCV3n5FTsj0Dn0i0mDYd++Cx > =h3W8 > -----END PGP SIGNATURE----- |
|
From: Christopher B. <cb...@co...> - 2014-08-21 21:19:58
|
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 |
|
From: Cary R. <cy...@ya...> - 2014-08-21 21:29:03
|
Hi Chris, Yes FST should be the preferred format for waveform viewing and VCD should only be used if needed. I already answered the iverilog dumping of structs question in my previous email. Cary On Thursday, August 21, 2014 2:19 PM, 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 ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Iverilog-devel mailing list Ive...@li... https://lists.sourceforge.net/lists/listinfo/iverilog-devel |
|
From: <by...@nc...> - 2014-08-21 22:12:02
|
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 > |
|
From: Christopher B. <cb...@co...> - 2014-08-23 13:55:18
|
This is great info -- I think we will definitely move to FST. I guess I am still wondering if iverilog supports dumping the hierarchy in structs (and interfaces). Maybe one of the iverilog developers can chime in? It is not a show stopper. We can create little helper modules that take the struct on an input port essentially "break out" the fields internally. We can then liberally instantiate these for debugging purposes ... but of course this is less convenient. Best, Chris On Aug 21, 2014, at 6:11 p, by...@nc... wrote: > 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 >> > |
|
From: Stephen W. <st...@ic...> - 2014-08-23 14:54:45
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I don't think we support dumping things like structs broken out. They show up in the trace in packed form. Sorry. The other thing on your list that is not supported is interfaces. That is on my list of things to be addressed eventually, but I (personally) have other more pressing things in front of it. It'd be awesome if you choose to use iverilog in your class, we'll do what we can to support. On 08/23/2014 06:55 AM, Christopher Batten wrote: > > This is great info -- I think we will definitely move to FST. I > guess I am still wondering if iverilog supports dumping the > hierarchy in structs (and interfaces). Maybe one of the iverilog > developers can chime in? > > It is not a show stopper. We can create little helper modules that > take the struct on an input port essentially "break out" the fields > internally. We can then liberally instantiate these for debugging > purposes ... but of course this is less convenient. - -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlP4qxEACgkQrPt1Sc2b3ikz8ACgji2UWkV5Dar6Vzja65CYr2Sl YM4AoL7CZCV3n5FTsj0Dn0i0mDYd++Cx =h3W8 -----END PGP SIGNATURE----- |
Thanks for helping keep SourceForge clean.
X