Closed codepilot closed 2 weeks ago
Attached are the problematic entries
Not a vivado issue
get_wires -of_objects [get_nodes GTYP_QUAD_SINGLE_X0Y240/GTYP_QUAD_SITE_0_APB3PRDATA_0_]
results in:
GTYP_QUAD_SINGLE_X0Y240/GTYP_QUAD_SITE_0_APB3PRDATA0 CPM_G5_TILE_X0Y95/CPM5_ATOM_0_IFFCTRLQ3PRDATASF0
so CPM_G5_TILE_X0Y95/CPM5_ATOM_0_IFFCQ10TXONESZEROSFS is not in that list
This is the first line of the test-results.log
Thank you for reporting this issue! I've diagnosed it to a missed check on the device creation process. RapidWright attempts to compress the incoming device data and uses 16-bit storage for certain wire index representations. The tile type CPM_G5_TILE
in xcvh1782
(and presumably other devices) has 79740 wires, clearly exceeding the 65535 threshold.
We can probably rearrange the storage without much impact to memory utilization, but it will likely require a new set of device files and an updated release. I will also add the appropriate checks and your test above to future release cycles.
Are you able to work around this issue in the meantime, or is there an urgency in getting this resolved?
@codepilot - I've created PR #984 which should resolve this issue. It requires new devices files and a new rapidwright-lib jar (both specified in the branch device_widen_wire_index
. Switching your local RapidWright git copy to that branch and running ./gradlew updateJars
should get you all the changes you need. Give it a try and let us know how it goes.
@codepilot - I've created PR #984 which should resolve this issue. It requires new devices files and a new rapidwright-lib jar (both specified in the branch
device_widen_wire_index
. Switching your local RapidWright git copy to that branch and running./gradlew updateJars
should get you all the changes you need. Give it a try and let us know how it goes.
Will do
When iterating through all wires and nodes in a device, this code below should never output anything. It does for xcvh1782. It would be good to add to the tests.