Re: [Iverilog-devel] running iverilog and vvp from the build tree (no make install)

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

Martin Whitaker wrote:
> On 09/08/19 10:11, Evan Lavelle wrote:
>> On 09/08/2019 01:28, Galen Seitz wrote:
>>> Hello again,
>>>
>>> In order to track down the commit that caused the behavior change 
>>> between 0.9 and 0.10 that is being discussed in another thread,
>>
>> I wouldn't bother. If Martin's right (and I'm sure he is) then this is a 
>> 'feature' in the Lattice model, and whether or not Q initialises 
>> correctly is just a roll of the dice (but probably deterministic for a 
>> given simulator). You may be able to find a switch on one of the other 
>> simulators to randomise the initialisation order, which would be 
>> interesting - you should find that Q resets on some runs but not on 
>> others (Steve wanted to do this for Icarus, but I don't think it ever 
>> happened).
>>
>> This is exactly what SV's 'always_comb' is meant to fix. This was a very 
>> late attempt to rationalise simulation start-up in Verilog (to, 
>> curiously, exactly what VHDL had done since day #1).
> 
> And indeed, replacing the "always @ QB" with "always_comb" fixes the problem.
> 
> However, Icarus tries to protect the user against such problems by 
> preferentially scheduling "always" processes ahead of "initial" processes 
> at time 0. The reason it is not working in this case is that the initial 
> process in a UDP is handled differently to normal initial processes, and in 
> v10 and later is being scheduled ahead of the "always" processes. Although 
> this is legal behaviour, I will look at changing it to restore the more 
> user-friendly behaviour of v0.9.

I've pushed the change to both the master and v10 branches.