Menu
▾
▴
iverilog-devel
|
From: Galen S. <ga...@se...> - 2019-08-06 23:11:00
|
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... |
|
From: Galen S. <ga...@se...> - 2019-08-08 00:37:11
|
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... |
|
From: Evan L. <sa2...@cy...> - 2019-08-08 07:40:49
|
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? |
|
From: Galen S. <ga...@se...> - 2019-08-08 17:10:04
|
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... |
|
From: Evan L. <sa2...@cy...> - 2019-08-08 17:55:07
|
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. |
|
From: Galen S. <ga...@se...> - 2019-08-08 22:08:24
|
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... |
|
From: Martin W. <ic...@ma...> - 2019-08-08 23:26:15
|
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. |
|
From: Galen S. <ga...@se...> - 2019-08-08 23:54:10
|
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... |
Thanks for helping keep SourceForge clean.
X