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
>