Save and Restore simulation state
Hi Srini, We normally only use SourceForge for the mailing list and for release distribution. I think Steve requested you to use to discuss this on the mailing list. Please post this to the iverilog-devel mailing list. The short answer is look at ivtest which is our regression environment and determine how to integrate your tests into that environment. For your development I completely understand your desire to have your tests Makefile driven and it should be possible to architect your tests so they...
IVL_UVM: UVM support - incremental additions
Packages which tries to create an instance of a class is not accepted by Icarus.
This is now fixed in the master branch.
Parameters defined in package not seen in Verilog module imported it
This is now fixed in the master branch. The fix is unlikely to be backported to the v10 branch as it is the result of a significant rework of the parser.
../../submit/7.v:1: syntax error ../../submit/7.v:1: error: invalid module item. ../../submit/7.v:2: syntax error ../../submit/7.v:2: error: invalid module item. ../../submit/7.v:3: syntax error ../../submit/7.v:2: error: Syntax error in instance port expression(s). ivl: pform.cc:2231: void pform_make_modgates(const vlltype&, perm_string, parmvalue_t*, svector<lgate>*, std::__cxx11::list<named<PExpr*> >*): Assertion `! pform_cur_module.empty()' failed. Aborted
Fixed (replaced with an "internal error" error message) in master and v10-branch.
pform.cc:1329: void pform_endmodule(const char*, bool, Module::UCDriveType): Assertion `strcmp(name, mod_name) == 0' failed.
This seems to be already fixed. It does indeed look like the fix for #1039 also fixed this one.
virtual void PEBinary::declare_implicit_nets(LexicalScope*, NetNet::Type): Assertion `left_ && right_' failed.
Fixed in git master and v10-branch
verinum.cc:71: std::__cxx11::string process_verilog_string_quotes(const string&): Assertion `idx < str_len' failed.
Pushed fixes for this to both git master and v10-branch. The solution is to detect a nil character in a string literal, and report that as an error.
pform.cc:1255: void pform_endmodule(const char*, bool, Module::UCDriveType): Assertion `strcmp(name, mod_name) == 0' failed.
Fixed in git master and v10-branch
assert: elaborate.cc:2404: failed assertion dex
Fixed in master and v10-branch branches.
pform.cc:333: LexicalScope* pform_peek_scope(): Assertion `lexical_scope' f ailed.
Pushed to v10-branch a fix so that this generates a syntax error instead of an assertion failure. The master branch already handles this.
This may be a duplicate of bug #1039.
../../submit/7.v:1: syntax error ../../submit/7.v:1: error: invalid module item. ../../submit/7.v:2: syntax error ../../submit/7.v:2: error: invalid module item. ../../submit/7.v:3: syntax error ../../submit/7.v:2: error: Syntax error in instance port expression(s). ivl: pform.cc:2231: void pform_make_modgates(const vlltype&, perm_string, parmvalue_t*, svector<lgate>*, std::__cxx11::list<named<PExpr*> >*): Assertion `! pform_cur_module.empty()' failed. Aborted
pform.cc:1329: void pform_endmodule(const char*, bool, Module::UCDriveType): Assertion `strcmp(name, mod_name) == 0' failed.
virtual void PEBinary::declare_implicit_nets(LexicalScope*, NetNet::Type): Assertion `left_ && right_' failed.
This also fails on the latest version from git. The only difference in output seems to be that it is now on line 72 instead of 71.
This also fails on the latest version from git.
It appears that this is already fixed in the latest version from git.
I also ran this on the latest version and it also fails there in the same way.
verinum.cc:71: std::__cxx11::string process_verilog_string_quotes(const string&): Assertion `idx < str_len' failed.
pform.cc:1255: void pform_endmodule(const char*, bool, Module::UCDriveType): Assertion `strcmp(name, mod_name) == 0' failed.
pform.cc:333: LexicalScope* pform_peek_scope(): Assertion `lexical_scope' f ailed.
assert: elaborate.cc:2404: failed assertion dex
segmentation fault
I have confirmed this bug was present in v10.1 but has already been fixed. v10.3 does not exhibit this fault.
VPI compile on Mac OSX
No problem, and sorry it took so long to respond to this one.
Understood, thanks for the explanation.
The source tarball does not contain a file named iverilog-vpi, nor any file containing the string "color-diagnostics": % tar xf verilog-10.0.tar.gz % cd verilog-10.0 % find . -name "iverilog*" ./driver/iverilog.man.in ./iverilog-vpi.man.in ./iverilog-vpi.sh ./tgt-fpga/iverilog-fpga.man % grep -r diagnostics . ./netlist.h: // the stream. It is used for debug and diagnostics. % iverilog-vpi is created when you run make. autoconf will be setting the CXX variable, based on local settings on your machine....
At tmy end I edited the bin/iverilog-vpi to get going (As I have admin previlages on this machine). I looked inside the source tar ball and am able to see same file at: /Users/srini/tools/EDA/ivlog/verilog-10.0/iverilog-vpi Can you please confirm? As I mentioned, the issue is minor and only on Mac. Thanks Srini
ATtmy end I edited the bin/iverilog-vpi to get going (As I have admin previlages on this machine). I looked inside the source tar ball and am able to see same file at: /Users/srini/tools/EDA/ivlog/verilog-10.0/iverilog-vpi Can you please confirm? As I mentioned, the issue is minor and only on Mac. Thanks Srini
Invalid hierarchical reference does not generate error
The hierarchical search algorithm is indeed broken - it matches module names as well as instance names at intermediate levels in the hierarchy. Setting target to devel, as that is where this will be fixed first. v10.2 is the latest stable release - see https://github.com/steveicarus/iverilog/releases. v10.3 is coming soon.
Invalid hierarchical reference does not generate error
systemverilog user defined types elaborate internal error
Seems this should have been closed long ago.
I don't see this in the Icarus source code. What file are you changing?
Declaring array ports for tasks/functions causes an assertion failure
Fixed in both master and v10 branches. If compiling with -g2005 or earlier, an error message will be output, otherwise a "sorry" message will be output to indicate this feature is not yet supported.
"a;" outside a module causes compiler to segfault
I have added a note in the README file to alert users to the problem with bison 2.3.
No, I run this with version from Ubuntu repository. It is Icarus Verilog version 10.1 (stable) I will try with latest code on next week.
No, I run this with version from Ubuntu repository. It is Icarus Verilog version 10.1 (stable) I will try with latest code on next week.
I can't reproduce this. Have you tested using the latest code available on GitHub?
segmentation fault
Error: Unable to find the root module "-g2012" in the verilog source.
If you use the -s option, you must provide the name of your top module. See the man page or https://iverilog.fandom.com/wiki/Iverilog_Flags#-s_topmodule
Error: Unable to find the root module "-g2012" in the verilog source.
possible false clocking
Closing, as I believe the compiler is behaving correctly.
Adding a small delay to the case statement does produce the desired results. I'll see about taking up the gtkwave issue over with the gtkwave people. Thanks for your time and your guidance. -- John
Add a small delay before the case statement, e.g. #0.01, ensuring all inputs to the combinatorial block are stable before evaluating the output. That's not exactly simulating the FPGA behaviour, but it achieves the same end. You'll need to add a timescale to your design for fractional delays to work. You'd have to talk to the gtkwave author about displaying glitches. Their presence can be detected in the VCD file. If you run your original code, a value is output for clk_1_5 every time step. Once...
It would be useful if the perceived glitch on clk_1_5 was visible in gtkwave. The circuit is intended to be implemented by a FPGA whose combination logic block is guarenteed not to glitch if certain critiera is meet. This fact is being leveraged by the technical note I mentioned in how they implemented the divider. Making the change you suggested to using a default clause in the case block does eliminate one of the glitches perceived by the simulator. Do you have a suggestion on how to let the simulator...
The design generates glitches on clk_1_5. Because there are no delays, you don't see these in gtkwave. There are two sources of glitches: Assigning clk_1_5 = rclk and then reassigning it in the case statement can generate a glitch. This will be enough to trigger the @(posedge clk_1_5). You can fix that by removing the initial assignment and adding a default clause in the case statement. The non-blocking assignments to a and b cause a and b to change in a different simulation time delta to rclk. You...
possible false clocking
Unfortunately the VHDL target is currently unmaintained. I don't know enough VHDL to take that on.
assert in tgt-vhdl/scope.cc
Parameters defined in package not seen in Verilog module imported it
Hi Martin - thanks; that surprised me. I've tried the code on EDA Playground, and VCS agrees with ModelSim, while Icarus, Riviera (which I think normally follows ModelSim), GPL-CVer, and Veriwell agree with XL. The problem is that the section you've quoted makes sense for $random(n), but it doesn't cover the case where no seed is provided. The LRM appears to have nothing to say about this. '$random' clearly can't map on to 'rtl_dist_uniform(seed, LONG_MIN, LONG_MAX)' as no seed is supplied, and 'rtl_dist_uniform'...
Icarus is not random-stable
If you want random stability, you need to pass your seed variable to every call to $random, not just the first. In the IEEE standard, this is (poorly) explained in the section on $dist functions: "For each system function, the seed argument is an inout argument; that is, a value is passed to the function, and a different value is returned. The system functions shall always return the same value given the same seed. This facilitates debugging by making the operation of the system repeatable. The seed...
Icarus is not random-stable
Thanks very much - my Icarus regressions all now pass.
Further fixes pushed to both the master and the v10 branches. $write #3 should now pass. $write #4 should now be rejected as illegal.
The 2012 standard says "The $signed and $unsigned system functions can be used to cast the signedness (but not the type) of expressions." I think "but not the type" is meant to indicate that the input value must be a bit vector. Elsewhere $signed and $unsigned are defined as returning a bit vector with the same number of bits and bit pattern as the input. So prohibiting real input values doesn't seem unreasonable. $rtoi and $realtobits provide the means to convert/cast real values to bit vectors....
Hi Martin - that's great - thanks. It's not quite complete, unfortunately, but I'm not sure how far it's worth going with this. The attached is a slightly modified version of the test, which adds two further $writes. $write #3 has a function call ('foo(0)') as the actual parameter, where the function returns a real, and $write expects '%d'. The real it returns is 2.5, so this should be rounded to 3. $write #4 is the same, except that the the actual parameter is now '$signed(foo(0))'. This is probably...
Reals are incorrectly rounded to ints
Fix pushed to both the master and v10 branches.
Verilog-XL considers this to be illegal. Incisive outputs warnings but converts to integers as per the standard rounding rules. As Icarus is converting to integers, I think it too should adhere to the rounding rules.
It appears to be an issue with the $write call. If you assign the values to integers before writing them, you get the correct behaviour.
Reals are incorrectly rounded to ints
I am able to reproduce it on Mac on version 10.2, but not on Linux. ~Theodore On Apr 17, 2018, at 10:52 AM, Martin Whitaker martinwhitaker@users.sourceforge.net wrote: I am unable to reproduce this. The code a; results in the error message -:1: error: variable declarations must be contained within a module. The compiler used to segfault on this code, but this was fixed just before the v10.0 release (bug #992). Can you provide a simple test case that demonstrates the fault you are seeing. [bugs:#1028]...
The difference appears to be the version of bison used at compile time. macOS includes bison 2.3, and building with that version causes the segfault. Building with bison 3.0.4 works fine. ~Theodore On Apr 17, 2018, at 11:37 AM, Theodore Dubois tblodt@icloud.com wrote: I am able to reproduce it on Mac on version 10.2, but not on Linux. ~Theodore On Apr 17, 2018, at 10:52 AM, Martin Whitaker martinwhitaker@users.sourceforge.net wrote: I am unable to reproduce this. The code a; results in the error...
I am unable to reproduce this. The code a; results in the error message -:1: error: variable declarations must be contained within a module. The compiler used to segfault on this code, but this was fixed just before the v10.0 release (bug #992). Can you provide a simple test case that demonstrates the fault you are seeing.
"a;" outside a module causes compiler to segfault
Thank you - confirmed fixed.
v10 regression: task inout parameter copy-out fails, Ok in 0.9.7
I've pushed a fix for this to both the master and v10 branches on GitHub.
Confirmed it also fails on the master branch. This is yet more fallout from the SystemVerilog enhancements. The parser is applying the default port direction (input) to each port item that doesn't explicitly include a direction, whereas it should only use the default for the first item, then inherit from left to right. Changing the task declaration to task swap(inout reg[2:0] x, inout reg[2:0] y); gives the correct output.
v10 regression: task inout parameter copy-out fails, Ok in 0.9.7
Sorry about that - only just managed to get back on to this after 7 months! I did a git pull and re-ran the regressions just before your mail, and can confirm that all the failures that I had in July are now gone. So, presumably #1016 and #1017 fixed everything. Great work - thanks very much.
Program fails until a $write debug statement is added
No response, so closing as fixed. Please reopen if you still see this bug.
You need to clock on the edit link. I updated it to VHDL since I assume that is what you were trying to do.
VHDL: rotate support for simulation