You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current LUT-RAM implementation is likely wrong after #1267, but less wrong than before.
In particular:
RAM32X1S should be able to pack between 6-8 BELs in a SLICEM, currently only 4 are accomidated
For future work around this:
We need to consult the relevant documentation, and determine what are the valid packing schemes for 32-bit LUT-RAMs (using RAM32X1S, RAM32X1D and RAM32M).
Develop a set of Vivado mini-tests demonstrating the various packing options
Add those to symbiflow-arch-defs and verify that VPR can pack that tightly
Verify that fasm2bels can round trip those designs for analysis
I've split the 32-bit LUT-RAM issues and 128/256 bit LUT-RAM issues into two seperate issues, with the 128/256 issues into #1275. This is because the fixes around the 128/256 is likely much less work than the fixes around the 32-bit LUT-RAM issues.
Vendor tools dram tests were not enabled until #1234 got merged.
With #1268 I have temporarily disabled the vivado_targets, to let CI go green (as it has been red for too long now).
This issue is to keep track of the problem with DRAM evaluated on vendor tools with fasm2bels.
The text was updated successfully, but these errors were encountered: