Replacing connection information in metadata.txt with Java code

[jakobwenzel]

Hi there!

when creating module DCPs, we write out a metadata.txt file from Vivado with a Tcl script. I've seen some modules where this script takes upwards of five ours to complete. Therefore I have been looking into removing the whole connectivity information from the Tcl script and instead gathering the information in RapidWright. There are some edge cases where I am not sure how to proceed.

The core loop in Tcl that writes out connectivity information is here:

RapidWright/tcl/rapidwright.tcl

Lines 268 to 274 in 57438b9

	set cpins [get_pins -quiet -leaf -of [get_nets -segments $netname]]
	foreach cpin $cpins {
	set ccell [get_cells -of [get_pins $cpin]]
	set loc [get_property -quiet LOC $ccell]
	set sitePin [get_site_pins -quiet -of $cpin]
	puts $md " pin $cpin $loc $sitePin"
	}

The variable sitePin is named in the singular, but there can actually be multiple pins. If that is the case, they are just written out space separated. The Java code that parses the file is here:

RapidWright/src/com/xilinx/rapidwright/design/MetadataParser.java

Lines 348 to 357 in 57438b9

	String siteName = tokens.length > 3 ? tokens[3] : null;
	String sitePinName = tokens.length > 4 ? tokens[4] : null;
	String pinName = sitePinName.substring(sitePinName.indexOf('/')+1);
	if (tokens.length > 5 && currPort.isOutPort()) {
	SiteInst i = m.getSiteInstAtSite(dev.getSite(siteName));
	if (i.getSitePinInst(pinName) == null) {
	sitePinName = tokens.length > 5 ? tokens[5] : sitePinName;
	pinName = sitePinName.substring(sitePinName.indexOf('/')+1);
	}
	}

If there is more than one Site Pin, tokens.length will be > 5.

My questions:

1. For output pins, Lines 354-355 sometimes choose the second pin in the list. This seems like a workaround for some bug. I've never seen the if condition trigger. If there are multiple output site pins, what are the rules to choose one to connect to the net?

2. For input pins, we always just choose the first one (as returned by Vivado). I have seen this case multiple times in practice, always with BRAMs. Some examples are (the contents of $sitePin, one per line, all on xc7a200t):

   RAMB36_X2Y28/CLKBWRCLKL RAMB36_X2Y28/CLKBWRCLKU RAMB36_X2Y28/REGCLKBL RAMB36_X2Y28/REGCLKBU
   RAMB18_X3Y48/WEBWE0 RAMB18_X3Y48/WEBWE1
   RAMB18_X2Y58/WEA0 RAMB18_X2Y58/WEA1 RAMB18_X2Y58/WEA2 RAMB18_X2Y58/WEA3
   

   The question here is basically the same: Do we choose one of the input pins? If so, which one? Or do we connect to all of them?

   If needed, I can provide example DCPs for this case.

3. For potentially upstreaming this work: My approach needs access to the EDIF netlist (EDIFNetlist.getPhysicalPins in particular). My understanding is that RapidWright supports partially encrypted designs (which I have never used) and that EDIF netlists are not available for at least some cells there. Does the current approach work with such designs? Does EDIFNetlist.getPhysicalPins work for such designs? If no, we would probably have to keep the Tcl approach for these designs.

Thanks,
Jakob

[clavin-xlnx]

Hi Jakob,

Thanks for looking at this, I will try my best to answer your questions:

1. Some nets can have multiple outputs (two are possible in Series7, UltraScale, UltraScale+, up to three in Versal). I believe we are just trying to associate a SitePinInst with a Port object. Given that some nets can have multiple outputs, I think it is arbitrary as to which pin gets selected. That code hasn't changed in 7+ years, so I don't think it should matter.
2. I think the answer to this is essentially the same. We want to associate a Port with a specific SitePinInst on the module as a reference. The Port object uses a Set (

   RapidWright/src/com/xilinx/rapidwright/design/Port.java

   Line 50 in 57438b9

   private Set<SitePinInst> sitePinInsts = new HashSet<>();

   ) to keep track of which SitePinInst objects it connects to, so perhaps populating all of them might be the proper path.
3. A partially encrypted design will have a black box around the encrypted IP or cell and so such exploration would probably require the Tcl script. So, in general, EDIFNetlist.getPhysicalPins() would not work. We do have a work around (Adds external library for netlists to compensate for black boxed cells #1294) that allows us to generate a substitute netlist that would enable connectivity exploration (useful for placing and routing partially encrypted designs), but this is not turned on by default.