Re: [Iverilog-devel] possible regression in 0.10 when simulating Lattice FF

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

On 8/8/19 10:54 AM, Evan Lavelle wrote:
> On 08/08/2019 18:09, Galen Seitz wrote:
> 
>> My testbench generates a reset signal that is 2 clocks long.  The D 
>> input is tied to 0, and the enable is tied to 1.  Notifier is an 
>> internal signal of FD1P3DX and is X, but that doesn't seem to impact 
>> the simulation.
> 
> You really need to write a testbench that instantiates a single 
> UDFDL5E_UDP_X, and then drives D, CK, CE, CLR, and notifier with 
> whatever they're doing in your real design for those 2 cycles. That 
> would be sufficient to show whether or not the UDP handling has broken. 
> My suspicion is that 'notifier' is changing from something to X, which 
> would result in what you're seeing. That wouldn't really help, though, 
> since it would point to a (timing) error in whatever is instantiating 
> the UDP in your design.

Here is a simulation that contains only the testbench and the UDP 
primitive. notifier is not assigned, and hence is X for the entire 
simulation time.  This matches what the Lattice FD1P3DX module does. 
This simulation gives the expected result (Q = 0) for all simulators, 
include iverilog 0.10.

<https://www.edaplayground.com/x/4Cms>

It would seem that the FD1P3DX wrapper is what is triggering the bug.  I 
will try to create a simulation that trims it down to the bare minimum.

In my real design I used the Lattice IP generation tool to generate a 
clocked ROM.  The code created by the tool instantiates the FD1P3DX 
module as part of the address decoding.  While simulating my design, I 
discovered that the output of the FD1P3DX was unknown.  That is how I 
ended up looking into this.

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