Menu
▾
▴
iverilog-devel — Conversations on matters of Icarus Verilog development
You can subscribe to this list here.
| 2008 |
Jan
(98) |
Feb
(33) |
Mar
(60) |
Apr
(126) |
May
(186) |
Jun
(65) |
Jul
(19) |
Aug
(95) |
Sep
(86) |
Oct
(81) |
Nov
(46) |
Dec
(87) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(47) |
Feb
(79) |
Mar
(138) |
Apr
(44) |
May
(113) |
Jun
(133) |
Jul
(59) |
Aug
(84) |
Sep
(87) |
Oct
(65) |
Nov
(51) |
Dec
(141) |
| 2010 |
Jan
(63) |
Feb
(22) |
Mar
(28) |
Apr
(41) |
May
(59) |
Jun
(18) |
Jul
(7) |
Aug
(11) |
Sep
(85) |
Oct
(28) |
Nov
(51) |
Dec
(16) |
| 2011 |
Jan
(29) |
Feb
(35) |
Mar
(65) |
Apr
(106) |
May
(58) |
Jun
(8) |
Jul
(34) |
Aug
(52) |
Sep
(15) |
Oct
(32) |
Nov
(81) |
Dec
(69) |
| 2012 |
Jan
(50) |
Feb
(18) |
Mar
(47) |
Apr
(21) |
May
(12) |
Jun
(27) |
Jul
(4) |
Aug
(31) |
Sep
(15) |
Oct
(31) |
Nov
(2) |
Dec
(13) |
| 2013 |
Jan
(6) |
Feb
(1) |
Mar
(4) |
Apr
(7) |
May
(30) |
Jun
(7) |
Jul
(53) |
Aug
(60) |
Sep
(30) |
Oct
(38) |
Nov
(20) |
Dec
(12) |
| 2014 |
Jan
(8) |
Feb
(21) |
Mar
(15) |
Apr
(13) |
May
(1) |
Jun
(5) |
Jul
(23) |
Aug
(57) |
Sep
(7) |
Oct
(9) |
Nov
(32) |
Dec
(45) |
| 2015 |
Jan
(35) |
Feb
(16) |
Mar
(29) |
Apr
(20) |
May
(55) |
Jun
(37) |
Jul
(5) |
Aug
(25) |
Sep
(2) |
Oct
(3) |
Nov
(6) |
Dec
(8) |
| 2016 |
Jan
(23) |
Feb
(15) |
Mar
(39) |
Apr
(9) |
May
(4) |
Jun
(11) |
Jul
(5) |
Aug
(1) |
Sep
(1) |
Oct
(3) |
Nov
(12) |
Dec
(1) |
| 2017 |
Jan
(1) |
Feb
(4) |
Mar
(7) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(13) |
Nov
(6) |
Dec
(4) |
| 2018 |
Jan
(26) |
Feb
(4) |
Mar
(5) |
Apr
(6) |
May
(1) |
Jun
(2) |
Jul
(9) |
Aug
|
Sep
(1) |
Oct
(5) |
Nov
|
Dec
(1) |
| 2019 |
Jan
(8) |
Feb
|
Mar
(6) |
Apr
|
May
|
Jun
(6) |
Jul
|
Aug
(40) |
Sep
(7) |
Oct
(23) |
Nov
(16) |
Dec
(8) |
| 2020 |
Jan
(3) |
Feb
(15) |
Mar
|
Apr
|
May
(27) |
Jun
(7) |
Jul
(2) |
Aug
(9) |
Sep
(32) |
Oct
(23) |
Nov
(6) |
Dec
(3) |
| 2021 |
Jan
(10) |
Feb
(1) |
Mar
(4) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
(3) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
(2) |
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Maciej S. <mac...@ce...> - 2014-09-02 08:16:19
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I would like to ask for your opinion about executing the ivtest suite on parallel cores. I have modified the vvp_reg.pl script [1], so it can use multiple instances of vvp at the same time. The script uses Parallel::ForkManager (available in CPAN) to run iverilog & vvp instances in separate processes to decrease the time required to perform tests on modern CPUs. I have managed to go down from ~1 minute to ~15 seconds on 8-core i7 with SSD. The approximate performance boost increases linearly up to 4 cores, then the difference becomes insignificant. You may specify the number of used processes by modifying the CPUS environmental variable, e.g. "CPUS=8 ./par_vvp_reg.pl" runs with 8 processes. Otherwise the number of available cores is autodetected (works only in Linux, relies on /proc/cpuinfo). Unfortunately, there are drawbacks too: * I modified fscanf* tests, because they were using the same file and therefore stayed in conflict. It does not change results for the default vvp_reg.pl script. It is an example of restrictions that test writers would have to obey. * The output is not fully compatible with the default output stored in the repository. I decided to sort the test results in lexical order, otherwise the order would be random each run (depends on the time when a test ends). * There are two tests (pr2509349a & sys_func_task_error) that I could not fix. I guess this might be a result of changing the iverilog output file name from vsim to $tname.vsim (to avoid conflicts). I did not modified them, because I do not want to break the default test scripts. * Output files are saved in the main directory, they are removed at the end of the script. I do not remove ivl_vhdl_work directory between tests, because it could be used in another process. More elegant solution would be to use separate directories. If you think this is completely wrong - please let me know. * This is the first time I write code in Perl, therefore I am not sure if everything is done in accordance with the art. With all the mentioned shortcomings, I think that it might be a good tool for quick, preliminary checks that could save developer's time. What do you think? Regards, Orson [1] https://github.com/orsonmmz/ivtest/tree/parallel_test -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUBXzJAAoJEBRwGu1hpbJ1etMIAJyQSFeF0/p4YWlBQgpWQPml NIv2YZeKlCQHYSYfNFDIVkevnfCSNXvv6+4l0BWy4F66yfOJiZ8Y01KOH/sPWg11 2NLfnlYxbMNKLpnvERsxp6NVe41ylxjg/QPS9RFqg4NvXEAhbIW4rtd9wT1GRG3y 1+tSj4IIrC0PrVS7t0vB18dA/MB1X38aiP8yRav0EzZoRPGQHKT+yhvuoesfjtbO fD10GPqjaZnVTK+2TBfh7R00XwwVgIVuxaqall78OuKk5s1Xr5nWD7XZjsGSQGRu S/gjOtd77KSTXRNq+1jkOf/DR1DhVsBXLtaSk5tvLn1JJtjS431vMyxXxro7bjo= =w7yz -----END PGP SIGNATURE----- |
|
From: Iztok J. <izt...@gm...> - 2014-08-29 17:54:38
|
$ irun sv_foreach1.sv
irun: 14.10-s003: (c) Copyright 1995-2014 Cadence Design Systems, Inc.
ncsim> run
FAILED -- foo[0][7] == xxxxx
Simulation complete via $finish(1) at time 0 FS + 0
./sv_foreach1.sv:41 $finish;
ncsim> exit
$ irun sv_foreach2.sv
irun: 14.10-s003: (c) Copyright 1995-2014 Cadence Design Systems, Inc.
ncsim> run
ncsim: *E,TRNULLID: NULL pointer dereference.
File: ./sv_foreach2.sv, line = 52, pos = 8
Scope: main
Time: 0 FS + 0
./sv_foreach2.sv:52 if (foo[ia][ib].a !== ia[1:0] || foo[ia][ib].b !==
ib[2:0]) begin
ncsim> exit
$ irun sv_foreach3.sv
irun: 14.10-s003: (c) Copyright 1995-2014 Cadence Design Systems, Inc.
file: sv_foreach3.sv
for (idx1 = 0 ; idx1 < 4 ; idx1 = idx1+1) begin
|
ncvlog: *E,UNDIDN (sv_foreach3.sv,65|10): 'idx1': undeclared identifier
[12.5(IEEE)].
for (idx1 = 0 ; idx1 < 4 ; idx1 = idx1+1) begin
|
ncvlog: *E,UNDIDN (sv_foreach3.sv,65|21): 'idx1': undeclared identifier
[12.5(IEEE)].
for (idx1 = 0 ; idx1 < 4 ; idx1 = idx1+1) begin
|
ncvlog: *E,UNDIDN (sv_foreach3.sv,65|32): 'idx1': undeclared identifier
[12.5(IEEE)].
for (idx1 = 0 ; idx1 < 4 ; idx1 = idx1+1) begin
|
ncvlog: *E,UNDIDN (sv_foreach3.sv,65|39): 'idx1': undeclared identifier
[12.5(IEEE)].
for (idx2 = 0 ; idx2 < 7 ; idx2 = idx2+1)
|
ncvlog: *E,UNDIDN (sv_foreach3.sv,66|13): 'idx2': undeclared identifier
[12.5(IEEE)].
for (idx2 = 0 ; idx2 < 7 ; idx2 = idx2+1)
|
ncvlog: *E,UNDIDN (sv_foreach3.sv,66|24): 'idx2': undeclared identifier
[12.5(IEEE)].
for (idx2 = 0 ; idx2 < 7 ; idx2 = idx2+1)
|
ncvlog: *E,UNDIDN (sv_foreach3.sv,66|35): 'idx2': undeclared identifier
[12.5(IEEE)].
for (idx2 = 0 ; idx2 < 7 ; idx2 = idx2+1)
|
ncvlog: *E,UNDIDN (sv_foreach3.sv,66|42): 'idx2': undeclared identifier
[12.5(IEEE)].
if (foo[idx1][idx2] != null) begin
|
ncvlog: *E,UNDIDN (sv_foreach3.sv,67|18): 'idx1': undeclared identifier
[12.5(IEEE)].
if (foo[idx1][idx2] != null) begin
|
ncvlog: *E,UNDIDN (sv_foreach3.sv,67|24): 'idx2': undeclared identifier
[12.5(IEEE)].
module worklib.main:sv
errors: 10, warnings: 0
ncvlog: *F,NOTOPL: no top-level unit found, must have recursive instances.
irun: *E,VLGERR: An error occurred during parsing. Review the log file for
errors with the code *E and fix those identified problems to proceed.
Exiting with code (status 2).
$ irun sv_queue3.sv
irun: 14.10-s003: (c) Copyright 1995-2014 Cadence Design Systems, Inc.
ncsim> run
PASSED
ncsim: *W,RNQUIE: Simulation is complete.
ncsim> exit
|
|
From: Javier S. <jav...@gm...> - 2014-08-28 11:13:21
|
Dear all, I sent a preliminary proposal to the FOSDEM people to organize a FOSS EDA dev room [1] in FOSDEM 2015, to be held in Brussels, Belgium on 31 January and 1 February 2015. The goal is to bring together people working in different FOSS EDA projects so they can present the status and plans of the projects and identify opportunities for collaboration. I received their answer today. They say a FOSS EDA dev room would indeed make a lot of sense. Before they can evaluate the proposal fully, they would like to see a potential list of subjects and speakers. I have already contacted people in the KiCad dev list, and I am pretty sure KiCad will be well covered. If any of you would be interested in attending this event and speaking, please get in touch with me [2]. I know some of you are involved in other FOSS EDA efforts (GEDA, GNUCAP, QUCS, NGSPICE...). I would be very grateful if you could share this message with those communities too. Unfortunately there isn't a lot of time to complete this exercise. I need to send them an updated proposal by the deadline of 15 September. Thanks in advance for your help. Cheers, Javier [1] https://fosdem.org/2015/news/2014-07-01-call-for-participation/ [2] https://phonebook.cern.ch/phonebook/#personDetails/?id=476608 |
|
From: Stephen W. <st...@ic...> - 2014-08-25 18:57:29
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You know what? That's working out pretty well. Thanks! On 08/25/2014 11:18 AM, Victor Lyuboslavsky wrote: > FYI. Riviera-PRO and ModelSim are available on > www.EDAPlayground.com <http://www.EDAPlayground.com> so we could do > some sanity checking there. They're not Big-2, but should give some > preliminary data :) > > For example, sv_foreach1.sv <http://sv_foreach1.sv> results are at > http://www.edaplayground.com/x/XLr # KERNEL: FAILED -- foo[0][7] == > xxxxx > > -Victor > > > On Mon, Aug 25, 2014 at 12:14 PM, Stephen Williams > <st...@ic... <mailto:st...@ic...>> wrote: > > > Hi folks, > > I'm working on some more complex issues of foreach loops and queue > assignments, and I would once again like to get a sanity check of > the attached programs to make sure I properly understand the tested > behaviors. > > Can someone with access to Big-N SV tools try the attached > examples? > > Thanks! > > > ------------------------------------------------------------------------------ > > Slashdot TV. > Video for Nerds. Stuff that matters. http://tv.slashdot.org/ > _______________________________________________ Iverilog-devel > mailing list Ive...@li... > <mailto:Ive...@li...> > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > > > > > ------------------------------------------------------------------------------ > > 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 > - -- 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) iEYEARECAAYFAlP7hxAACgkQrPt1Sc2b3ilhPACgr+PHlt0e125acBtguU4RFJ66 cWcAoNJdP3ZMGom0djrBtW8SWmyIu7tr =XxXN -----END PGP SIGNATURE----- |
|
From: Victor L. <vi...@vi...> - 2014-08-25 18:31:23
|
FYI. Riviera-PRO and ModelSim are available on www.EDAPlayground.com so we could do some sanity checking there. They're not Big-2, but should give some preliminary data :) For example, sv_foreach1.sv results are at http://www.edaplayground.com/x/XLr # KERNEL: FAILED -- foo[0][7] == xxxxx -Victor On Mon, Aug 25, 2014 at 12:14 PM, Stephen Williams <st...@ic...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Hi folks, > > I'm working on some more complex issues of foreach loops and > queue assignments, and I would once again like to get a sanity > check of the attached programs to make sure I properly understand > the tested behaviors. > > Can someone with access to Big-N SV tools try the attached examples? > > Thanks! > > - -- > 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) > > iEYEARECAAYFAlP7bwEACgkQrPt1Sc2b3ikTmACeJ4cjvLLgHE3q8zZISQXDu+CI > ZVwAoJBL5L8UChFVLLaJ7RD7ou+4Xmy5 > =UiBB > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------------ > 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: Stephen W. <st...@ic...> - 2014-08-25 17:54:56
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anybody here thinking of attending this event? Looks like I'll have time this Thursday and am thinking of attending. Thursday, Aug 29 @ 7:15pm Round Table Pizza 860 Old San Francisco Road Sunnyvale CA 94086 (408) 245-9000 http://www.roundtablepizza.com/ - -- 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) iEYEARECAAYFAlP7eGYACgkQrPt1Sc2b3ikEJACfQW9+tClGjA9PiVTjAVzNz9SI g/AAn1E8dzESQhBYNqBEK05S23llDzCp =/LhW -----END PGP SIGNATURE----- |
|
From: Stephen W. <st...@ic...> - 2014-08-25 17:14:54
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks, I'm working on some more complex issues of foreach loops and queue assignments, and I would once again like to get a sanity check of the attached programs to make sure I properly understand the tested behaviors. Can someone with access to Big-N SV tools try the attached examples? Thanks! - -- 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) iEYEARECAAYFAlP7bwEACgkQrPt1Sc2b3ikTmACeJ4cjvLLgHE3q8zZISQXDu+CI ZVwAoJBL5L8UChFVLLaJ7RD7ou+4Xmy5 =UiBB -----END PGP SIGNATURE----- |
|
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-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: 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----- |
|
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: <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: 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: 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: <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: Cary R. <cy...@ya...> - 2014-08-21 19:13:02
|
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 On Thursday, August 21, 2014 9:20 AM, Christopher Batten <cb...@co...> wrote: Hi everyone, This is my first time posting to this list. I teach an undergraduate course in computer architecture at Cornell University: http://www.csl.cornell.edu/courses/ece4750/2013f The course includes a significant lab component where students gradually design, implement, test, and evaluate a complete multicore system capable of running real parallel applications at the register-transfer level. The course used to use commercial Verilog simulators, but four years ago we switched to using iverilog and gtkwave. So far we have stuck to the most recent stable iverilog release (i.e., 0.9.7). Having undergraduate students use opensource tools is important to me, and so far it really has worked out beautifully. This fall we are experimenting with using a few limited SystemVerilog constructs to help simplify the code and expose students to SystemVerilog design features. We have our own simple unit test framework, so this would only be for SV design features not SV verification features. It looks like the SV design features supported by the iverilog development branch of have come a long way. I am specifically thinking of integrating simple packed structures, enums, passing unpacked arrays through ports, and very simple interfaces (just bundling ports, no logic in the interface). After skimming through the test cases in the ivtest repo (https://github.com/steveicarus/ivtest) it looks like much of this might already be supported in iverilog. I have two initial questions. First, when using the iverilog development branch is it recommended that we stick to the snapshots (e.g., s20140801) because they are a little more stable than the master branch? Second, is the ability to dump structs to one of the trace formats and then view those structs in gtkwave currently supported? I made a few small changes to the struct1.v test in the ivltests repo. I added the appropriate dumpfile/dumpvar system tasks and then added some delays: https://gist.github.com/cbatten/b7303bc8327102326059 I am using the s20140801 snapshot of iverilog and version 3.3.58 of gtkwave. I compile and run the test like this: % iverilog -g2012 -o struct1 struct1.v % ./struct1 % gtkwave struct1.vcd When I open the resulting VCD file in gtkwave it shows the two packed structs as flat vectors with no hierarchy, i.e., I cannot view the fields within the struct. I also tried the LXT2 and FST file formats like this: % ./struct1 -lxt2 % cp struct1.vcd struct1.lxt % gtkwave struct1.lxt % ./struct1 -fst % cp struct1.vcd struct1.fst % gtkwave struct1.fst 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. ... Which made me hopeful that this would work. Am I doing something wrong, or is this currently not supported? Thanks in advance your help! Best, Chris ---------------------- Christopher F. Batten Assistant Professor Computer Systems Laboratory School of Electrical and Computer Engineering Cornell University email : cb...@co... web : http://www.csl.cornell.edu/~cbatten addr : 323 Rhodes Hall, Ithaca, NY 14853 cell : (617) 780-6222 ------------------------------------------------------------------------------ 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: Christopher B. <cb...@co...> - 2014-08-21 16:17:02
|
Hi everyone, This is my first time posting to this list. I teach an undergraduate course in computer architecture at Cornell University: http://www.csl.cornell.edu/courses/ece4750/2013f The course includes a significant lab component where students gradually design, implement, test, and evaluate a complete multicore system capable of running real parallel applications at the register-transfer level. The course used to use commercial Verilog simulators, but four years ago we switched to using iverilog and gtkwave. So far we have stuck to the most recent stable iverilog release (i.e., 0.9.7). Having undergraduate students use opensource tools is important to me, and so far it really has worked out beautifully. This fall we are experimenting with using a few limited SystemVerilog constructs to help simplify the code and expose students to SystemVerilog design features. We have our own simple unit test framework, so this would only be for SV design features not SV verification features. It looks like the SV design features supported by the iverilog development branch of have come a long way. I am specifically thinking of integrating simple packed structures, enums, passing unpacked arrays through ports, and very simple interfaces (just bundling ports, no logic in the interface). After skimming through the test cases in the ivtest repo (https://github.com/steveicarus/ivtest) it looks like much of this might already be supported in iverilog. I have two initial questions. First, when using the iverilog development branch is it recommended that we stick to the snapshots (e.g., s20140801) because they are a little more stable than the master branch? Second, is the ability to dump structs to one of the trace formats and then view those structs in gtkwave currently supported? I made a few small changes to the struct1.v test in the ivltests repo. I added the appropriate dumpfile/dumpvar system tasks and then added some delays: https://gist.github.com/cbatten/b7303bc8327102326059 I am using the s20140801 snapshot of iverilog and version 3.3.58 of gtkwave. I compile and run the test like this: % iverilog -g2012 -o struct1 struct1.v % ./struct1 % gtkwave struct1.vcd When I open the resulting VCD file in gtkwave it shows the two packed structs as flat vectors with no hierarchy, i.e., I cannot view the fields within the struct. I also tried the LXT2 and FST file formats like this: % ./struct1 -lxt2 % cp struct1.vcd struct1.lxt % gtkwave struct1.lxt % ./struct1 -fst % cp struct1.vcd struct1.fst % gtkwave struct1.fst 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. ... Which made me hopeful that this would work. Am I doing something wrong, or is this currently not supported? Thanks in advance your help! Best, Chris ---------------------- Christopher F. Batten Assistant Professor Computer Systems Laboratory School of Electrical and Computer Engineering Cornell University email : cb...@co... web : http://www.csl.cornell.edu/~cbatten addr : 323 Rhodes Hall, Ithaca, NY 14853 cell : (617) 780-6222 |
|
From: Cary R. <cy...@ya...> - 2014-08-19 21:18:48
|
Yes, CVC is ignoring any delay when a continuous assignment or gate are driven by a constant value. Cary On Tuesday, August 19, 2014 2:44 AM, Evan Lavelle <sa2...@cy...> wrote: What are you actually seeing? Presumably CVC is showing 1 on both ca and gt at time 1? If so, that would be pretty hard to justify. 11.6.1 is definitive on continuous assignments at time 0 - the 'continuous assignment process' is evaluated at time 0, and an active update event is added to the event queue. On the other hand, I'm pretty sure that this was not actually specified prior to 2005, so it would be interesting to see what XL does. I'd be very surprised if XL got this 'wrong', though - continuous assignments were always meant to model combinatorial logic correctly, unlike always blocks, and you can't initialise correctly by ignoring the delays. For initialisation of the gate output, 2005/page 112 explicitly shows this case. For 'buf #3 g2 (q, qi)', the diagram shows q unknown till time 3. This diagram also appears in the OVI V1 LRM from 1991 (Figure '7-1: Module schematic and the simulation times of initial value propagation'), so no excuses there. ------------------------------------------------------------------------------ _______________________________________________ Iverilog-devel mailing list Ive...@li... https://lists.sourceforge.net/lists/listinfo/iverilog-devel |
|
From: Evan L. <sa2...@cy...> - 2014-08-19 09:44:40
|
What are you actually seeing? Presumably CVC is showing 1 on both ca and gt at time 1? If so, that would be pretty hard to justify. 11.6.1 is definitive on continuous assignments at time 0 - the 'continuous assignment process' is evaluated at time 0, and an active update event is added to the event queue. On the other hand, I'm pretty sure that this was not actually specified prior to 2005, so it would be interesting to see what XL does. I'd be very surprised if XL got this 'wrong', though - continuous assignments were always meant to model combinatorial logic correctly, unlike always blocks, and you can't initialise correctly by ignoring the delays. For initialisation of the gate output, 2005/page 112 explicitly shows this case. For 'buf #3 g2 (q, qi)', the diagram shows q unknown till time 3. This diagram also appears in the OVI V1 LRM from 1991 (Figure '7-1: Module schematic and the simulation times of initial value propagation'), so no excuses there. |
|
From: Stephen W. <st...@ic...> - 2014-08-18 22:27:07
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Note that "constant values are propagated" is a Verilog constant meaning that constant values are propagated through the network, whereas the term "constant propagation" is a generic compiler construction term meaning the propagation of constant values through expressions. The LRM says exactly nothing about "constant propagation" in the latter sense. Also, it is 100% clear to me that in your example, ca and gt should be 'bx for 10 clicks before the constant value arrives. What if, for example, the expression on the right side were a variable that just happens to have a constant value? On 08/18/2014 03:02 PM, Martin Whitaker wrote: > Section 11.6.1 of 1364-2005 states > > "A continuous assignment process is also evaluated at time 0 to > ensure that constant values are propagated." > > If we follow the normal rules for a continuous assignment with a > delay, the LHS should only be updated after the specified delay. > > I know Verilog-XL and NC-Verilog behave this way. > > Martin > > Cary R. wrote: >> I am looking to see what the attached code does for various >> simulators. glpcver and CVC both do constant propagation >> independent of the delay while Icarus stops at the delay for both >> constant and variable assignments. It makes sense that the gate >> and continuous assignment should match since they are intended to >> model the same functionality at different levels of abstraction. >> I looked in the standard and could not find where it specified >> that a constant should be propagated like this. Any pointers to >> where in the standard this is specified and/or test results would >> be appreciated. >> >> I am running CVC against the Icarus test suite looking for errors >> in either simulator and this is the first big difference I am >> looking at. >> >> Cary > > ------------------------------------------------------------------------------ > > _______________________________________________ > Iverilog-devel mailing list Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > - -- 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) iEYEARECAAYFAlPyfbQACgkQrPt1Sc2b3im+lACfV2irh9tYzKRqGrSM3uk7/7kz J+IAnRYQ4qSux4QZJgxxsjLPiBY24qiy =pxiv -----END PGP SIGNATURE----- |
|
From: Martin W. <mai...@ma...> - 2014-08-18 22:15:56
|
Section 11.6.1 of 1364-2005 states "A continuous assignment process is also evaluated at time 0 to ensure that constant values are propagated." If we follow the normal rules for a continuous assignment with a delay, the LHS should only be updated after the specified delay. I know Verilog-XL and NC-Verilog behave this way. Martin Cary R. wrote: > I am looking to see what the attached code does for various simulators. > glpcver and CVC both do constant propagation independent of the delay while > Icarus stops at the delay for both constant and variable assignments. It > makes sense that the gate and continuous assignment should match since they > are intended to model the same functionality at different levels of > abstraction. I looked in the standard and could not find where it specified > that a constant should be propagated like this. Any pointers to where in > the standard this is specified and/or test results would be appreciated. > > I am running CVC against the Icarus test suite looking for errors in either > simulator and this is the first big difference I am looking at. > > Cary |
|
From: Cary R. <cy...@ya...> - 2014-08-18 22:12:32
|
Thanks Martin, That is my understanding as well, but the CVC/gplcver folks are pretty adamant that ignoring the delay during constant propagation is correct which was why I was looking for actual test results. I have asked them where in the standard they see this functionality being specified. Cary On Monday, August 18, 2014 3:02 PM, Martin Whitaker <mai...@ma...> wrote: Section 11.6.1 of 1364-2005 states "A continuous assignment process is also evaluated at time 0 to ensure that constant values are propagated." If we follow the normal rules for a continuous assignment with a delay, the LHS should only be updated after the specified delay. I know Verilog-XL and NC-Verilog behave this way. Martin Cary R. wrote: > I am looking to see what the attached code does for various simulators. > glpcver and CVC both do constant propagation independent of the delay while > Icarus stops at the delay for both constant and variable assignments. It > makes sense that the gate and continuous assignment should match since they > are intended to model the same functionality at different levels of > abstraction. I looked in the standard and could not find where it specified > that a constant should be propagated like this. Any pointers to where in > the standard this is specified and/or test results would be appreciated. > > I am running CVC against the Icarus test suite looking for errors in either > simulator and this is the first big difference I am looking at. > > Cary |
|
From: Lonnie L G. <lg...@sr...> - 2014-08-13 19:50:16
|
I rechecked and when I switched from the directory for top_sim to just the
file I wasn't including it. So I added the dir back and did -s top_sim. With
that it compiled and ran correct.
Thanks
From: Cary R. [mailto:cy...@ya...]
Sent: Wednesday, August 13, 2014 12:42 PM
To: Discussions concerning Icarus Verilog development
Subject: Re: [Iverilog-devel] using -s to define top module gets error
Are you 100% sure the top_sim.v file is actually being loaded by Icarus? How
are you loading it? For the most part -s should never be needed.
Cary
On Wednesday, August 13, 2014 10:34 AM, Lonnie Gliem
<lg...@sr...> wrote:
It is top_sim
On Aug 13, 2014, at 11:32 AM, Iztok Jeras <izt...@gm...> wrote:
Just in case, did you check the module name inside top_sim.v is it top_sim
or is it different?
On 13 August 2014 18:28, Lonnie L Gliem <lg...@sr...> wrote:
So I changed it to just the name of the file top_sim.v
error: Unable to find the root module "top_sim" in the Verilog source.
: Perhaps ``-s top_sim.v'' is incorrect?
1 error(s) during elaboration.
Then I tried just top_sim
error: Unable to find the root module "top_sim" in the Verilog source.
: Perhaps ``-s top_sim'' is incorrect?
1 error(s) during elaboration.
On Wed, 2014-08-13 at 09:23 -0700, Stephen Williams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> The "-s" takes the module name, not the path to the source file
> that contains the module.
>
> On 08/13/2014 09:11 AM, Lonnie L Gliem wrote:
> > I am having trouble in a simulation where it finds way too many
> > top
> >
> > modules. So I tried using the -s option to tell it which one is the
> > top.
> >
> >
> >
> > But I get this error.
> >
> >
> >
> > error: Unable to find the root module
> > "/export/home/lgliem/libs/libsim/ulogic_sim/top_sim.v" in the
> > Verilog
> >
> > source.
> >
> > : Perhaps ``-s
> > /export/home/lgliem/libs/libsim/ulogic_sim/top_sim.v'' is
> > incorrect?
> >
> > 1 error(s) during elaboration.
> >
> >
> >
> > The module is there so I am not sure what is wrong.
> >
> >
> >
> > Lonnie
> >
> >
> >
> >
> >
> >
----------------------------------------------------------------------------
--
> >
> >
> >
> >
> > _______________________________________________ Iverilog-devel
> > mailing list Ive...@li...
> > https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> >
>
>
> - --
> Steve Williams "The woods are lovely, dark and deep.
> steve at icarus.com <http://icarus.com/> But I have promises to
keep,
> http://www.icarus.com <http://www.icarus.com/> and lines to code
before I sleep,
> http://www.picturel.com <http://www.picturel.com/> And lines to
code before I sleep."
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
>
> iEYEARECAAYFAlPrkOYACgkQrPt1Sc2b3ikw0gCgsWpEpwR+Azm5UnpjxpJ8VqBl
> aKMAnigQqyVdQO5It0x9krxICE2f0dpo
> =urWJ
> -----END PGP SIGNATURE-----
>
>
----------------------------------------------------------------------------
--
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
----------------------------------------------------------------------------
--
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
----------------------------------------------------------------------------
--
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
----------------------------------------------------------------------------
--
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
|
|
From: Cary R. <cy...@ya...> - 2014-08-13 17:42:21
|
Are you 100% sure the top_sim.v file is actually being loaded by Icarus? How are you loading it? For the most part -s should never be needed. Cary On Wednesday, August 13, 2014 10:34 AM, Lonnie Gliem <lg...@sr...> wrote: It is top_sim On Aug 13, 2014, at 11:32 AM, Iztok Jeras <izt...@gm...> wrote: Just in case, did you check the module name inside top_sim.v is it top_sim or is it different? > > > > >On 13 August 2014 18:28, Lonnie L Gliem <lg...@sr...> wrote: > >So I changed it to just the name of the file top_sim.v >> >>error: Unable to find the root module "top_sim" in the Verilog source. >> : Perhaps ``-s top_sim.v'' is incorrect? >>1 error(s) during elaboration. >> >>Then I tried just top_sim >> >>error: Unable to find the root module "top_sim" in the Verilog source. >> : Perhaps ``-s top_sim'' is incorrect? >>1 error(s) during elaboration. >> >> >> >> >>On Wed, 2014-08-13 at 09:23 -0700, Stephen Williams wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> >>> The "-s" takes the module name, not the path to the source file >>> that contains the module. >>> >>> On 08/13/2014 09:11 AM, Lonnie L Gliem wrote: >>> > I am having trouble in a simulation where it finds way too many >>> > top >>> > >>> > modules. So I tried using the -s option to tell it which one is the >>> > top. >>> > >>> > >>> > >>> > But I get this error. >>> > >>> > >>> > >>> > error: Unable to find the root module >>> > "/export/home/lgliem/libs/libsim/ulogic_sim/top_sim.v" in the >>> > Verilog >>> > >>> > source. >>> > >>> > : Perhaps ``-s >>> > /export/home/lgliem/libs/libsim/ulogic_sim/top_sim.v'' is >>> > incorrect? >>> > >>> > 1 error(s) during elaboration. >>> > >>> > >>> > >>> > The module is there so I am not sure what is wrong. >>> > >>> > >>> > >>> > Lonnie >>> > >>> > >>> > >>> > >>> > >>> > ------------------------------------------------------------------------------ >>> > >>> > >>> > >>> > >>> > _______________________________________________ Iverilog-devel >>> > mailing list Ive...@li... >>> > https://lists.sourceforge.net/lists/listinfo/iverilog-devel >>> > >>> >>> >>> - -- >>> 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) >>> >>> iEYEARECAAYFAlPrkOYACgkQrPt1Sc2b3ikw0gCgsWpEpwR+Azm5UnpjxpJ8VqBl >>> aKMAnigQqyVdQO5It0x9krxICE2f0dpo >>> =urWJ >>> -----END PGP SIGNATURE----- >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Iverilog-devel mailing list >>> Ive...@li... >>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel >> >> >> >>------------------------------------------------------------------------------ >>_______________________________________________ >>Iverilog-devel mailing list >>Ive...@li... >>https://lists.sourceforge.net/lists/listinfo/iverilog-devel >> > ------------------------------------------------------------------------------ > _______________________________________________ >Iverilog-devel mailing list >Ive...@li... >https://lists.sourceforge.net/lists/listinfo/iverilog-devel > ------------------------------------------------------------------------------ _______________________________________________ Iverilog-devel mailing list Ive...@li... https://lists.sourceforge.net/lists/listinfo/iverilog-devel |
|
From: Lonnie G. <lg...@sr...> - 2014-08-13 17:30:00
|
It is top_sim On Aug 13, 2014, at 11:32 AM, Iztok Jeras <izt...@gm...> wrote: > Just in case, did you check the module name inside top_sim.v is it top_sim or is it different? > > > On 13 August 2014 18:28, Lonnie L Gliem <lg...@sr...> wrote: > So I changed it to just the name of the file top_sim.v > > error: Unable to find the root module "top_sim" in the Verilog source. > : Perhaps ``-s top_sim.v'' is incorrect? > 1 error(s) during elaboration. > > Then I tried just top_sim > > error: Unable to find the root module "top_sim" in the Verilog source. > : Perhaps ``-s top_sim'' is incorrect? > 1 error(s) during elaboration. > > > > On Wed, 2014-08-13 at 09:23 -0700, Stephen Williams wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > > The "-s" takes the module name, not the path to the source file > > that contains the module. > > > > On 08/13/2014 09:11 AM, Lonnie L Gliem wrote: > > > I am having trouble in a simulation where it finds way too many > > > top > > > > > > modules. So I tried using the -s option to tell it which one is the > > > top. > > > > > > > > > > > > But I get this error. > > > > > > > > > > > > error: Unable to find the root module > > > "/export/home/lgliem/libs/libsim/ulogic_sim/top_sim.v" in the > > > Verilog > > > > > > source. > > > > > > : Perhaps ``-s > > > /export/home/lgliem/libs/libsim/ulogic_sim/top_sim.v'' is > > > incorrect? > > > > > > 1 error(s) during elaboration. > > > > > > > > > > > > The module is there so I am not sure what is wrong. > > > > > > > > > > > > Lonnie > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > > > > _______________________________________________ Iverilog-devel > > > mailing list Ive...@li... > > > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > > > > > > > > > - -- > > 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) > > > > iEYEARECAAYFAlPrkOYACgkQrPt1Sc2b3ikw0gCgsWpEpwR+Azm5UnpjxpJ8VqBl > > aKMAnigQqyVdQO5It0x9krxICE2f0dpo > > =urWJ > > -----END PGP SIGNATURE----- > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Iverilog-devel mailing list > > Ive...@li... > > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > > ------------------------------------------------------------------------------ > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel |
31 messages has been excluded from this view by a project administrator.
