Pseduo PIPs should have information on which site and bel pins they traverse

[acomodi]

Pseudo PIPs are necessary to allow site-thru connections, where an explicit cell is missing, but one is required to let a signal be routed to the destination (e.g. IOI_LOGIC, BUFHCE, etc.).

There are situations though, where a pseudoPIP does not fully describe how a particular net should be routed in the site, and which site is used as route-thru.

As a concrete example, take the following situation:

The image represents a site route-thru with a pseudoPIP, that connects the input site pin to the output site pin (in this case CLBLL_LL_C1 --> CLBLL_LL_C). The pseudoPIP though does inherently activates a LUT-thru from the A1 -> O6 pin of the output bottom SLICE's CLUT.

Without the extra information, writing the FASM feature for the LUT-thru becomes quite hacky and would require to extract the information from the wire names.

[gatecat]

Extending the current pseudo-cell approach to include an explicit bel pin mapping, too, might make the most sense?

Worth considering that for most cells other than LUTs, the pseudo-cell associated with the pseudo-pip will only have one possible bel pin mapping, simplifying the handling quite a bit.

[acomodi]

One question would be how to treat a pseudoPIP that goes through multiple BELs, such as one that goes through a LUT and an OUTMUX. Assuming that this case is allowed, I guess we would actually need a list of explicit bel pin mapping, with the addition also of the site used.

Given that there are two SLICEs in a CLB, only the information about the BELs might not be enough.

In addition, it might not be relevant but, as I understand it, a pseudoPIP can have one and only one route through a site, but I am not too sure about this. A counter example can be the following:

PseudoPIP: CLBLL_LL_C1 --> CLBLL_LL_CMUX (still assuming that the pseudo PIP can traverse multiple BELs within a site)

This one can have the two following routes through the site:

1. C1 -> LUT.A1 -> LUT.O6 -> COUTMUX.O6 -> CMUX
2. C1 -> LUT.A1 -> LUT.O5 -> COUTMUX.O5 -> CMUX

The question would be, how to actually determine starting from a physical netlist (when writing FASM or for instance when the DCP is written with RapidWright) which route the CLBLL_LL_C1 --> CLBLL_LL_CMUX pseudo PIP is occupying?

[gatecat]

In the case given, which output wire is used would be fixed by whether the bel field of the pseudoCell for the route through is a 5LUT or 6LUT bel: https://github.com/SymbiFlow/fpga-interchange-schema/blob/b3ab09776c8dc31a71ca2c7fbcb4575219232d16/interchange/DeviceResources.capnp#L257

GitHub

SymbiFlow/fpga-interchange-schema

Contribute to SymbiFlow/fpga-interchange-schema development by creating an account on GitHub.

[acomodi]

Right, so, I think I was looking at this a bit in the wrong way. I missed that a PIP, in case it is a pseudo one, it will have a list of pseudoCells, identifying all the resources traversed with the pseudoPIP, and this is just fixed and decided when building the device resources (I guess that in case of xc7, RapidWright is deciding which of the two output wires will be used for this pseudoPIP).

[gatecat]

It's currently unclear whether psuedoCells could be used to bind routing bels, too, but that seems like it would be reasonable to use if needed.

[acomodi]

After investigating a bit how to solve this issue, I think that, at the moment, it should be pretty straightforward to get the bel pin used by the pseudo PIPs only by querying the device database.

The only outstanding problem, which I am not sure how to solve, but I may be missing something, is how to identify the specific site instance that a pseudo (tile) PIP expressed in the physical netlist traverses. Keeping the xc7 CLB as an example, we need the site instance to get the FASM site prefix.