Site PIPs with side effects

[gatecat]

There's a nasty edge case in the Xilinx CLB where flipflops must be put into latch mode to legalise use of both O[i] and CO[i] when one isn't feeding the flipflop (or the next tile in the case of CO[3]).

Consider the following Verilog which triggers this case:

module top(
        input [3:0] di, s,
        output q
    );
    wire [3:0] o, co;
    CARRY4 carry_i (.DI(di), .S(s), .O(o), .CO(co));
    LUT2 #(.INIT(4'h8)) lut_i (.I0(o[3]), .I1(co[3]), .O(q));
endmodule

The result, as placed and routed by Vivado is:

also note:

get_property CONFIG.LATCH_OR_FF [get_bels SLICE_X0Y5/DFF]
LATCH

This is effectively a special site PIP inside the FF used for route through, but it also carries the following side effects that affect the whole site:

• the LATCH feature must be set, as this is site-wide (i.e. no DFFs can be placed in the site)
• CLK must be connected to ground, by enabling the clock inverter
• CE must be connected to Vcc, using CEUSEDMUX

We need a way in the interchange schema of representing these kind of site pips with complex constraints. PnR should assign a high cost to them so they are only used when absolutely needed (i.e. to legalise carries in this case), as when enabled they render all the FFs in the tile useless (which might also cause some problems with placement validity checking, but that's a nextpnr-specific issue for another day).

[mithro]

I remember having a long discussion about this case with @litghost

[gatecat]

It's definitely a nasty case, and working around it with Yosys techmaps (which aiui is how the current SymbiFlow works)? is definitely a reasonable starting point.

But long term, it would definitely be nice to be able to support site routing like this in the interchange format; not just because of this specific case but also it feels like a pattern that might crop up in other places, and in general enable more creative use of site resources for route-throughs.

[mithro]

@gatecat -- I was wondering if we just put it in the "too hard" basket for today and make it a target for V1.2 or V2? I did think that @litghost had considered this in the constraints work...

[gatecat]

That seems totally fair - but I think if we end up working on something else in this part of the schema then it's worth revisiting. I think it should be possible to implement using a pseudo-cell approach similar to how pseudo-tile-pips currently work.