071-ppips: In Kintex7, two wires are permanently connected to RIOI_O[01]

[hansfbaier]

Some nodes, for example RIOI_O0 and RIOI_O1 have multiple uphill pips,
which both seem connected to the same output.
In that case the documentation would suggest to generate a hint in the ppips database file:
https://f4pga.readthedocs.io/projects/prjxray/en/latest/dev_database/common/ppips.html
"The tag hint is used for PIPs that are used by Vivado to tell the router that two logic slice outputs drive the same value, i.e., behave like they are connected as far as the routing process is concerned."

Currently, as suggested by @tmichalak here: https://chipsalliance.slack.com/archives/C033M7FLURZ/p1669982485158029, I generate always for those.

[mithro]

@kgugala - Who should review this?

[mithro]

@kgugala - It seems like we have lost the upload to BuildEventStore in the migration to GitHub Actions?

[hansfbaier]

The red Artix fuzzer seems to be a flicker? Seems totally unrelated...

[tmichalak]

I reran the Artix job. Will inspect the db diffs after it finishes to verify if that helped with the missing bits. @hansfbaier I guess there is still the problem with the switchbox pips instead of ppips, correct?

[hansfbaier]

@tmichalak Yes, this only generates the ppips that got missing on Kintex (and are needed by nextpnr).
It does neither generate all ppips nor get rid of any switchbox pips.

[hansfbaier]

@tmichalak RapidWright has something promising: http://www.rapidwright.io/javadoc/com/xilinx/rapidwright/device/PseudoPIPHelper.html
We could use this to dump the ppips for each tile type.

[hansfbaier]

@tmichalak I wrote a little python script that uses RapidWright to get the pseudo pips of a tile:

#!/usr/bin/env python3
import sys

import rapidwright
from com.xilinx.rapidwright.device import PseudoPIPHelper, Device
import com.xilinx.rapidwright.device.TileTypeEnum as TileType

part = "xc7k70tfbg676-2"
tiletype = sys.argv[1]
device = Device.getDevice(part)
ppipmap = PseudoPIPHelper.getPseudoPIPMap(device)
tiletype = TileType.valueOf(tiletype)
rioi = ppipmap[tiletype]
ppipnames = [str(ph.getPseudoPIPName()) for ph in list(rioi.values())]
print("\n".join(ppipnames))

running it I get:

$ ./get-ppips.py RIOI                
RIOI.RIOI_OLOGIC0_OQ->RIOI_OLOGIC0_OFB
RIOI.RIOI_ILOGIC0_DDLY->IOI_ILOGIC0_O
RIOI.RIOI_OLOGIC0_TQ->RIOI_OLOGIC0_TFB
RIOI.RIOI_ILOGIC0_D->IOI_ILOGIC0_O
RIOI.IOI_OLOGIC1_D1->RIOI_OLOGIC1_OFB
RIOI.IOI_OLOGIC1_D1->RIOI_OLOGIC1_OQ
RIOI.RIOI_IDELAY1_IDATAIN->RIOI_IDELAY1_DATAOUT
RIOI.IOI_OLOGIC0_T1->RIOI_OLOGIC0_TQ
RIOI.IOI_OLOGIC0_T1->RIOI_OLOGIC0_TFB
RIOI.RIOI_IDELAY0_IDATAIN->RIOI_IDELAY0_DATAOUT
RIOI.IOI_OLOGIC1_T1->RIOI_OLOGIC1_TFB
RIOI.IOI_OLOGIC1_T1->RIOI_OLOGIC1_TQ
RIOI.IOI_OLOGIC0_D1->RIOI_OLOGIC0_OQ
RIOI.IOI_OLOGIC0_D1->RIOI_OLOGIC0_OFB
RIOI.RIOI_ILOGIC1_DDLY->IOI_ILOGIC1_O
RIOI.RIOI_ILOGIC1_D->IOI_ILOGIC1_O
RIOI.RIOI_OLOGIC1_TQ->RIOI_OLOGIC1_TFB
RIOI.RIOI_OLOGIC1_OQ->RIOI_OLOGIC1_OFB

[hansfbaier]

If we had RapidWright available with the python interface, getting the PPIPs would be as easy as that

[hansfbaier]

Actually as those never change, dumping them once and commiting them should be fine

[tmichalak]

If we had RapidWright available with the python interface, getting the PPIPs would be as easy as that

@hansfbaier I don't mind installing RW python package and calling your script. Actually this option is cleaner than checking in a file that at some point in the future no one will know where it came from.

[hansfbaier]

@tmichalak comparing the RW results with current results, it also looks like RW is missing some ppips, most notably the marked ones here, which nextpnr-xilinx currently uses:

I started writing a replacement for 071-ppips based on RW, but I am hesitating, because the results
are dramatically smaller and that might break the existing PnR tools.

[hansfbaier]

OK here we go, let's compare the results: #2068

[hansfbaier]

@tmichalak According to @mithro here #2068
this interim fix is the way to go, until the data is available via the interchange format.