search

Xilinx / RapidWright

Build Customized FPGA Implementations for Vivado
http://www.rapidwright.io
Other
276 stars 106 forks source link

" Too many words to allocate: 333129474" beyond the limit of capnp? #410

Open the-centry opened 2 years ago

the-centry commented 2 years ago

============================================================================== == Device Resources Dump: xcvu7p-flvb2104-1-e ==

Loading device from file xcvu7p-flvb2104-1-e Load Device: 3.590s 440.991MBs populateEnums: 0.458s 52.941MBs SiteTypes: 0.082s 4.029MBs TileTypes: 0.200s 4.374MBs Tiles: 0.494s 44.722MBs INFO: Building uncommon Wire->Node cache... This might take a few seconds for large devices on the first call.
It is generally triggered when getting the Node from an uncommon Wire object.
To avoid printing this message, set Device.QUIET_MESSAGE=true or set the ENVIRONMENT variable RW_QUIET_MESSAGE=1. INFO: Finished building uncommon Wire->Node cache Exception in thread "main" java.lang.RuntimeException: Too many words to allocate: 333129474 at org.capnproto.BuilderArena.allocate(BuilderArena.java:130) at org.capnproto.WireHelpers.allocate(WireHelpers.java:80) at org.capnproto.WireHelpers.initStructListPointer(WireHelpers.java:509) at org.capnproto.StructList$Factory.initFromPointerBuilder(StructList.java:81) at org.capnproto.StructList$Factory.initFromPointerBuilder(StructList.java:30) at org.capnproto.StructBuilder._initPointerField(StructBuilder.java:194) at com.xilinx.rapidwright.interchange.DeviceResources$Device$Builder.initWires(DeviceResources.java:906) at com.xilinx.rapidwright.interchange.DeviceResourcesWriter.writeAllWiresAndNodesToBuilder(DeviceResourcesWriter.java:807) at com.xilinx.rapidwright.interchange.DeviceResourcesWriter.writeDeviceResourcesFile(DeviceResourcesWriter.java:280) at com.xilinx.rapidwright.interchange.DeviceResourcesExample.main(DeviceResourcesExample.java:29)

Second If the source code of rapidwright_jars.zip is opened for users ?

clavin-xlnx commented 2 years ago

Thank you for the issue report. Indeed, this has been a problem with larger devices being represented in the current Interchange schema (see #176). There is a long term solution to this issue, but I can investigate a path forward in the short term for these larger designs, but currently, we don't have a work around.

To answer your other question, the rapidwright-api-lib jar is currently not available in open source. If you have any specific use cases you are willing to share, please comment or reach out directly. We are happy to facilitate a solution if you have a particular challenge with the current tools.