Replies: 4 comments 25 replies
-
|
Hi @chrmarlyn. Thanks for bringing this up! The |
Beta Was this translation helpful? Give feedback.
-
|
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: Another thing I noticed is your use of the old
I appreciate that this reply doesn't unblock you immediately, but I can share there is light ahead! |
Beta Was this translation helpful? Give feedback.
-
|
Hello again @eddieh-xlnx and @clavin-xlnx , I have given the I tried to recreate the net that I removed in my original code snippet by doing the following:
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 Terminal output Also, @clavin-xlnx : I tried your tip regarding loading the DCPs, but RapidWright couldn't read the netlist in the I appreciate the help as always! / Chrysella |
Beta Was this translation helpful? Give feedback.
-
|
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 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 Appreciate the help always and thanks for everything so far! // Chrysella |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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:
Approach:
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.Used
connect()from theNetclass -> 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 withreport_route_statusin 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
I1onlut_2isn'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 andgetPinMappingsL2P()from theCellclass show that the logical pins should be namedI0-I5.Is my speculation correct? Has anyone had this problem before?
I appreciate any help that I can get!
/ Chrysella
Beta Was this translation helpful? Give feedback.
All reactions