iverilog-devel — Conversations on matters of Icarus Verilog development

Re: [Iverilog-devel] MSYS2 installation

[Evan L. <sa2...@cy...>]

Thanks - that's great. I don't do Windows, but I think the best format 
for a release might be 32-bit static. I'll have another go at it later 
this week or next.


On 02/06/2019 20:01, Martin Whitaker wrote:
> Martin Whitaker wrote:
>> Running 'stat' in the MSYS2 shell shows the full resolution 
>> timestamps. It appears the latest version of bison writes the .hh file 
>> before the .cc file, thus breaking our make rules. Also reported in 
>> https://github.com/steveicarus/iverilog/issues/247 for Ubuntu.
> 
> I've pushed a fix for this to both the master and the v10 branch.
> 
> 
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel

Re: [Iverilog-devel] MSYS2 installation

[Martin W. <ic...@ma...>]

Martin Whitaker wrote:
> Running 'stat' in the MSYS2 shell shows the full resolution timestamps. It 
> appears the latest version of bison writes the .hh file before the .cc 
> file, thus breaking our make rules. Also reported in 
> https://github.com/steveicarus/iverilog/issues/247 for Ubuntu.

I've pushed a fix for this to both the master and the v10 branch.

Re: [Iverilog-devel] MSYS2 installation

[Martin W. <ic...@ma...>]

Evan Lavelle wrote:
> Some feedback on an MSYS2/mingw64 build (a 64-bit build, with the newer 
> version of MinGW). This is pretty painless, except that 'make install' 
> doesn't work. There are various warnings with the gcc 9.1.0 build, but 
> nothing important - I can post the build output if anyone wants to see it. 
> Note that this is a clean MSYS2 build, and not a Cygwin build.

Yes, gcc 9.x has introduced a bunch of new warnings. Looks like C++ is 
re-inventing itself again.

> The generated Makefile appears to be incorrect for the install step, but 
> I'm not quite sure how. The 'install' goal depends on 'all', and make runs 
> through the 'all' dependencies before starting the install step. It gets to 
> the Bison rule, and decides that parse.h is out of date, because it's older 
> than parse.cc. It then attempts to carry out the 'mv parse.cc.h', but 
> fails, since parse.cc.h no longer exists, having already been moved in the 
> main build. This happens in 3 different Makefiles. The comment here refers 
> to 'pr3462585' to explain why the Bison rule is carried out this way, but I 
> can't find anything on pr3462585 on the net.

Unfortunately SourceForge renumbered all the bugs, so we lost the 
connection between bug reports and regression tests, etc.

> parse.h and parse.cc actually have the same (visible) timestamp so, at 
> first sight, this shouldn't happen. My first thought was that it might be a 
> time resolution problem on Win/MSYS2, so I added .LOW_RESOLUTION_TIME 
> targets with parse.h prerequisites, but this does nothing (and make 
> complains that they're high resolution anyway). I also tried running the 
> install step with the Cygwin make rather than the MSYS2 make, but this 
> makes no difference (and would probably fail anyway).

Running 'stat' in the MSYS2 shell shows the full resolution timestamps. It 
appears the latest version of bison writes the .hh file before the .cc 
file, thus breaking our make rules. Also reported in 
https://github.com/steveicarus/iverilog/issues/247 for Ubuntu.

> The manual fix is simply to touch the parse.h files when the build stops, 
> and re-run the install.
> 
> The next issue is that the build is dynamic, and I don't think this really 
> works for Windows. To get iverilog to run, you have to ship MinGW's 
> libstdc++-6.dll, libgcc_s_seh-1.dll, and libwinpthread-1.dll with iverilog. 
> You can just put them in the same bin directory. But, to get vvp to run, 
> you have to add lots more dlls (not sure which). The simplest thing to do 
> is just to install MSYS2 with either the 32-bit or 64-bit toolchain, and 
> put the toolchain in your path (/cygdrive/c/msys64/mingw64/bin for me, in 
> my Cygwin path) along with the MSYS2-generated Icarus exes. Not great, and 
> Pablo's installer gives you an option to install the required DLLs. It 
> doesn't work without the DLLs, so presumably this option is for people who 
> already have an MSYS2 installation.
> 
> None of this is necessary with a static build, which is what I do with my 
> own code. However, that's with hand-written Makefiles, and I'm not sure how 
> to persuade configure to generate static binaries, or even if it's possible.

Well, it's always been that way, and I don't really have the time or 
motivation to change it (I don't use Windows myself).

I think the extra DLLs you need to copy for vvp are libbz, libhistory, 
libreadline, libtermcap, and zlib. I should probably add that to the 
instructions on the Wiki.

[Iverilog-devel] MSYS2 installation

[Evan L. <sa2...@cy...>]

Some feedback on an MSYS2/mingw64 build (a 64-bit build, with the newer 
version of MinGW). This is pretty painless, except that 'make install' 
doesn't work. There are various warnings with the gcc 9.1.0 build, but 
nothing important - I can post the build output if anyone wants to see 
it. Note that this is a clean MSYS2 build, and not a Cygwin build.

The generated Makefile appears to be incorrect for the install step, but 
I'm not quite sure how. The 'install' goal depends on 'all', and make 
runs through the 'all' dependencies before starting the install step. It 
gets to the Bison rule, and decides that parse.h is out of date, because 
it's older than parse.cc. It then attempts to carry out the 'mv 
parse.cc.h', but fails, since parse.cc.h no longer exists, having 
already been moved in the main build. This happens in 3 different 
Makefiles. The comment here refers to 'pr3462585' to explain why the 
Bison rule is carried out this way, but I can't find anything on 
pr3462585 on the net.

parse.h and parse.cc actually have the same (visible) timestamp so, at 
first sight, this shouldn't happen. My first thought was that it might 
be a time resolution problem on Win/MSYS2, so I added 
.LOW_RESOLUTION_TIME targets with parse.h prerequisites, but this does 
nothing (and make complains that they're high resolution anyway). I also 
tried running the install step with the Cygwin make rather than the 
MSYS2 make, but this makes no difference (and would probably fail anyway).

The manual fix is simply to touch the parse.h files when the build 
stops, and re-run the install.

The next issue is that the build is dynamic, and I don't think this 
really works for Windows. To get iverilog to run, you have to ship 
MinGW's libstdc++-6.dll, libgcc_s_seh-1.dll, and libwinpthread-1.dll 
with iverilog. You can just put them in the same bin directory. But, to 
get vvp to run, you have to add lots more dlls (not sure which). The 
simplest thing to do is just to install MSYS2 with either the 32-bit or 
64-bit toolchain, and put the toolchain in your path 
(/cygdrive/c/msys64/mingw64/bin for me, in my Cygwin path) along with 
the MSYS2-generated Icarus exes. Not great, and Pablo's installer gives 
you an option to install the required DLLs. It doesn't work without the 
DLLs, so presumably this option is for people who already have an MSYS2 
installation.

None of this is necessary with a static build, which is what I do with 
my own code. However, that's with hand-written Makefiles, and I'm not 
sure how to persuade configure to generate static binaries, or even if 
it's possible.

Re: [Iverilog-devel] PR 149 making into 10_2

[Martin W. <ic...@ma...>]

Vamsi Vytla wrote:
> Hi All,
> 
> Just wondering why
> 
> https://github.com/steveicarus/iverilog/pull/149
> 
> Didn't make it in the 10_2 release. Do one of you mind having a look
> when you get a chance?

Because the 10.2 release comes from the stable (v10-branch) branch. Bug 
fixes get backported from development, but new features generally aren't.

[Iverilog-devel] PR 149 making into 10_2

[Vamsi V. <vam...@gm...>]

Hi All,

Just wondering why

https://github.com/steveicarus/iverilog/pull/149

Didn't make it in the 10_2 release. Do one of you mind having a look
when you get a chance?

Cheers!
Vamsi Vytla

Re: [Iverilog-devel] Icarus Verilog Windows builds

[Martin W. <ic...@ma...>]

OK, it needs to be added to "make install" then.

On 22/03/19 15:26, Stephen Williams wrote:
> The libivl.a is only needed (on windows) when building loadable target
> modules. There is a group trying to do exactly this, and that is how I
> found out that it is missing.
> 
> On Thu, Mar 21, 2019 at 12:55 PM Martin Whitaker
> <ic...@ma...> wrote:
>>
>> Stephen Williams wrote:
>>> Hi,
>>>
>>> Is someone doing, and publishing, Windows builds of Icarus Verilog? It
>>> appears that the "pablo" version doesn't have the latest released
>>> version, and also is missing the libivl.a file.
>>>
>> You didn't announce 10.2, so it may be that Pablo isn't aware of it. I only
>> found out about it because people started mentioning it in bug reports.
>>
>> BTW, as I mentioned before, the latest version available on SourceForge is
>> 10.0.
>>
>> I don't have libivl.a installed in my Windows test system either, and
>> everything works without it.
>>
>>
>> _______________________________________________
>> Iverilog-devel mailing list
>> Ive...@li...
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 
> 
> 

Re: [Iverilog-devel] Icarus Verilog Windows builds

[Stephen W. <st...@ic...>]

The libivl.a is only needed (on windows) when building loadable target
modules. There is a group trying to do exactly this, and that is how I
found out that it is missing.

On Thu, Mar 21, 2019 at 12:55 PM Martin Whitaker
<ic...@ma...> wrote:
>
> Stephen Williams wrote:
> > Hi,
> >
> > Is someone doing, and publishing, Windows builds of Icarus Verilog? It
> > appears that the "pablo" version doesn't have the latest released
> > version, and also is missing the libivl.a file.
> >
> You didn't announce 10.2, so it may be that Pablo isn't aware of it. I only
> found out about it because people started mentioning it in bug reports.
>
> BTW, as I mentioned before, the latest version available on SourceForge is
> 10.0.
>
> I don't have libivl.a installed in my Windows test system either, and
> everything works without it.
>
>
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel



-- 
Steve Williams                "The woods are lovely, dark and deep.
st...@ic...              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."

Re: [Iverilog-devel] Icarus Verilog Windows builds

[Martin W. <ic...@ma...>]

Stephen Williams wrote:
> Hi,
> 
> Is someone doing, and publishing, Windows builds of Icarus Verilog? It
> appears that the "pablo" version doesn't have the latest released
> version, and also is missing the libivl.a file.
> 
You didn't announce 10.2, so it may be that Pablo isn't aware of it. I only 
found out about it because people started mentioning it in bug reports.

BTW, as I mentioned before, the latest version available on SourceForge is 
10.0.

I don't have libivl.a installed in my Windows test system either, and 
everything works without it.

[Iverilog-devel] Icarus Verilog Windows builds

[Stephen W. <st...@ic...>]

Hi,

Is someone doing, and publishing, Windows builds of Icarus Verilog? It
appears that the "pablo" version doesn't have the latest released
version, and also is missing the libivl.a file.

-- 
Steve Williams                "The woods are lovely, dark and deep.
st...@ic...              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."

Re: [Iverilog-devel] automatically starting in noninteractive mode if standard input is not a terminal

[Martin W. <ic...@ma...>]

Lennert Buytenhek wrote:
> Hello!
> 
> I've been using the hack patch below to make Icarus Verilog
> automatically start in noninteractive mode when standard input is
> not a terminal.  This is useful when you're piping test data into a
> testbench and you don't want Ctrl-C to cause your terminal to be
> flooded with endless output like this:
> 
> 	$ ./gen | vvp ./detect
> 	[...]
> 	[1117850] 0   x x  x
> 	[1119450] 0   x x  x
> 	^C** VVP Stop(0) **
> 	** Flushing output streams.
> 	** Current simulation time is 1120750 ticks.
> 	> 0
> 	Unknown command: 0
> 	Try the help command to get a summary
> 	of available commands.
> 	> 0
> 	Unknown command: 0
> 	Try the help command to get a summary
> 	of available commands.
> 	> 0
> 	Unknown command: 0
> 	Try the help command to get a summary
> 	of available commands.
> 	> 0
> 	Unknown command: 0
> 	Try the help command to get a summary
> 	of available commands.
> 	[...]
> 
> Specifying -n by hand achieves the same thing, but there doesn't seem
> to be a legitimate reason to make Ctrl-C cause piped (noninteractive)
> input to be treated as commands if you don't explicitly pass in an
> option to prevent that from happening, IMHO.

I was about to agree with you, but then thought, what if someone piped in a 
set of commands they wanted to be executed when simulation stopped, i.e. 
some sort of semi-automatic debugging aid.

As "vvp -n" provides the behaviour you want, I'm inclined to leave well alone.

Re: [Iverilog-devel] automatically starting in noninteractive mode if standard input is not a terminal

[Lennert B. <bu...@wa...>]

On Fri, Jan 04, 2019 at 06:38:11AM +0100, Niels Möller wrote:

> > I've been using the hack patch below to make Icarus Verilog
> > automatically start in noninteractive mode when standard input is
> > not a terminal.  This is useful when you're piping test data into a
> > testbench and you don't want Ctrl-C to cause your terminal to be
> > flooded with endless output like this:
> 
> To me, it seems you'd may want to distinguish between stop due to the
> SIGINT signal, and $stop in the simulation.
> 
> And just change the SIGINT handling (set up in vvp/schedule.cc, it
> seems) to generate $finish instead of $stop, in the case that stdin
> isn't a tty.

Hello!

I was going along with what is there now, which is that the signal
handler always generates a stop, and that there is a stop_is_finish
flag which converts $stop to $finish which is set by the startup code
if you ask for noninteractive mode (-n) or set by the signal handler
if SIGHUP or SIGTERM are received.  What my patch does is basically
just act if -n is specified if standard input is not a tty.

You'd have to keep the stop_is_finish flag to implement -n, but then
you'd need an additional flag set at init time if stdin is not a tty
and check that flag from the signal handler (as I don't think you can
call isatty() from a signal handler) -- or, just split the signal
handler into two signal handlers, one that sets schedule_stopped_flag
and one that clears schedule_runnable, and then install the right one
in signals_capture() based on what mode we are in -- any preferences?

Re: [Iverilog-devel] How to debug the iverilog grammars?

[David F. <fa...@go...>]

In addition to enabling the tracing functionality in the parser generator,
you also have to set a global variable at run time to enable it.
If you look in the generated .c/.cc file produced by bison, it should be an
in ending with _debug.
Set that to 1, or control it with a flag.

On Sat, Jan 5, 2019 at 2:59 AM ca...@li... <ca...@li...>
wrote:

> Thanks guys for the replies.
>
> Yes I was looking for a way to activate the parse tracing features as
> explained here :
> https://www.slac.stanford.edu/comp/unix/gnu-info/bison_11.html .
>
> I have looked at the parse.output file that is generated but it shows the
> whole
> autamata which is very confusing (im extremely inexperienced with bison)
> whereas
> I would rather like to see the exact path the parser has taken at runtime,
> what tokens
> were encountered and what tokens where expected.
>
> From my understanding the parse trace functionality if enabled correctly
> should show me
> the exact states that were followed before my syntax error occurs.
>
> For our project I hope to add multi-state UDP tables into a branch or fork
> of iverilog to allow
> more concice gate-level RSFQ logic descriptions. I could share the git
> diff if anyone is interested.
>
> Kind regards
> Calvin
> _______________________________________________
> 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
>

Re: [Iverilog-devel] How to debug the iverilog grammars?

[<ca...@li...>]

Thanks guys for the replies.

Yes I was looking for a way to activate the parse tracing features as
explained here : https://www.slac.stanford.edu/comp/unix/gnu-info/bison_11.html .

I have looked at the parse.output file that is generated but it shows the whole
autamata which is very confusing (im extremely inexperienced with bison) whereas
I would rather like to see the exact path the parser has taken at runtime, what tokens
were encountered and what tokens where expected.

>From my understanding the parse trace functionality if enabled correctly should show me
the exact states that were followed before my syntax error occurs.

For our project I hope to add multi-state UDP tables into a branch or fork of iverilog to allow
more concice gate-level RSFQ logic descriptions. I could share the git diff if anyone is interested.

Kind regards
Calvin
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel

Re: [Iverilog-devel] automatically starting in noninteractive mode if standard input is not a terminal

[<ni...@ly...>]

Lennert Buytenhek <bu...@wa...> writes:

> I've been using the hack patch below to make Icarus Verilog
> automatically start in noninteractive mode when standard input is
> not a terminal.  This is useful when you're piping test data into a
> testbench and you don't want Ctrl-C to cause your terminal to be
> flooded with endless output like this:

To me, it seems you'd may want to distinguish between stop due to the
SIGINT signal, and $stop in the simulation.

And just change the SIGINT handling (set up in vvp/schedule.cc, it
seems) to generate $finish instead of $stop, in the case that stdin
isn't a tty.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.

Re: [Iverilog-devel] How to debug the iverilog grammars?

[Martin W. <ic...@ma...>]

Yes, look in the parse.output file in the appropriate directory (if you 
build in-tree, the same directory as the parse.y file you're modifying).

David Fang via Iverilog-devel wrote:
> When you say "syntax additions are failing", are you referring to
> shift-reduce/reduce-reduce conflicts in the grammar?
> Those appear in separate report, like a .output file that gives a
> human-readable state machine for the grammar automaton and shows where the
> conflicts are.
> Newer versions of bison let you specify the name of this output with
> --report-file=FILE.
> 
> On Thu, Jan 3, 2019 at 8:21 AM ca...@li... <ca...@li...>
> wrote:
> 
>> Hello all,
>>
>> Could someone please help me activate the YYDEBUG + parse tracing features
>> within the IVL compiler.
>>
>> I have tried "#defined YYDEBUG 1", as well as the '-t' flag, the '--debug'
>> flag and set the yydebug
>> variable to 1, but I cannot seem to get any information as to why my
>> syntax additions are failing.
>>
>> I greatly appreciate any assistance.
>>
>> Kind regards,
>> Calvin
>>
>> _______________________________________________
>> 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
> 

Re: [Iverilog-devel] How to debug the iverilog grammars?

[David F. <fa...@go...>]

When you say "syntax additions are failing", are you referring to
shift-reduce/reduce-reduce conflicts in the grammar?
Those appear in separate report, like a .output file that gives a
human-readable state machine for the grammar automaton and shows where the
conflicts are.
Newer versions of bison let you specify the name of this output with
--report-file=FILE.

On Thu, Jan 3, 2019 at 8:21 AM ca...@li... <ca...@li...>
wrote:

> Hello all,
>
> Could someone please help me activate the YYDEBUG + parse tracing features
> within the IVL compiler.
>
> I have tried "#defined YYDEBUG 1", as well as the '-t' flag, the '--debug'
> flag and set the yydebug
> variable to 1, but I cannot seem to get any information as to why my
> syntax additions are failing.
>
> I greatly appreciate any assistance.
>
> Kind regards,
> Calvin
>
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

[Iverilog-devel] automatically starting in noninteractive mode if standard input is not a terminal

[Lennert B. <bu...@wa...>]

Hello!

I've been using the hack patch below to make Icarus Verilog
automatically start in noninteractive mode when standard input is
not a terminal.  This is useful when you're piping test data into a
testbench and you don't want Ctrl-C to cause your terminal to be
flooded with endless output like this:

	$ ./gen | vvp ./detect
	[...]
	[1117850] 0   x x  x
	[1119450] 0   x x  x
	^C** VVP Stop(0) **
	** Flushing output streams.
	** Current simulation time is 1120750 ticks.
	> 0
	Unknown command: 0
	Try the help command to get a summary
	of available commands.
	> 0
	Unknown command: 0
	Try the help command to get a summary
	of available commands.
	> 0
	Unknown command: 0
	Try the help command to get a summary
	of available commands.
	> 0
	Unknown command: 0
	Try the help command to get a summary
	of available commands.
	[...]

Specifying -n by hand achieves the same thing, but there doesn't seem
to be a legitimate reason to make Ctrl-C cause piped (noninteractive)
input to be treated as commands if you don't explicitly pass in an
option to prevent that from happening, IMHO.

Not sure if this works on Windows or whether this is the right way to
do it, but any thoughts?

Thanks!



diff --git a/vvp/main.cc b/vvp/main.cc
index 5b598e4d..53cd5705 100644
--- a/vvp/main.cc
+++ b/vvp/main.cc
@@ -277,7 +277,7 @@ int main(int argc, char*argv[])
 
         /* For non-interactive runs we do not want to run the interactive
          * debugger, so make $stop just execute a $finish. */
-      stop_is_finish = false;
+      stop_is_finish = !isatty(0);
       while ((opt = getopt(argc, argv, "+hil:M:m:nNsvV")) != EOF) switch (opt) {
          case 'h':
            fprintf(stderr,

[Iverilog-devel] How to debug the iverilog grammars?

[<ca...@li...>]

Hello all,

Could someone please help me activate the YYDEBUG + parse tracing features within the IVL compiler.

I have tried "#defined YYDEBUG 1", as well as the '-t' flag, the '--debug' flag and set the yydebug
variable to 1, but I cannot seem to get any information as to why my syntax additions are failing.

I greatly appreciate any assistance.

Kind regards,
Calvin

Re: [Iverilog-devel] iverilog indefinite hang with no growing memory

[Martin W. <ic...@ma...>]

Standard Verilog didn't allow module ports to be arrays. So the rules for 
arrayed instances were quite simple:

   - if the bit width of the passed expression exactly matches
     the bit width of the port, connect the whole expression to
     every instance
   - else if the bit width of the passed expression is an
     integer multiple of the bit width of the port, divide the
     passed expression into equal parts and connect one part
     to each instance
   - else error

The passed expression had to be a bit vector (1D packed array).

SystemVerilog allows module ports to be arrays, so adds the option to
do what you are trying to do. But it seems that currently Icarus only 
supports that for output ports, not for input ports.

Morgan McClure wrote:
> So I guess my understanding of the spec is unclear - my understanding was
> that defining my_strobes as a packed array means that it's not going to be
> properly unrolled when I try to instantiate "mod_array_inst[15:0]" and it's
> going to jam a 16 bit wide signal into each instance's "strobe" signal
> which is a single bit.
> Am I misunderstanding the spec? Is it allowed to pass both a packed or an
> unpacked array to an array-style instantiation and as long as dimensions
> match it's figured out by the compiler to unpack by that dimension?
> My confusion really comes from the fact that "my_strobes" seems to behave
> differently than  "my_values" and "done_flags" does (and in fact it
> requires different array type - my_values seems to get unrolled along the
> packed dimension but my_strobes only allows unrolling along the packed
> dimension).
> 
> It looks like I made a typo originally, so I've attached an updated version
> that shows the now updated issue.
> done_flags (as an output) works as I expect but my_strobes (as an input)
> seems to require the opposite dimension to be unrolled.
> 
> 
> On Sat, Oct 13, 2018 at 2:26 PM Martin Whitaker <
> ic...@ma...> wrote:
> 
>> Your first alternative
>>
>>     wire [0] my_strobes[14:0];
>>
>> is illegal syntax. The compiler should of course output an erro message,
>> not go into an infinite loop.
>>
>> I think your second alternative
>>
>>     wire my_strobes[15:0];
>>
>> should work, but this is a SystemVerilog feature, so may not be
>> implemented
>> properly yet. Replacing it with
>>
>>     wire [15:0] my_strobes;
>>
>> should work.
>>
>> Morgan McClure wrote:
>>> Hi iVerilog devs,
>>> I've run into an interesting bug with iverilog compiling a module with
>>> unpacked-array instantiation of a module (not sure the correct naming for
>>> this syntax).
>>> When this occurs the CPU sits pegged at 100% but no memory growth and it
>>> never terminates.
>>> I've attached a self contained test program that exhibits the bug,
>>> alternately commenting line 40 or 42 changes the result (one throws a
>>> compiler error that I need an index, the other hangs)
>>>
>>> I'm running on mac, installed with homebrew, revision info here:
>>>
>>> icarus-verilog: stable 10.2 (bottled), HEAD
>>> Verilog simulation and synthesis tool
>>> http://iverilog.icarus.com/
>>> /usr/local/Cellar/icarus-verilog/10.2_1 (59 files, 5.5MB) *
>>>     Poured from bottle on 2018-08-08 at 10:09:06
>>> From:
>>>
>> https://github.com/Homebrew/homebrew-core/blob/master/Formula/icarus-verilog.rb
>>>
>>>
>>> Compilation arguments were simply:
>>> iverilog -g2005-sv test_me.v
>>>
>>> I've also attached a process sample while it's hung.
>>>
>>> Please let me know if I can provide more information.
>>>
>>> Thanks,
>>> -Morgan
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
> 

Re: [Iverilog-devel] iverilog indefinite hang with no growing memory

[Morgan M. <mcc...@gm...>]

So I guess my understanding of the spec is unclear - my understanding was
that defining my_strobes as a packed array means that it's not going to be
properly unrolled when I try to instantiate "mod_array_inst[15:0]" and it's
going to jam a 16 bit wide signal into each instance's "strobe" signal
which is a single bit.
Am I misunderstanding the spec? Is it allowed to pass both a packed or an
unpacked array to an array-style instantiation and as long as dimensions
match it's figured out by the compiler to unpack by that dimension?
My confusion really comes from the fact that "my_strobes" seems to behave
differently than  "my_values" and "done_flags" does (and in fact it
requires different array type - my_values seems to get unrolled along the
packed dimension but my_strobes only allows unrolling along the packed
dimension).

It looks like I made a typo originally, so I've attached an updated version
that shows the now updated issue.
done_flags (as an output) works as I expect but my_strobes (as an input)
seems to require the opposite dimension to be unrolled.


On Sat, Oct 13, 2018 at 2:26 PM Martin Whitaker <
ic...@ma...> wrote:

> Your first alternative
>
>    wire [0] my_strobes[14:0];
>
> is illegal syntax. The compiler should of course output an erro message,
> not go into an infinite loop.
>
> I think your second alternative
>
>    wire my_strobes[15:0];
>
> should work, but this is a SystemVerilog feature, so may not be
> implemented
> properly yet. Replacing it with
>
>    wire [15:0] my_strobes;
>
> should work.
>
> Morgan McClure wrote:
> > Hi iVerilog devs,
> > I've run into an interesting bug with iverilog compiling a module with
> > unpacked-array instantiation of a module (not sure the correct naming for
> > this syntax).
> > When this occurs the CPU sits pegged at 100% but no memory growth and it
> > never terminates.
> > I've attached a self contained test program that exhibits the bug,
> > alternately commenting line 40 or 42 changes the result (one throws a
> > compiler error that I need an index, the other hangs)
> >
> > I'm running on mac, installed with homebrew, revision info here:
> >
> > icarus-verilog: stable 10.2 (bottled), HEAD
> > Verilog simulation and synthesis tool
> > http://iverilog.icarus.com/
> > /usr/local/Cellar/icarus-verilog/10.2_1 (59 files, 5.5MB) *
> >    Poured from bottle on 2018-08-08 at 10:09:06
> > From:
> >
> https://github.com/Homebrew/homebrew-core/blob/master/Formula/icarus-verilog.rb
> >
> >
> > Compilation arguments were simply:
> > iverilog -g2005-sv test_me.v
> >
> > I've also attached a process sample while it's hung.
> >
> > Please let me know if I can provide more information.
> >
> > Thanks,
> > -Morgan
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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
>

Re: [Iverilog-devel] iverilog indefinite hang with no growing memory

[Martin W. <ic...@ma...>]

Your first alternative

   wire [0] my_strobes[14:0];

is illegal syntax. The compiler should of course output an erro message, 
not go into an infinite loop.

I think your second alternative

   wire my_strobes[15:0];

should work, but this is a SystemVerilog feature, so may not be implemented 
properly yet. Replacing it with

   wire [15:0] my_strobes;

should work.

Morgan McClure wrote:
> Hi iVerilog devs,
> I've run into an interesting bug with iverilog compiling a module with
> unpacked-array instantiation of a module (not sure the correct naming for
> this syntax).
> When this occurs the CPU sits pegged at 100% but no memory growth and it
> never terminates.
> I've attached a self contained test program that exhibits the bug,
> alternately commenting line 40 or 42 changes the result (one throws a
> compiler error that I need an index, the other hangs)
> 
> I'm running on mac, installed with homebrew, revision info here:
> 
> icarus-verilog: stable 10.2 (bottled), HEAD
> Verilog simulation and synthesis tool
> http://iverilog.icarus.com/
> /usr/local/Cellar/icarus-verilog/10.2_1 (59 files, 5.5MB) *
>    Poured from bottle on 2018-08-08 at 10:09:06
> From:
> https://github.com/Homebrew/homebrew-core/blob/master/Formula/icarus-verilog.rb
> 
> 
> Compilation arguments were simply:
> iverilog -g2005-sv test_me.v
> 
> I've also attached a process sample while it's hung.
> 
> Please let me know if I can provide more information.
> 
> Thanks,
> -Morgan
> 
> 
> 
> 
> 
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 

[Iverilog-devel] iverilog indefinite hang with no growing memory

[Morgan M. <mcc...@gm...>]

Hi iVerilog devs,
I've run into an interesting bug with iverilog compiling a module with
unpacked-array instantiation of a module (not sure the correct naming for
this syntax).
When this occurs the CPU sits pegged at 100% but no memory growth and it
never terminates.
I've attached a self contained test program that exhibits the bug,
alternately commenting line 40 or 42 changes the result (one throws a
compiler error that I need an index, the other hangs)

I'm running on mac, installed with homebrew, revision info here:

icarus-verilog: stable 10.2 (bottled), HEAD
Verilog simulation and synthesis tool
http://iverilog.icarus.com/
/usr/local/Cellar/icarus-verilog/10.2_1 (59 files, 5.5MB) *
  Poured from bottle on 2018-08-08 at 10:09:06
From:
https://github.com/Homebrew/homebrew-core/blob/master/Formula/icarus-verilog.rb


Compilation arguments were simply:
iverilog -g2005-sv test_me.v

I've also attached a process sample while it's hung.

Please let me know if I can provide more information.

Thanks,
-Morgan

Re: [Iverilog-devel] ICARUS_VPI_CONST

[Stephen W. <st...@ic...>]

If it doesn't leak into user code that includes vpi_user.h, then I can't
imagine why there would be a problem.

On Sat, Sep 29, 2018 at 4:30 AM Martin Whitaker <
ic...@ma...> wrote:

> In response to https://github.com/steveicarus/iverilog/issues/201, I've
> just pushed a few more fixes for const-correctness when ICARUS_VPI_CONST
> is
> defined as "const". Is there any reason why we shouldn't now make this the
> default when building Icarus?
>
> I realise we need to be careful to avoid the definition propagating into
> iverilog-vpi.
>
>
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>


-- 
Steve Williams                "The woods are lovely, dark and deep.
st...@ic... <ste...@gm...>              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."

[Iverilog-devel] ICARUS_VPI_CONST

[Martin W. <ic...@ma...>]

In response to https://github.com/steveicarus/iverilog/issues/201, I've 
just pushed a few more fixes for const-correctness when ICARUS_VPI_CONST is 
defined as "const". Is there any reason why we shouldn't now make this the 
default when building Icarus?

I realise we need to be careful to avoid the definition propagating into 
iverilog-vpi.