ice40: Maybe a connection is missing in carry_passout in the generated netlist

[tarikgraba]

Hi,

We have sometimes issue simulating ice40 post-pr netlists generated by nextpnr (while correctly behaving on the device).

We have tried to track the issue and I think it is related to the way carry cells and lut are packed in logic cells when both the carry and lut output are used.

More precisely, we found that adding a connection between the I3 input and the CIN input here:

nextpnr/ice40/chains.cc

Line 126 in cfa5f77

// If COUT also connects to a CIN; preserve the carry chain

solves the issues for me.

Something like:

         // If COUT also connects to a CIN; preserve the carry chain
         if (cin_cell) {
+            lc->connectPort(id_CIN, co_i3_net);
             NetInfo *co_cin_net = ctx->createNet(ctx->id(lc->name.str(ctx) + "$COUT"));
 
             // Connect I1 to 1 to preserve carry chain

Maybe someone with better knowledge of ICE40 arch and nextpnr internals can take a look at this/give us some hints.

[whitequark]

We have sometimes issue simulating ice40 post-pr netlists generated by nextpnr (while correctly behaving on the device).

This description of a problem is too vague to be useful. Please provide a specific (preferably, minimized) example demonstrating the sim/P&R mismatch. Also, a sim/P&R mismatch where the hardware works as expected would normally be addressed by changing the simulation models, not the P&R code. Why are you changing the P&R code? Is there a rationale for the change besides "it makes some unspecified test pass"?

[tarikgraba]

Yes I know that the description is vague (sorry didn't find the correct way to express my issue).
I will try to build a minimal example to showcase the behavior.

Regarding modifying the simulation model, it was my first thought. The simulation model provided with yosys contains models for the LogicCells (LC) and it seems correct for me (and its behavior seems similar to the Lattice/Libero provided one).

Regarding the modification of the P&R code.

As I understand (from reading the iCE40 datatasheet) there is a configurable path in the LC from CIN to the input of the LUT that bypasses the I3 input. But no path from I3 to COUT (and the simulation model respects this behavior).

As I understand the P&R code (in chains.cc) we are supposed to have O = I3 while still propagating the carry from the previous cell.

And the issue that I observe in post simulation is that the carry is not propagated because it seems that there is no path from I3 to cout.
connecting to CIN the same signal that arrives at I3 resolves the issue.

But maybe I am missing something here.

[tarikgraba]

@whitequark I have uploaded an example of code with mismatch between post-syn and post-pr simulation here:

https://github.com/tarikgraba/nextpnr-ice40-post-pr-sim

(I have uploaded the RTL, a testbench and the post-syn/pr netlists (json and v)).

I have tested the design on real hardware and it is functional.

The post-pr simulation fails.
I have tracked the issue to 2 ICESTORM_LC instances (20 and 21) where both O (lut output) and COUT (carry chain output) are used, but CIN (carry input) is not connected.
Connecting to CIN the signal arriving at the input I3 give the correct behavior.

I agree with you on the fact that the simulation model is incomplete and maybe correcting the simulation model should be enough.

Now, the thing that is troubling me is reading the documentation, I understand that there is no path from the I3 input to the output carry of the logic cell (figure in my previous message), at least, if the configuration uses a mux as depicted. This is why I suggested that a connection was missing in the input carry.
But, as it seems to work on the real hardware, it would suggest that it is not a mux but a bi-directional switch, and I3 and CIN are connected internally.

Thanks for your time.

[whitequark]

I have to say that I haven't had the time to fully investigate this design (and I don't expect I will, but now that you've provided a full example, another team member would be able to do it). But I want to comment on this:

But, as it seems to work on the real hardware, it would suggest that it is not a mux but a bi-directional switch, and I3 and CIN are connected internally.

I know that previously it was thought that the iCE40 architecture uses a mix of buffers and muxes in the routing matrix, but later hardware testing proved it was all buffers. So I'm surprised to hear there is a mux in this one case. It is possible that this is the case, just something I'd try to scrutinize more before accepting it.

[tarikgraba]

But, as it seems to work on the real hardware, it would suggest that it is not a mux but a bi-directional switch, and I3 and CIN are connected internally.

I know that previously it was thought that the iCE40 architecture uses a mix of buffers and muxes in the routing matrix, but later hardware testing proved it was all buffers. So I'm surprised to hear there is a mux in this one case. It is possible that this is the case, just something I'd try to scrutinize more before accepting it.

Ok, if we can be sure that we do not have muxes (the official doc do not really give sufficient information about implementation details), we just need to update the simulation model accordingly.

Thank's for taking this into account, do not hesitate to ask if you (or your colleague) need help.

[whitequark]

There is no certainty of it. I pinged a colleague who has been reverse-engineering iCE40.

[wanda-phi]

The proposed fix is correct. Please make a proper PR and I will just merge it.

However, the proposed reasoning is far from correct. The reason why it works has nothing to do with the I3 connection or its nature; the reason is that COUT → CIN is a hardwired connection, determined entirely by placement. Whenever an LC is directly on top of another LC, the COUT → CIN connection will be made (with a configurable const-value exception at LC0 of every tile for chain initialization). There are no configuration bits for that at all.

When nextpnr legalizes the carry chains (ie. when this function is being called), it collects them into lists, which will be put into a contiguous column of LCs in the hardware, in order. This is done via the relative placement constraints that are assigned in the same pass. These constraints ensure that the COUT → CIN connection is made in hardware even without any connections implicit in the netlist (the I3 port is entirely irrelevant, and this would still be working if it was missing completely).

[tarikgraba]

Thank's for the explanation!

To be sure, before proposing a PR: I understand from your comment that CIN is always connected to the adjacent/lower cell.
The modification I have proposed, would connect the net arriving at I3 to CIN only if COUT is used (connected to an upper cell). Here:

• Are we sure here that the net arriving at I3 always comes from the adjacent/lower cell ?
• Can we connect systematically the net arriving at I3 to CIN even if COUT is not used ?

[wanda-phi]

Thank's for the explanation!

To be sure, before proposing a PR: I understand from your comment that CIN is always connected to the adjacent/lower cell. The modification I have proposed, would connect the net arriving at I3 to CIN only if COUT is used (connected to an upper cell). Here:

* Are we sure here that the net arriving at I3 always comes from the adjacent/lower cell ?

We are — the I3 port is connected to the right net. Furthermore, we can be sure that the dedicated routing pathway will be used, as there is literally no other valid route between the two ports.

* Can we connect systematically the net arriving at I3 to CIN even if COUT is not used ?

We could. This is not required (the routing path for this arc is already forced as mentioned above, and the simulation model will not use the value of CIN when COUT is unused), but it also won't harm anything and could be considered helpful for understanding the netlist.

[tarikgraba]

Opened PR #1611.
Thank's