Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wire w/ Null Tile included in tile.getWireConnections(wire) for Wires with FAKE_SM_VALUE Speed Model #80

Open
GTRI-Dallon opened this issue Sep 28, 2020 · 3 comments
Assignees

Comments

@GTRI-Dallon
Copy link

I have encountered this problem with the RapidWright router when routeNode.getConnections() is called for certain wires. So far, I have encountered this error on a kintexu device (xcku025-ffva1156-2-e), but did not encounter the problem when using a Zynq Ultrascale device.

The problem is that the list of wires returned from tile.getWireConnections(wire) for these wires includes a wire with a null tile. This then leads to a null pointer exception in the router. Some example wires where this problem occurs are INT_X1Y179/BOUNCE_E_10_FTN, INT_X12Y179/BOUNCE_E_12_FTN, and INT_X12Y179/INODE_1_E_28_FTN. Each of these wires has a speed model of "FAKE_SM_VALUE" and the list of connections seems complete if the invalid one with a null tile is ignored.

This seems to be a different issue from #63 as these wires are all base wires.

@clavin-xlnx
Copy link
Member

I can confirm the issue is present in RapidWright 2020.1.2, it looks to me an issue with something in the device model. This appears to a be a rare issue, but will need to get resolved. I will dive deeper during the next release to see if a quick fix can be applied. It is interesting to note that this issue appears to occur at the edge tile of the device.

@GTRI-Dallon
Copy link
Author

Thanks for confirming the issue is present! It's easy enough to work around for now as at least all the actual connections still seem to be represented. Thanks for being willing to look more into this.

@clavin-xlnx clavin-xlnx self-assigned this Feb 4, 2022
@clavin-xlnx
Copy link
Member

Looking at this again after a long while. Unfortunately, some of these rare exceptional cases are not as straightforward to fix. Running through all the devices, I get this number of invocations for the listed devices that have a null tile in the result:

// RapidWright 2021.2.1
xcku19p_CIV 264532
xcku19p 264532
xcku085_CIV 4923
xcku085 4923
xcku025 3429
xczu25dr 3620
xcvc1802 301
xcvm1802 23558
xcvu160_CIV 49844
xcvu160 49844

I can target all of these cases with this code:

        CodePerfTracker tt=  new CodePerfTracker("Test Device");
        Device.QUIET_MESSAGE = true;
        for(String deviceName : new String[] {"xcku19p_CIV", "xcku19p", "xcku085_CIV", "xcku025",
                "xcku085", "xczu25dr", "xcvc1802", "xcvm1802", "xcvu160_CIV", "xcvu160"}) {
            tt.start(deviceName);
            Device d = Device.getDevice(deviceName);
            int nullCount = 0;
            for(Tile t : d.getAllTiles()) {
                for(int i = 0; i < t.getWireCount(); i++) {
                    List<Wire> wires = t.getWireConnections(i);
                    for(Wire w : wires) {
                        if(w.getTile() == null) {
                            //System.out.println("Null: " + t + "/" + t.getWireName(i));
                            nullCount++;
                        }
                    }
                }
            }
            if(nullCount > 0) System.out.println(d + " " + nullCount);
            Device.releaseDeviceReferences();
            tt.stop();
        }
        tt.printSummary();

Some of these can be worked around by getting the Node object of the set of wires returned and populating the missing tile, but it doesn't work in all instances. Some more investigation is needed before a complete fix is made.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants