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

[fpga] Add flow and constraints to dump the flash info array cell sites #25363

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

a-will
Copy link
Contributor

@a-will a-will commented Nov 23, 2024

Adjust MMI dump to use a regex for mem type. Some memories in the FPGA can consist of both RAMB36 and RAMB18 types, depending on the width of the array. Use a regex to allow more flexible memory type detection.

Add KEEP_HIERARCHY to the prim_ram_1p instances representing the flash info arrays. This helps keep intelligible hierarchical paths to the memories, so we can readily select the correct cells.

Add calls to dump an MMI file for each array represented by a (bank,type) tuple, and add them to the bitstream cache entry.

Some memories in the FPGA can consist of both RAMB36 and RAMB18 types,
depending on the width of the array. Use a regex to allow more flexible
memory type detection.

Signed-off-by: Alexander Williams <[email protected]>
Add KEEP_HIERARCHY to the prim_ram_1p instances representing the
flash info arrays. This helps keep intelligible hierarchical paths
to the memories, so we can readily select the correct cells.

Add calls to dump an MMI file for each array represented by a
(bank,type) tuple, and add them to the bitstream cache entry.

Signed-off-by: Alexander Williams <[email protected]>
@a-will
Copy link
Contributor Author

a-will commented Nov 23, 2024

CC @moidx

Still a WIP, and I haven't tested splicing any particular image. We might be able to create a more targeted Tcl proc that could aggregate arrays (e.g. concatenate the two banks for each type into a linearized address space).

Also, it looks like the bitstream cache handling will need some updating. There are two approaches I can think of:

  1. Specify required properties in a schema for each top.
  2. Ignore problems with old bitstream cache entries, and do a two-phase integration.
    1. Add the bitstream and manifest generation, and get entries in the bitstream cache that have the new MMI files.
    2. Add bazel rules that consume the new MMI files after the bitstream cache is populated with the first entry.

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

Successfully merging this pull request may close these issues.

1 participant