NullPointerException w/ Wire.getStartWire() + unexpected Wire.getNode() behavior

[GTRI-Dallon]

Hi,

I've encountered a problem where I cannot get the start wire, or node, when I have an object for some other wire within the same node. Here's a short example of some code that produces the error with the xczu3eg-sfva625-1-e part:

Wire w = device.getWire("CLEL_R_X19Y19/EASTBUSOUT_FT1_29");
Node n = w.getNode();
Wire sw = w.getStartWire();

Two problems occur when running this code. First, getNode() returns a node object "CLEL_R_X19Y19/EASTBUSOUT_FT1_29". However, Vivado shows that the node for this wire is actually "INT_X21Y19/WW4_E_BEG2". Second, getStartWire() results in a NullPointerException. Here's the trace:

Exception in thread "main" java.lang.NullPointerException
    at com.xilinx.rapidwright.device.c.a(Unknown Source)
    at com.xilinx.rapidwright.device.c.b(Unknown Source)
    at com.xilinx.rapidwright.device.Wire.getStartWire(Unknown Source)

This same problem occurs with some other wires as well such as CLEL_R_X17Y16/EASTBUSIN_FT0_56. I can probably work around this for my application, but it would be great if this could be fixed/clarified.

[clavin-xlnx]

Thank you, I can confirm this is an issue (both problems) for starting from some intermediate wire segments that form part of a node across multiple tiles. I will start on a fix and will likely be in the next release.

Note that these are lesser used wire references as they don't connect to anything in the tile, so they won't affect most users. Nevertheless, it is incorrect and will be fixed.

[GTRI-Dallon]

Thanks for the quick response and for the future-fix!

[clavin-xlnx]

There is a partial fix for this in the latest release (2019.2.2), but there are still a few pesky wires that still can't quite get connected in context to their node. The performance is also not where I would like it. Probably need a more significant approach with the 2020.1 release to get a more satisfying fix.

[clavin-xlnx]

This should be fixed in 2020.1.6. There is a small runtime hit, especially for larger devices when querying uncommon wires, but a message will print on the first instance and will be cached thereafter.

[clavin-xlnx]

Actually, on second inspection, it looks like Node.getNode() should now produce the expected results, however, Wire.getStartWire() does not. Looks like I missed a nuance in the method definition. This can easily be fixed in the next release, but there is an easy work-around until then:

Node node = wire.getNode();
Wire startWire = node == null ? wire : new Wire(node.getTile(), node.getWire());

[clavin-xlnx]

This should now be fixed in 2020.1.7, please re-open if there are additional issues.