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

VTR seems to struggle with being smart about how it packs into memories #2718

Open
WhiteNinjaZ opened this issue Sep 12, 2024 · 0 comments
Open

Comments

@WhiteNinjaZ
Copy link
Contributor

While testing some small memory designs on the 7-series architecture I found that the order in which the diffrent BRAM sizes are specified matters greatly when it comes to which BRAMs VTR chooses to use for implementing the design. It appears that as long as the first BRAM given in the xml is large enough to fit a given memory it is chosen by default even if using smaller memories would be more efficient.

Expected Behaviour

VTR should try to be more efficient in how it chooses which RAM sizes to use (i.e. for a 16k memory should be packed into a RAMB18 and not a RAMB36). The type of BRAM chosen should not be dependent upon the order in which the BRAMs are given in the architecture.

Steps to Reproduce

On the current Xilinx architecture given here run the following infer_dual_port18.txt which should result in the pb usage given bellow:
image

Now switch the order of the RAMB36 and RAMB18 modes in the xml description and re-run. This should result in the following Pb type usage:
image

As you can see the type of BRAM used is completely changed by switching the order in which they are given in the xml

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

No branches or pull requests

1 participant