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.
Since RapidWright has exported Interchange data as a single message, there has been a limitation on exporting the routing information (specifically
NodeandWireobjects) 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 orget_property ROWS [get_parts [get_property PART [current_project]]]in Vivado). All of theWireandNodeobjects that exist or are based in that row of tiles are included in the message.For example, if you were exporting the
xcvp1902device (currently the largest device), there would be 1457 Cap'n Proto messages total in the file (1 device, 1456 routing). In this scheme, theDeviceResources.Deviceobject is the top level for both types of messages. In the device message, the fieldswiresandnodesare set tonullto signify that messages will come later to populate those fields. In the routing messages, only thewiresandnodesfields 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 thewiresandnodesentries 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.