Issues with intra-site routing on Versal board

[chrmarlyn]

Hi again!

I am trying to do some basic inter-site routing on a Versal board, more specifically the Versal Premium series (VP1502), but none of the two approaches that I have tried are working. Below is my code and a description of what I have done (note that some of the approaches have been commented out). I am using the 2025.1 version of Vivado and the corresponding version of RapidWright (2025.1.0) in Python.

Code:

import os, rapidwright

from com.xilinx.rapidwright.design import Design, Unisim, tools
from com.xilinx.rapidwright.eco import ECOTools
from com.xilinx.rapidwright.router import Router
from com.xilinx.rapidwright.rwroute import PartialRouter

# Create a test design
ultra = "xcvu19p-fsva3824-2-e"
versal = "xcvp1502"

device = versal
test = Design("test_design", device)

# Place two luts at 2 arbitrarily chosen sites
lut_1 = test.createAndPlaceCell("lut_1", Unisim.LUT6, "SLICE_X148Y0/A6LUT")
tools.LUTTools.configureLUT(lut_1, "O!=I1")

lut_2 = test.createAndPlaceCell("lut_2", Unisim.LUT6, "SLICE_X148Y1/B6LUT")
tools.LUTTools.configureLUT(lut_2, "O=I1")


# Create a net
net = test.createNet("test_net")

# Using ECOTools
ECOTools.connectNet(test, lut_1, "O", net)        # Source
ECOTools.connectNet(test, lut_2, "I1", net)       # Sinks

# # Using net.connect()
# net.connect(lut_1, "O")                             # Source
# net.connect(lut_2, "I1")                            # Sinks

print("Created net", net.getName(), "\tSource:", net.getSource(), "\tSinks:", net.getSinkPins())

# Intra-site routing
test.routeSites()

# Inter-site routing
Router(test).routeDesign()

# # Check if there are any unrouted pins left
# print(PartialRouter.getUnroutedPins(test))

test.writeCheckpoint("test.dcp")

Approach:

1. Tried using ECOTools.connectNet() but this fails before the program gets to the routing part. The error that is thrown is the following: java.lang.java.lang.RuntimeException: java.lang.RuntimeException: ERROR: Unable to route pin 'lut_2/I0' out of site SLICE_X148Y1.

2. Used connect() from the Net class -> this doesn't throw any errors, but when I open the design in Vivado's Device view, the net appears in red (i.e. it's "Routable, but not routed"), while the schematic looks fine. A check with report_route_status in the Tcl console also confirms the unrouted net. However, PartialRouter.getUnroutedPins() returns an empty list, indicating that there are no pins belonging to fully unrouted nets, which seems to contradict what Vivado is showing.

Furthermore, in my second approach, the print statement before the intra-site routing prints the following:

Created net test_net Source: OUT SLICE_X148Y1.B_O Sinks: [],

which indicates that the sink pin I1 on lut_2 isn't properly connected (but it's still present in the Vivado schematic, as previously mentioned). After some light debugging, I have found that there seems to be an issue with how the logical input pins are named on the Versal boards, since both methods work perfectly fine for an UltraScale+ device ("xcvu19p-fsva3824-2-e"), but I find this rather odd since both Vivado and getPinMappingsL2P() from the Cell class show that the logical pins should be named I0-I5.

Is my speculation correct? Has anyone had this problem before?

I appreciate any help that I can get!

/ Chrysella

[eddieh-xlnx]

Hi @chrmarlyn. Thanks for bringing this up! The ECOTools framework has not been robustly validated on Versal devices, but it is very much on our roadmap to make the same API function identically on both UltraScale+ and Versal. We're a bit swamped, but leave this with us. Thanks!

[chrmarlyn]

Hi @eddieh-xlnx ,

Thanks for the reply! I'll leave it to you then. Your help is much appreciated! :))

I have one follow up question though, if that's okay. Is my second approach with connect() from the Net class viable (in theory)? If not, why? I am having a hard time understanding why the inter-site routing fails, since I am creating my design from scratch instead of loading it from a DCP (and therefore not modifying any existing nets).

Thanks again!

[eddieh-xlnx]

By second approach, do you mean this commented out code?

# # Using net.connect()
# net.connect(lut_1, "O")                             # Source
# net.connect(lut_2, "I1")                            # Sinks

I would say that Net.connect() is probably less robust than ECOTools.connectNet(), and we'd be moving towards deprecating the former and preferring/improving the latter.

Inside both of these operations, there are a number of things that need to be updated:

1. Logical Netlist
2. Physical Netlist
   a. Intra-site routing
   b. Inter-site routing

It looks like 1. is working somewhat, because as you say it appears correct in the Vivado schematic.

However, my impressions are that 2a. is currently behaving as we expect -- we're aware of some issues due to how the Versal SLICE is different from the UltraScale+ one -- so it's likely down to that. Without 2a., it's possible that neither Vivado nor RapidWright will pick up the need for 2b. since the design isn't fully formed.

Hope this sheds some light on the issue while we work on a fix!

Can you share a little more about what you're trying to achieve, and we can see if we can support you in other ways? You may also contact me privately.

[eddieh-xlnx]

Hi @chrmarlyn. I've found out what the issue is, and fixed it in the closed-source portion of RapidWright. The earliest we'll be able to get a new release out is next week though, sorry!

I took the above code and adapted it into a test here: #1247 -- which I've tested to work with the fixed code -- but will not pass until a new release is made.

Note that it doesn't need:

# Intra-site routing
test.routeSites()

Another thing I noticed is your use of the old Router:

# Inter-site routing
Router(test).routeDesign()

Router is actually an early, basic router that doesn't support Versal. You should move over to using RWRoute which is much more robust, actively developed, and does support Versal.

I appreciate that this reply doesn't unblock you immediately, but I can share there is light ahead!

[chrmarlyn]

Hi @clavin-xlnx ,

Thanks for testing my code and for the clarification! I am glad to hear that the updated Versal routing works, and I understand that it will take some time to release the fix. Also, thanks for the tip regarding the EDIF files!

In the meantime, please let me know if I can assist with anything regarding the UltraScale+ problems.

Your help is much appreciated!

All the best,

Chrysella

[clavin-xlnx]

@chrmarlyn - I have a release candidate of 2025.1.1 that contains the fix from @eddieh-xlnx and also fixes the Versal site routing issue above. I haven't been able to fix the first issue in UltraScale+ yet, but I know what is wrong and just need some more time.

You can try out the fix by checking out the 2025.1.1 branch:

cd <path_to_clone_of_this_repo>
git checkout 2025.1.1
./gradlew compileJava
./gradlew updateJars
RAPIDWRIGHT_PATH=<path_to_clone_of_this_repo> CLASSPATH=<path_to_clone_of_this_repo>/bin:=<path_to_clone_of_this_repo>/jars/* python3 <script.py>

In the meantime, please let me know if I can assist with anything regarding the UltraScale+ problems.

If you can provide a DCP that exhibits (UltraScale+ issue 2) the RuntimeException during routeSites(), that would be super helpful in diagnosing the problem. I'm not sure if I will be able to reproduce the exact issue otherwise.

[chrmarlyn]

Hi @clavin-xlnx ,

Great, thank you for the update! I am having some technical issues at the moment but I will give the branch a try as soon as possible :)

Also, I have lost the DCP, so I will need to recreate it before I can send it over. This might take a while, but I will get back to you as soon as it is finished/I have found the original DCP.

Thanks again and have a great day!

All the best,
Chrysella

[clavin-xlnx]

Just a quick update, I believe I have resolved the issue related to the UltraScale+ issue 1 (should be resolved in #1253). I have merged the fix into the 2025.1.1 as well as in master if you want to try it.

[chrmarlyn]

Great, thanks for letting me know, Chris!

[chrmarlyn]

Hello again @eddieh-xlnx and @clavin-xlnx ,

I have given the 2025.1.1 branch a try and I am able to use ECOTools.connectNet() without getting the "Unable to route pin out of site" error. routeSite() also does the routing correctly, which is wonderful, but I ran into yet another issue with ECOTools which I think could be a bug.

I tried to recreate the net that I removed in my original code snippet by doing the following:

1. Creating a new net in the same level of the design
2. Using ECOTools.connectNet() to connect the output of the first LUT (i.e. the pin on the AND LUT that I previously removed)
3. Using ECOTools.connectNet() to connect the input of the second LUT (same as above but for the XOR LUT)

but as seen in the last row of the print statements below, RapidWright cannot correctly connect the sink pin (I0).

What are your opinions on this?

I will reattach the code and the DCP for your convenience.

Code

import rapidwright

from com.xilinx.rapidwright.design import Design
from com.xilinx.rapidwright.eco import ECOTools


design = Design.readCheckpoint(r"C:\vp1202.dcp", r"C:\vp1202.edn")

lut_and = design.getCell("uut/and_lut")
lut_xor = design.getCell("uut/xor_lut")

target_net = design.getNet("uut/intermediate")

print("Target net:", target_net)

# Check port instances (all)
print("EDIFHierPortInstances:", target_net.getLogicalHierNet().getLeafHierPortInsts())

# Remove net pins
print("Target net pins before removal:", target_net.getPins())

ECOTools.disconnectNet(design, target_net.getLogicalHierNet().getLeafHierPortInsts(False))

print("Target net pins after SINK removal:", target_net.getPins())

ECOTools.disconnectNet(design, target_net.getLogicalHierNet().getLeafHierPortInsts())

print("Target net pins after SINK + SOURCE removal:", target_net.getPins())

# Remove the net
design.removeNet(target_net)

print("Target net after net removal:", design.getNet(target_net.getName()))


" RE-ADD the net "

new_net = design.createNet("uut/new_intermediate")

print("\nStep A:", design.getNet(new_net.getName()))

ECOTools.connectNet(design, lut_and, "O", new_net)

print("Step B, source connection:", new_net.getPins())

ECOTools.connectNet(design, lut_xor, "I0", new_net)

print("Step C, sink connection:", new_net.getPins())

vp1202 files #1245.zip

Terminal output

==============================================================================
==                         Reading DCP: vp1202.dcp                          ==
==============================================================================
 XML Parse & Device Load:     3,461s
    (Read PhysDB Caches):            (    0,365s)
 (Read PhysDB Placement):            (    0,076s)
   (Read PhysDB Routing):            (    0,210s)
(Read PhysDB Finalizing):            (    0,001s)
            (EDIF Parse):            (    0,626s)
   Read Netlist & PhysDB:     0,629s
------------------------------------------------------------------------------
         [No GC] *Total*:     4,090s
Target net: uut/intermediate
EDIFHierPortInstances: [uut/and_lut/O, uut/xor_lut/I0]
Target net pins before removal: [OUT SLICE_X342Y0.AQ, IN SLICE_X342Y0.B1]
Target net pins after SINK removal: [OUT SLICE_X342Y0.AQ]
Target net pins after SINK + SOURCE removal: []

Target net after net removal: None
Step A: uut/new_intermediate
Step B, source connection: [OUT SLICE_X342Y0.AQ]
Step C, sink connection: [OUT SLICE_X342Y0.AQ]

Also, @clavin-xlnx : I tried your tip regarding loading the DCPs, but RapidWright couldn't read the netlist in the .edf file because it "is encrypted and cannot be used", although my design doesn't contain any IP. It doesn't help to pass the EDIF path as an argument either. The only format that is working for me is .edn. Any ideas on why the exception is thrown?

Traceback (most recent call last):
  File "com.xilinx.rapidwright.design.Design.java", line 0, in com.xilinx.rapidwright.design.Design.readCheckpoint
Exception: Java Exception

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "c:\vp1202_route_test.py", line 7, in <module>
    design = Design.readCheckpoint(r"C:\vp1202.dcp")
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
java.lang.java.lang.RuntimeException: java.lang.RuntimeException:
*******************************************************************************
** ERROR: Unable to find a readable EDIF file for the DCP:
          C:\vp1202.dcp

           The accompanying EDIF file at
   C:\vp1202.edf
 is encrypted and cannot be used.

          When Vivado generates DCPs, by default it includes an EDIF file that
          is generally not readable by RapidWright.  However, a readable EDIF
          can be generated using 'write_edif'.  Two options exist to resolve
          this issue:

          1) Always run 'write_edif' after 'write_checkpoint' in Vivado.  This
             is the most efficient and least error prone way.  A convenience
             Tcl command is available in $RAPIDWRIGHT_PATH/tcl/rapidwright.tcl
             called 'write_rw_checkpoint <file>'.  Just source rapidwright.tcl
             and replace your 'write_checkpoint' call with this command.

          2) If option #1 is skipped, RapidWright can automatically invoke
             Vivado and attempt to do it automatically.  This assumes a
             compatible Vivado is on your PATH.  This mode is enabled by
             default.  Auto-generation can be disabled two ways:
               (1) set environment variable RW_AUTO_GENERATE_READABLE_EDIF=0, or
               (2) call 'Design.setAutoGenerateReadableEdif (false)' in
                   your RapidWright program.

          We apologize for the inconvenience of this added step.
*******************************************************************************

I appreciate the help as always!

/ Chrysella

[clavin-xlnx]

I failed to mention that I tested the fix in combination with my ongoing Versal site routing fixes. Once I am able to get all the regression tests passing on the other set of fixes, I'll be able to share them with you. Thank you for giving us all these test cases, we simply don't have the same maturity level for Versal routing as we do for UltraScale+.

[clavin-xlnx]

Hi @chrmarlyn - I think I have all the routing issues you've described fixed in our 2025.1.1 branch. If you can pull those changes and run ./gradlew compileJava again, this should resolve the problems you have been seeing. Thanks for your patience and let us know if you run into more issues.

[chrmarlyn]

Hey @clavin-xlnx !

Thank you so much for the update. The latest version of the 2025.1.1 branch did the trick with the latest issues that I reported, but I think I have found another routing bug. When adding a flip-flop to my design and connecting it in series with the other LUTs, the inter-site routing with RWRoute.routeDesignFullNonTimingDriven(test_route) fails and throws a NullPointerException.

I am not entirely sure how to interpret the error message, so I was hoping that you would be able to help me with that. I will share the new code down below.

Thanks for everything so far!

Code

import rapidwright

from com.xilinx.rapidwright.design import Design, Unisim, tools
from com.xilinx.rapidwright.rwroute import RWRoute
from com.xilinx.rapidwright.eco import ECOTools

test_place = Design("test_design", "vp1202")

cell_1 = test_place.createAndPlaceCell("my_test_cell_1", Unisim.LUT6, "SLICE_X100Y0/A6LUT")
tools.LUTTools.configureLUT(cell_1, "O=I1")
cell_1.fixCell(True)

cell_2 = test_place.createAndPlaceCell("my_test_cell_2", Unisim.LUT6, "SLICE_X100Y0/H6LUT")
tools.LUTTools.configureLUT(cell_2, "O=I1")
cell_2.fixCell(True)

ff = test_place.createAndPlaceCell("flipflop", Unisim.FDCE, "SLICE_X100Y0/AFF")                 
ff.fixCell(True)

net = test_place.createNet("my_test_net_0")
ECOTools.connectNet(test_place, cell_1, "O", net)
ECOTools.connectNet(test_place, cell_2, "I1", net)

outer_net_1 = test_place.createNet("my_test_net_1")
ECOTools.connectNet(test_place, cell_2, "O", outer_net_1)
ECOTools.connectNet(test_place, ff, "D", outer_net_1)

outer_net_2 = test_place.createNet("my_test_net_2")
ECOTools.connectNet(test_place, ff, "Q", outer_net_2)
ECOTools.connectNet(test_place, cell_1, "I1", outer_net_2)  

" Write the first DCP"
print("Writing placed DCP...")
test_place.writeCheckpoint("my_placed.dcp")

" Load written DCP"
print("Loading placed DCP...")
test_route = Design.readCheckpoint("my_placed.dcp")

# # Intra-site routing
print("Starting intra-site routing...")
test_route.routeSites()
print("Intra-site routing is done!")

# Inter-site routing
rawr = RWRoute.routeDesignFullNonTimingDriven(test_route)

" Write the second DCP"
print("Writing routed DCP...")
test_route.writeCheckpoint("my_routed.dcp")

Stack Trace

Traceback (most recent call last):
  File "RWRoute.java", line 2383, in com.xilinx.rapidwright.rwroute.RWRoute.routeDesignFullNonTimingDriven
Exception: Java Exception

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "c:\write_dcp.py", line 46, in <module>
    rawr = RWRoute.routeDesignFullNonTimingDriven(test_route)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
java.lang.java.lang.NullPointerException: java.lang.NullPointerException: Cannot invoke "com.xilinx.rapidwright.rwroute.RouteNodeType.ordinal()" because "type" is null

[clavin-xlnx]

Thanks @chrmarlyn for the test case, @eddieh-xlnx and I have both identified fixes related to the issue and have pushed them to the 2025.1.1 branch. Please try again and let us know how it goes.

[chrmarlyn]

Awesome, it worked! Thanks for support @clavin-xlnx and @eddieh-xlnx :)

[chrmarlyn]

Hi again @clavin-xlnx and @eddieh-xlnx ,

So sorry to already be reaching out again, but I think I have encountered a new issue with intra-site routing for Versal. This time, I was trying to recreate the following gated clock circuit (link) in RW, but ECOTools failed to connect (or route) the clock pins of the FDREs to the regular net that connects them with the LUT. This is the exception that it throws:

Traceback (most recent call last):
  File "ECOTools.java", line 735, in com.xilinx.rapidwright.eco.ECOTools.connectNet
Exception: Java Exception

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "c:\clk_gating.py", line 22, in <module>
    ECOTools.connectNet(design, ff1, "C", net)
java.lang.java.lang.RuntimeException: java.lang.RuntimeException: ERROR: Failed to route intra-site connection SLICE_X86Y67/CLK.CLK to CFF2.CLK.

The problem disappeared when I connected the net to the data pins ("D") of the FDREs instead of the clock pins, so there seems to be an issue with connecting regular, non-clock nets to the clock pins. Is this something that you have seen before?

I am on the latest version of the 2025.1.1 branch and am still using the VP1202 in my design. As usual, here is my code:

import rapidwright

from com.xilinx.rapidwright.design import Design, Unisim, tools
from com.xilinx.rapidwright.rwroute import RWRoute
from com.xilinx.rapidwright.eco import ECOTools

design = Design("clock_gating_test", "vp1202")

lut = design.createAndPlaceCell("lut", Unisim.LUT6, "SLICE_X86Y67/C6LUT")
tools.LUTTools.configureLUT(lut, "O=I1")
lut.fixCell(True)

ff1 = design.createAndPlaceCell("ff1", Unisim.FDRE, "SLICE_X86Y67/CFF2")
ff1.fixCell(True)

ff2 = design.createAndPlaceCell("ff2", Unisim.FDRE, "SLICE_X86Y67/DFF2")
ff2.fixCell(True)

net = design.createNet("net")

ECOTools.connectNet(design, lut, "O", net)
ECOTools.connectNet(design, ff1, "C", net)                                              # Problematic
ECOTools.connectNet(design, ff2, "C", net)                                              # Problematic

design.writeCheckpoint("test.dcp")

Appreciate the help always and thanks for everything so far!

// Chrysella

[clavin-xlnx]

Hi @chrmarlyn - I believe I have fixed the issue you've encountered (as well as a couple others) in a different branch: site_route_sr_clkmod. Try checking out this branch and see if you can confirm. The changes aren't quite ready to be merged into 2025.1.1 yet, but they should work and will allow you to hopefully make more progress.

If you can share more about what your goals are, we might be able to help you make faster progress rather than the back-and-forth bugs/fixes (which are very useful!). Let us know if you would like to engage a bit more and we might be able to accelerate your progress.

[chrmarlyn]

Hi again @clavin-xlnx ,

Thanks for the reply! I'm guessing that you merged the site_route_sr_clkmod branch into the 2025.1.1 branch, so I gave it a try and I'm not getting any errors anymore. Thank you!

As for your other inquiry, I'll shoot you a private message to tell you a bit more about my goals :)

Thanks again for the help!