[DesignTools] createMissingSitePinInsts throw error

[coherent17]

Hi RapidWright teams,

When I'm calling API createMissingSitePinInsts with Versal device, it throws exception as below:

Exception in thread "main" java.lang.RuntimeException: ERROR: Net on SLICE_S0X93Y387/AFF.D'XXX/gnd_1' is not an alias of 'GLOBAL_LOGIC0'
at com.xilinx.rapidwright.design.DesignTools.createMissingSitePinInsts(DesignTools.java:2298)
at com.xilinx.rapidwright.design.DesignTools.createMissingSitePinInsts(DesignTools.java:2477)

Can you help to check how can this been resolved?

Thanks,
Coherent

[clavin-xlnx]

Hi Coherent,

I am not able to pinpoint exactly where this error is occurring, could you provide the exact commit or version of RapidWright you are using? Does it have any changes in it? Ideally, if you are able to share a small test case that reproduces the issue, that would be ideal.

At the surface, it seems like the error message is declaring that the net 'SLICE_S0X93Y387/AFF.D'XXX/gnd_1' is not driven by a GND primitive cell, but I couldn't find anywhere in the code base where that error is being generated in RapidWright.

[coherent17]

The version I used is 2025.1.1-beta without any change in it, and here is the code snippet:

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

Lines 2296 to 2298 in 4656a21

	throw new RuntimeException("ERROR: Net on " + si.getSiteName() + "/" + belPin +
	"'" + siteWireNet.getName() + "' is not an alias of " +
	"'" + net.getName() + "'");

Is there's a quick fix locally I can do to bypass this error without sync to the new version/release?

I saw in the latest version in repo, there's a isVersal check:

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

Lines 2293 to 2298 in a7f80f9

	if (isVersal && net.isStaticNet() && bel.isLUT()) {
	siteWireNet = net;
	synchronized (si) {
	si.routeIntraSiteNet(net, belPin, belPin);
	}
	} else {

[eddieh-xlnx]

Recently, #1324 changed DesignTools.createMissingSitePinInsts() to require DesignTools.makePhysNetNamesConsistent() to be called before it. Can you check if this is done here?

EDIT: Oh wait. That PR appeared in 2025.2.0. It'll probably still break in 2025.2.0, but it's worth checking. Otherwise, you might need to show us more of the design at SLICE_S0X93Y87.

[coherent17]

Here is what I use API that we discussed before in previous issue or discussion.

DesignTools.makePhysNetNamesConsistent(design);
DesignTools.createMissingSitePinInsts(design);
DesignTools.updatePinsIsRouted(design);

[eddieh-xlnx]

I saw in the latest version in repo, there's a isVersal check

These changes were part of #1324 and were mainly a rework to operate using multi threads. There should not be any new functionality/fixes.

[clavin-xlnx]

Have there been any modifications to the netlist prior to calling these APIs? This method depends on a generated map (parentNetMap in EDIFNetlist) that gets generated once and must be reset if any changes are made to the netlist, otherwise the net gets out of sync. To reset it call EDIFNetlist.resetParentNetMap(), prior, but only if netlist modifications have taken place.

If not, is it possible for you to provide any more information about the net in question? Is it truly supposed to be GND? Is it properly connected to a GND cell? We do have a DesignObfuscator that can obfuscate names of a design if that makes it easier to share a test case.

[coherent17]

These 3 methods are somehow causing huge runtime + memory (> 128G) for grid machine and still somehow causing some OOM error in both Ultrascale+ & Versal design, and therefore the function that utilize these 3 API are off by default. Glad to see the rework for multi-threaded, I can try them in the future.

[coherent17]

Have there been any modifications to the netlist prior to calling these APIs? This method depends on a generated map (parentNetMap in EDIFNetlist) that gets generated once and must be reset if any changes are made to the netlist, otherwise the net gets out of sync. To reset it call EDIFNetlist.resetParentNetMap(), prior, but only if netlist modifications have taken place.

No, the netlist is not being modified.

If not, is it possible for you to provide any more information about the net in question? Is it truly supposed to be GND? Is it properly connected to a GND cell? We do have a DesignObfuscator that can obfuscate names of a design if that makes it easier to share a test case.

Let me check, and if possible, I might share the design or the obfuscated result through mail.
Thanks

[clavin-xlnx]

@coherent17 - I was able to reproduce the error you are seeing with a design we have internally in 2025.1.1. When I run the same design in 2025.2.0, the issue is not present. Are you able to update to 2025.2.0? You should be able to update RapidWright and stay on an older version of Vivado if you wish. RapidWright is backwards compatible with older versions of Vivado.

These 3 methods are somehow causing huge runtime + memory (> 128G) for grid machine and still somehow causing some OOM error in both Ultrascale+ & Versal design, and therefore the function that utilize these 3 API are off by default. Glad to see the rework for multi-threaded, I can try them in the future.

We are looking into ways to reduce memory usage for these methods, nothing material yet, but we'll let you know if we come up with any improvements.

[clavin-xlnx]

If you are unable to upgrade to 2025.2.0, it would be useful if you could try with 2025.2.0 to see if it resolves the issue.

[coherent17]

If you are unable to upgrade to 2025.2.0, it would be useful if you could try with 2025.2.0 to see if it resolves the issue.

Hi, I upgrade to 2025.2. And it works well on device xcvu440/xcvu19p/xcvp1902 RapidWright regression testcases. And the runtime actually improved a lot.

Thanks for the suggestion.