iverilog-devel — Conversations on matters of Icarus Verilog development

[Iverilog-devel] Actual 10.3 Release

[Stephen W. <st...@ic...>]

As promised, I have made up a 10.3 release of the stable branch of
Icarus Verilog. Specifically, I've made up the main source tarball
which can be downloaded from here:

ftp://ftp.icarus.com/pub/eda/verilog/v10/verilog-10.3.tar.gz

There is also a SRPM file in the same directory, and a binary rpm for
openSUSE 15.1 that I built as a test of the packaging.

>From here, there are lots of places that the release needs to
propagate, many of which I am not even aware of, so go ahead and test
it out and pass it around.

-- 
Steve Williams                "The woods are lovely, dark and deep.
st...@ic...              But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

[Iverilog-devel] Make iverilog accept (but ignore) unsupported SDF constructs.

[Stefan D. <Dr...@ri...>]

Hi everyone,

I was trying to run a post-synthesis simulation using iverilog with a netlist generated by Xilinx Vivado.

I ran into a problem that iverilog complains about the SDF file containing invalid syntax, as some of the keywords are not implemented in iverilogs sdf parser. The problematic constructs for my case are `PATHPULSEPERCENT` within the `DELAY` construct and `PERIOD` within the `TIMINGCHECK` construct. See the end of the email for a snippet of the sdf file.

 

I checked the IEEE1497-2001 standard and the problematic constructs are valid as far as I can see (so no Xilinx specific weirdness here)

 

I dont really need the functionality offered by these constructs, but it would be nice if iverilog could still accept the file as valid and simulate only with the supported subset, maybe printing a warning about what was ignored.

 

The problematic sdf code:

 

(DELAYFILE 

(SDFVERSION "3.0" )

(DESIGN "top")

(DATE "Tue Aug 13 18:03:42 2019")

(VENDOR "XILINX")

(PROGRAM "Vivado")

(VERSION "2019.1")

(DIVIDER /)

(TIMESCALE 1ps)

(CELL 

  (CELLTYPE "BUFGCE")

  (INSTANCE clk_IBUF_BUFG_inst)

  (DELAY 

    (PATHPULSEPERCENT (30,0))

    (ABSOLUTE 

      (IOPATH I O (40.0:47.0:47.0) (40.0:47.0:47.0))

    )

  )

    (TIMINGCHECK

      (SETUPHOLD (posedge CE) (posedge I) (84.0:275.0:275.0) (0.0:0.0:0.0))

      (SETUPHOLD (negedge CE) (posedge I) (84.0:275.0:275.0) (0.0:0.0:0.0))

      (PERIOD (posedge I) (1499.0:1499.0:1499.0))

      (PERIOD (negedge I) (1499.0:1499.0:1499.0))

      (WIDTH (negedge CE) (550.0:550.0:550.0))

      (WIDTH (posedge CE) (550.0:550.0:550.0))

    )

)

)

 

 

Kind Regards, Stefan

[Iverilog-devel] Time 0 races

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

Evan Lavelle wrote:
> Here's one I spent a few hours on:
> 
> module test;
>    event done;
>    initial begin
>      // #0;
>      foo;   // may or may not finish in zero time
>      -> done;
>    end
>    always @(done)
>      ...    // may or may not fire
> endmodule
> 
> There's a race between event creation and event triggering, and this code 
> "fails" in 4/7 simulators (including Incisive). Uncommenting the #0 makes 
> it run on all 7 simulators.
> ?!

I delved into the Icarus compiler code, and found the rules for 
prioritising always constructs are more complex than I remembered. It tries 
to identify always constructs that are modelling combinatorial logic, and 
only prioritises those. Your example above doesn't qualify - I think 
because it is sensitive to an event, not a signal.

I tested this example:

module test();
   reg i, q;
   initial i = 1;
   always @(i) q = i;
   initial #1 $display(q);
endmodule

Icarus and Riveria Pro output '1'. CVer and Veriwell output 'x'. Moving the 
always construct to before the initial constructs results in all four 
outputing '1'.

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

[Evan L. <sa2...@cy...>]

Here's one I spent a few hours on:

module test;
   event done;
   initial begin
     // #0;
     foo;   // may or may not finish in zero time
     -> done;
   end
   always @(done)
     ...    // may or may not fire
endmodule

There's a race between event creation and event triggering, and this 
code "fails" in 4/7 simulators (including Incisive). Uncommenting the #0 
makes it run on all 7 simulators.
?!

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

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

Galen Seitz wrote:
> On 8/10/19 2:05 AM, Evan Lavelle wrote:
>> On 09/08/2019 19:17, Martin Whitaker wrote:
>>
>>> However, Icarus tries to protect the user against such problems by 
>>> preferentially scheduling "always" processes ahead of "initial" 
>>> processes at time 0. 
>>
>> Wow. Never heard of that before. I wonder if other vendors do that?
> 
> For the case that we've been discussing, I don't understand why it isn't 
> always deterministic.  Given the code below, doesn't the initial block 
> generate an update event at time 0, and doesn't that cause the NBA inside 
> the always block to be scheduled?  If that is true, then when a sequential 
> UDP with an initial statement is substituted for the initial block below, 
> then doesn't the same logic apply?
> 
> reg a;
> reg y;
> 
> initial begin
>      a = 0;
> end
> 
> always @(a) begin
>      y <= a;
> end

 From the IEEE standard:

"The initial and always constructs are enabled at the beginning of a 
simulation. The initial construct shall execute only once, and its activity 
shall cease when the statement has finished. In contrast, the always 
construct shall execute repeatedly. Its activity shall cease only when the 
simulation is terminated. There shall be no implied order of execution 
between initial and always constructs. The initial constructs need not
be scheduled and executed before the always constructs."

So if the initial construct executes before the always construct, the 
procedural timing control "@(a)" won't have been executed when the 
assignment to "a" occurs, so won't be waiting for an update event.

It may help to explain that

always @(a) begin
     y <= a;
end

is exactly equivalent to

always begin
     @(a) y <= a;
end

i.e. the "@(a)" is part of the first statement executed by the always 
construct, not something that is continually active.

Given that other simulators don't suffer from this race, it seems quite 
likely that other vendors also prioritise always constructs at the start of 
simulation.

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

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

On 8/10/19 2:05 AM, Evan Lavelle wrote:
> On 09/08/2019 19:17, Martin Whitaker wrote:
> 
>> However, Icarus tries to protect the user against such problems by 
>> preferentially scheduling "always" processes ahead of "initial" 
>> processes at time 0. 
> 
> Wow. Never heard of that before. I wonder if other vendors do that?

For the case that we've been discussing, I don't understand why it isn't 
always deterministic.  Given the code below, doesn't the initial block 
generate an update event at time 0, and doesn't that cause the NBA 
inside the always block to be scheduled?  If that is true, then when a 
sequential UDP with an initial statement is substituted for the initial 
block below, then doesn't the same logic apply?

reg a;
reg y;

initial begin
	a = 0;
end

always @(a) begin
	y <= a;
end


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

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

[Evan L. <sa2...@cy...>]

On 09/08/2019 19:17, Martin Whitaker wrote:

> However, Icarus tries to protect the user against such problems by 
> preferentially scheduling "always" processes ahead of "initial" 
> processes at time 0. 

Wow. Never heard of that before. I wonder if other vendors do that?

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.

I have tested my code using master, and the issue is resolved.  Thanks 
for the quick fix/workaround.

It's unfortunate that the Lattice model was written in this way, but I'm 
certain I would have zero chance of getting them to make a change.

FWIW, here's a simplified simulation that has all of the Lattice code 
removed.  I substituted a simple toggle sequential UDP for the Lattice 
flip-flop.  This has both a reg that is assigned in an initial block and 
a UDP output that has an initial statement.  Each feeds an 'always @ 
sig' block.
<https://www.edaplayground.com/x/3S7P>


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

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

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

Galen Seitz wrote:
> 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?
> 
I always run 'make install'. If you don't want to affect your working 
installation, run configure with the --prefix option to set the 
installation root to someplace else, or with the --suffix option to make 
the filenames unique. If you want to keep multiple builds for comparison, 
you can build out-of-tree.

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...

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.

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.

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

[Evan L. <sa2...@cy...>]

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).

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

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

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'd like 
to run iverilog and vvp without installing.  I have tried using the '-B' 
option, but doing the obvious thing of setting it to the top of the 
build directory doesn't seem to work.  What is the correct way to do this?

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

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

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

On 8/8/19 4:13 PM, Martin Whitaker wrote:
> Galen Seitz wrote:
>> I was hesitant to post a link to Lattice copyrighted code, as I wasn't 
>> sure whether that was acceptable on the list.  That github project 
>> link contains the entire simulation library for the XP2 family, so 
>> I've decided not to worry about posting a link to a few files from the 
>> MachXO3 family.
>>
>> <https://www.edaplayground.com/x/3EKT>
>>
>> After running the simulation, from the EPWave window, click "Get 
>> Signals", then select the ".ff" instance.  Click the "Append All" 
>> button.  These are the ports of the .ff instance of the FD1P3DX 
>> module, which are the signals I've been looking at.
>>
>> If accessing EDA playground is a problem, let me know, and I will 
>> arrange other access to the files.
>>
>> My test design that demonstrates the problem consists of a testbench 
>> and four files from the Lattice library.  GSR.v is a global reset, and 
>> should be unused.  PUR.v is a power up reset which generates a 1 ns 
>> reset pulse starting at time 0.  FD1P3DX.v is some sort of wrapper 
>> around the UDFDL5E_UDP_X.v primitive.  When I grep the Lattice library 
>> I find that there are six modules that instance this particular UDP 
>> primitive.
>>
>> 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.
>>
>> With iverilog 0.10.0, the Q output is X at time 0 and remains X for 
>> the entire simulation.  With any other simulator on EDA playground, Q 
>> is 0 at time 0, and remains 0 for the entire simulation.  This 
>> includes iverilog 0.9.7 and 0.9.6.
> 
> If you look inside the FD1P3DX module, the QB signal output from the UDP 
> is correctly set to 0. The problem appears to be a race between the 
> execution of the "initial Q=1'b0;" inside the UDP and the execution of 
> the "always @ QB" inside the FD1P3DX module. If the initial statement is 
> executed first, the "@ QB" will never trigger.

I have created a simplified design for testing.  I replaced the Lattice 
UDP with this:

primitive dummy_udp(Q, D);
input D;
output Q;
	table
	   ? : 0;
	endtable
endprimitive


And what was the flip-flop wrapper now looks like this:

`timescale 1ns/100ps

module dummy(D, Q);
   input D;
   output Q;
   reg Q;
   wire QB;

   dummy_udp u2 (QB, D);

   always @ QB
   begin
       Q <= QB;
   end

endmodule



Using this design, I still get the same unknown from the "always @ QB". 
The full design is here:

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

It seems odd to me that only iverilog 0.10 gives this result when all 
other simulators on EDA playground show the output at 0.  I know next to 
nothing about simulator internals.  Am I being unrealistic in expecting 
this to work?  Given that the original flip-flop where I encountered 
this is Lattice code and not my own, my naïve expectation is that their 
models would operate correctly.


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

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

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

Galen Seitz wrote:
> I was hesitant to post a link to Lattice copyrighted code, as I wasn't sure 
> whether that was acceptable on the list.  That github project link contains 
> the entire simulation library for the XP2 family, so I've decided not to 
> worry about posting a link to a few files from the MachXO3 family.
> 
> <https://www.edaplayground.com/x/3EKT>
> 
> After running the simulation, from the EPWave window, click "Get Signals", 
> then select the ".ff" instance.  Click the "Append All" button.  These are 
> the ports of the .ff instance of the FD1P3DX module, which are the signals 
> I've been looking at.
> 
> If accessing EDA playground is a problem, let me know, and I will arrange 
> other access to the files.
> 
> My test design that demonstrates the problem consists of a testbench and 
> four files from the Lattice library.  GSR.v is a global reset, and should 
> be unused.  PUR.v is a power up reset which generates a 1 ns reset pulse 
> starting at time 0.  FD1P3DX.v is some sort of wrapper around the 
> UDFDL5E_UDP_X.v primitive.  When I grep the Lattice library I find that 
> there are six modules that instance this particular UDP primitive.
> 
> 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.
> 
> With iverilog 0.10.0, the Q output is X at time 0 and remains X for the 
> entire simulation.  With any other simulator on EDA playground, Q is 0 at 
> time 0, and remains 0 for the entire simulation.  This includes iverilog 
> 0.9.7 and 0.9.6.

If you look inside the FD1P3DX module, the QB signal output from the UDP is 
correctly set to 0. The problem appears to be a race between the execution 
of the "initial Q=1'b0;" inside the UDP and the execution of the "always @ 
QB" inside the FD1P3DX module. If the initial statement is executed first, 
the "@ QB" will never trigger.

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...

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

[Evan L. <sa2...@cy...>]

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.

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

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

On 8/8/19 12:26 AM, Evan Lavelle wrote:
> Is this:
> 
> https://github.com/flexSD/flexSD/blob/master/XP2%20Verilog%20Primitives/UDFDL5E_UDP_X.v 
> 
> 
> the UDP that's failing?
> 
> If so, how are you driving it? What are the D, CK, CE, CLR, and notifier 
> inputs doing at or soon after time 0?

I was hesitant to post a link to Lattice copyrighted code, as I wasn't 
sure whether that was acceptable on the list.  That github project link 
contains the entire simulation library for the XP2 family, so I've 
decided not to worry about posting a link to a few files from the 
MachXO3 family.

<https://www.edaplayground.com/x/3EKT>

After running the simulation, from the EPWave window, click "Get 
Signals", then select the ".ff" instance.  Click the "Append All" 
button.  These are the ports of the .ff instance of the FD1P3DX module, 
which are the signals I've been looking at.

If accessing EDA playground is a problem, let me know, and I will 
arrange other access to the files.

My test design that demonstrates the problem consists of a testbench and 
four files from the Lattice library.  GSR.v is a global reset, and 
should be unused.  PUR.v is a power up reset which generates a 1 ns 
reset pulse starting at time 0.  FD1P3DX.v is some sort of wrapper 
around the UDFDL5E_UDP_X.v primitive.  When I grep the Lattice library I 
find that there are six modules that instance this particular UDP primitive.

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.

With iverilog 0.10.0, the Q output is X at time 0 and remains X for the 
entire simulation.  With any other simulator on EDA playground, Q is 0 
at time 0, and remains 0 for the entire simulation.  This includes 
iverilog 0.9.7 and 0.9.6.

Thanks for looking at this!


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

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

[Evan L. <sa2...@cy...>]

Is this:

https://github.com/flexSD/flexSD/blob/master/XP2%20Verilog%20Primitives/UDFDL5E_UDP_X.v

the UDP that's failing?

If so, how are you driving it? What are the D, CK, CE, CLR, and notifier 
inputs doing at or soon after time 0?

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

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

On 8/6/19 3:55 PM, Galen Seitz wrote:
> Hi,
> 
> I just stumbled onto a simulation issue while simulating a Lattice 
> MachXO3 design.  I've narrowed it down to the FD1P3DX.v (a simple 
> flip-flop) and UDFDL5E_UDP_X.v (the underlying primitive) simulation 
> files that come with the Lattice tools (Diamond 3.11_x64 under CentOS 
> 7.6).  With Icarus version 10.2 (from epel), the output of the flip-flop 
> is X at time 0 even though reset is being asserted.  I built and tested 
> using iverilog from the HEAD of the v10 branch (commit b7b22660) and I 
> get the same results.
> 
> Using EDA playground I get the following iverilog results:
> iverilog 0.9.6        flip-flop Q = 0
> iverilog 0.9.7        flip-flop Q = 0
> iverilog 0.10.0        flip-flop Q = X
> 
> All of the other simulators that I have tried on EDA playground give 
> flip-flop Q = 0 as a result.  This includes Synopsys, Cadence, and 
> Aldec, as well as Cver and VeriWell.  It seems that something changed in 
> 0.10 to break this particular simulation.

For what it's worth, further testing of various iverilog builds gives 
these results:

flip-flop Q = 0 (working)
-------------------------
v0_9-branch


flip-flop Q = X (broken)
------------------------
master
s20150513
s20130827


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

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

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

Hi,

I just stumbled onto a simulation issue while simulating a Lattice 
MachXO3 design.  I've narrowed it down to the FD1P3DX.v (a simple 
flip-flop) and UDFDL5E_UDP_X.v (the underlying primitive) simulation 
files that come with the Lattice tools (Diamond 3.11_x64 under CentOS 
7.6).  With Icarus version 10.2 (from epel), the output of the flip-flop 
is X at time 0 even though reset is being asserted.  I built and tested 
using iverilog from the HEAD of the v10 branch (commit b7b22660) and I 
get the same results.

Using EDA playground I get the following iverilog results:
iverilog 0.9.6		flip-flop Q = 0
iverilog 0.9.7		flip-flop Q = 0
iverilog 0.10.0		flip-flop Q = X

All of the other simulators that I have tried on EDA playground give 
flip-flop Q = 0 as a result.  This includes Synopsys, Cadence, and 
Aldec, as well as Cver and VeriWell.  It seems that something changed in 
0.10 to break this particular simulation.

The simulation files are copyright Lattice, but are included in any 
Diamond installation.  Currently I have a playground configured that 
shows the problem (by looking at the wave output).  I can share a link 
to the playground.  Is that acceptable?

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

[Iverilog-devel] Potential 10.3 release

[Stephen W. <st...@ic...>]

Hi all,

It's been a pretty long time, and a lot of fixes have found their way
into the version 10 branch, so I'm considering making a 10.3 release.
A proper release will make it more likely for these fixes to find
their way into common distributions. I expect to make up the base
release in the next few days.

Martin and Cary have been doing most of the development these days, so
they have first veto. If you have a problem report that you think
should make 10.3, post here in the next few days, and we'll consider
it.

-- 
Steve Williams                "The woods are lovely, dark and deep.
st...@ic...              But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

[Iverilog-devel] ICuras and Verilator

[fuyong <fuy...@gm...>]

Hi,

Anyone has been using Icuras and Verilator together, with Icuras handling
the testbench and Verilator handle the design in pure synthesizable Verilog?

Thanx,
Yong

[Iverilog-devel] Looking for co-founder startup partner

[Le N. T. <lnt...@gm...>]

Hello,

I am Nguyen Tran, and I am look for for a co-founder startup partner. If
any one of you are interested in my idea, please do not hesitate to contact
me.

I introduce shortly about myself here. I have PhD degree and more than 10
years of working experience in ASIC design. My main fields are computer
architecture and ASIC design. I am currently a chip designer for a very
reputable company.

My idea is to develop a very fast RTL simulator. The key point is using
FPGA to accelerate the simulation. We do not use FPGA as an emulator.
Instead, we implement a custom many-core processor to run RTL simulation.
We believe that the normal currently CPU (like from Intel or AMD) are not
efficient for RTL simulation. Although the CPU has a number of cores,
utilising all of them for RTL simulation is not very efficient due to the
high overhead for thread synchronization. If we implement a custom
processor using FPGA, we can minimize thread synchronization, offer 4-level
logic ('1', '0', 'x', 'z') calculation, and utilize parallel simulation
among modules and processes... That accelerates RTL simulation.

Our RTL simulator will support DPI so that it can work with other tools
like Incisive, VCS, Questa. In this case, the RTL simulation is handled by
our tool, and the UVM verification is handled by the other one. That allows
our tool can be integrated easily in many current ASIC design flows.

To develop our simulator, I will handle the FPGA development part. I
expected to have a co-founder partner develop a RTL compiler for it.

I look forward to hearing from you and thank you so much for your time.

Best regards,

Nguyen.