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

[Galen S. <ga...@se...>]

On 8/9/19 1:16 PM, Martin Whitaker wrote:
> 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.

Thanks, I'll give it a try.

Regarding the question in the subject line, do you have a preferred way 
of running iverilog and vvp when you are working on the Icarus code?

galen
-- 
Galen Seitz
ga...@se...