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

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

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.