Flip-flops uninitialization causes issues in gate-level simulation.

[nathanchandanson]

Hello everyone.
I am trying to get a full chip with a FABulous FPGA embedded. Right now, I am trying to simulate the gate-level netlist that Librelane outputs at the end of the chip flow.

I am having issues with the simulation as I think the flip-flops used in the fabric are not initialized with a value.
Thus, the simulator sets them to x and propagates them through the design.

Has anyone had the same issue as me ?
And if yes, what was your solution ?

Thank you in advance.

[mole99]

The flip-flop within FABULOUS_LC is not initialized during bitstream upload. The solution is to create an explicit reset signal in your user design, which you assert after the bitstream has been uploaded.

The fabulous-fabrics setup actually specifies that the flip-flops cannot be initialized: https://github.com/FPGA-Research/fabulous-fabrics/blob/bb5d98490fbc99f1f0662f072d3819b7a9b2d663/user_designs/makefile.include#L10
We are planning to switch to this setup after FABulous 2.0 has been released. For now, simply ensure that all your flip-flops are properly reset.

[nathanchandanson]

Hi thank you for your answer.
I am using the default sequential_16bit_en user design so there already is a reset signal.

Basically the issue I am having is that on the 6 output pins I use, 5 of them work as expected, while one of the pins is x.
I use Questa, and tried to trace the source of this x, and while I couldn't pinpoint the exact source of the x, I noticed that some of the flip-flop primitives oscillated between x and a binary value.

As the only x's I could find in the design are coming from flip-flops, I assumed that the problem was due to the uninitialization.

[EverythingElseWasAlreadyTaken]

Hey,

this is a known problem that we have with gate level simulation of our fabrics using open source tools.
We already had a discussion about this here:
#252

If you have access to commercial simulators, you can also try those, since they can usually define default values for flops.

[mole99]

I'm not sure if this still fully applies. I was able to simulate some user design on sky130/gf180mcu/ihp-sg13g2 with the GL netlist on Icarus Verilog. However, other user designs either failed or got stuck.

[nathanchandanson]

I have the same issue as you @EverythingElseWasAlreadyTaken.

Regarding the initialization you did using cvc, I tried the same with Questa and got exactly the same result. The simulation started and at some point it freezes due to combinational loops.

I'm not sure if this still fully applies. I was able to simulate some user design on sky130/gf180mcu/ihp-sg13g2 with the GL netlist on Icarus Verilog. However, other user designs either failed or got stuck.

I think this is the same problem as I have : with some designs, the initialization works correctly while in other designs it does not.

[nathanchandanson]

Hi, I have some news.

I tried setting everything to 0 using the +initreg+0 +initmem+0 +initwire+0 flags, but this lead to a freeze of Questa due to the combinational loops of the fabric.

The issue comes from a flip-flop whose D value is not set when resetting the counter. This is quite strange as the others flip-flops of the counter are correctly initialized when resetting.
A workaround is just to deposit a 0 by hand on this flip-flop's input after the reset.

I will try to find what causes the uninitialization of this specific flip-flop and post an update if I find something.

[nathanchandanson]

I tried with a slightly different design (assigning different bits of the counter to the pins), and now all the pins become x value.
I can still make it work by depositing a 0 to all the Q inputs of the flip-flops that make up the counter in my design.
I think I had some luck with the first design.

I can replicate the same result (getting x's) in icarus verilog so this means that it is not a Questa issue.

I think this is probably due to the fact that there are a lot of combinational loops involved.