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

[Interchange] Exports DeviceResources Routing (Wires and Nodes) Info in Multiple Messages #1017

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

clavin-xlnx
Copy link
Member

@clavin-xlnx clavin-xlnx commented Jun 25, 2024

Since RapidWright has exported Interchange data as a single message, there has been a limitation on exporting the routing information (specifically Node and Wire objects) because of the high number of these objects exceeded the message size limitations of Cap'n Proto.

This PR attempts to resolve this issue by exporting the entire device first (without routing data) as a single message and then exporting multiple messages following. After the initial device message, there is one message for each row of tiles in the device ( Device.getRows() in RapidWright or get_property ROWS [get_parts [get_property PART [current_project]]] in Vivado). All of the Wire and Node objects that exist or are based in that row of tiles are included in the message.

For example, if you were exporting the xcvp1902 device (currently the largest device), there would be 1457 Cap'n Proto messages total in the file (1 device, 1456 routing). In this scheme, the DeviceResources.Device object is the top level for both types of messages. In the device message, the fields wires and nodes are set to null to signify that messages will come later to populate those fields. In the routing messages, only the wires and nodes fields are populated with the wires and nodes that exist in that row of tiles. If the device resources file is to be generated without routing resources, only one device message is written to the file and the wires and nodes entries will have a size of 0.

A verification step was added to verify these new messages could be read and that the wires and nodes match the RapidWright device model. For large devices (like the xcvp1902, the verification process can take up to an hour or more depending on the host). Also, it will require more Java heap memory and -Xmx32736m (32GB) is a recommended option to the JVM.

Given the time and memory requirements of the verification step, this has now been made optional and must be turned on through the command line option --verify.

This PR also includes PR #1014.

Base automatically changed from vp1902_interchange_support to master June 27, 2024 20:41
github.com:Xilinx/RapidWright into vp1902_interchange_support_routing
Signed-off-by: Chris Lavin <[email protected]>
@clavin-xlnx clavin-xlnx requested a review from eddieh-xlnx June 27, 2024 21:18
Signed-off-by: Chris Lavin <[email protected]>
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

Successfully merging this pull request may close these issues.

1 participant