Skip to content

ram: feature tracker #9392

Open
12 of 14 issues completed
Open

Description

@rovinski

Description

This is a public tracker for feature development for the ram tool.

  • Add support for endcap insertion
    • Endcaps need to be inserted around the perimeter of the RAM bounding box after fill
  • Physical verification
    • Check that timing, LVS, and DRC are clean via external tools
  • Sweep word and bit sizes 1-64 (all values) to verify support for arbitrary array sizes (no placement or routing errors, LVS clean, DRC clean, passes STA)
  • Add support for AND3/AND4 cells in the decoder
    • Only AND2 is supported now. Larger arrays can be more efficient with wider ANDs
  • Add support for automatic master selection
    • Find and identify FFs, ICGs, buffers, inverters, tristates, AND2/3/4s automatically if not user specified
  • Automatic detection of the followpin metal layer and width
    • The current implementation requires manual specification of the followpin layer and width. This should be automatically extractable from the library. The user should not need to specify this.
  • Add support for arbitrary bit mask granularity
    • Currently there is no mask support. Masking support should be added on an arbitrary basis (1 bit, 2 bits, 3 bits, etc.) as long as the word size is divisible by the mask size (cannot make a 2-bit mask for a 7-bit word)
  • Add cell anchoring
    • Allow instances within cells to be “anchored” at a certain point, such as for input buffers being aligned with the pins which they drive
  • Enable users to specify the input buffer to use, or to even disable completely
    • The current code always inserts a default size buffer. Allow users to manually specify which buffer to use
  • Enable users to specify an output buffer to use, or to disable completely
    • The current code does not use an output buffer, which may not be ideal for isolating array timing from the output loads. Add an output buffer by default, but also allow users to specify an output buffer to use or to disable the output buffer.
  • Automated test bench support
    • Add an option to automatically generate a testbench and test script for a generated memory. It should run a BIST-style test.
  • Formal verification support
    • Add support for using a formal verification tool to verify the RAM behavior
  • Add support for metal fill
    • Add an option to provide a fill config and use the built-in metal fill tool to fill the RAM before exporting.
  • Banking
    • Add support for multiple banks for very large arrays
    • Add support for clock gating inactive banks
  • Add preliminary structured clock tree placement
    • Currently, the clock pin directly fans out directly to all ICGs in the RAM. For small sizes, this is fine, but for larger sizes this can lead to very bad slew and skew. There should be a way to insert clock buffers between either words or columns to break up the large fanout.
  • Cross platform testing
    • Add a test for asap7. Would require adding a fake (or real) tristate device as it's not part of the PDK.
  • Add support for tapcell insertion intra-cell (currently only supported at word boundaries, potentially leading to more tapcells than necessary)
  • Add support for running integrated timing analysis
  • Add a user flag to specify the target clock period
    • This flag can be used in combination with timing in order to optimize power/area while still meeting timing constraints.
  • Add timing-guided decisions
    • Generate multiple RAM configurations based on user input
    • Use STA APIs to determine whether a certain configuration is better than another (power vs. delay vs. balanced)
    • Example parameters to try: input/output buffer sizes, column mux ratio, banking.
  • Investigate support for incremental RAM substitution
    • Consume timing path and constraint information external to the RAM and use it to potentially swap the RAM for a better configuration (e.g. optimize power if meeting timing constraints or vice-versa)
  • Investigate support for exporting as multi-height cell / structured placement group
    • Instead of creating a RAM block, the cells could be formed into a placement group which is aligned to the cell grid and fits directly into the core area, bypassing the need for a separate PDN and eliminating the need for block halos/endcaps.
  • Add support for automatically determining power grid widths, pitches, and layers, ensuring both routability and acceptable IR drop. Allow the user to manually override.

Activity

  1. rovinski commented on Jan 29, 2026

    @rovinski
    CollaboratorAuthor

    Experimenting with how to add sub-issues. I don't want to convert everything to a sub-issue from the start, I think. Probably only once it starts getting worked on.

  2. self-assigned this
    on Jan 29, 2026
  3. added theissue type on Jan 29, 2026
  4. rovinski commented on Jan 29, 2026

    @rovinski
    CollaboratorAuthor

    @braydenlouie @tnguy19 here is a list of todo items to work on. There's a lot of things to do but each one is helpful and fairly well-contained, at least until towards the bottom of the list (which I don't expect to get to for a long time).

  5. github-actions commented on Jul 29, 2026

    @github-actions
    Contributor

    This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 21 days if no further activity occurs. Remove the Stale label or comment to keep it open.

  6. added
    StaleA stale PR or issue subject to automated closure.
    on Jul 29, 2026
  7. removed
    StaleA stale PR or issue subject to automated closure.
    on Jul 29, 2026
  8. github-actions commented on Sep 27, 2026

    @github-actions
    Contributor

    This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 21 days if no further activity occurs. Remove the Stale label or comment to keep it open.

  9. added
    StaleA stale PR or issue subject to automated closure.
    on Sep 27, 2026
  10. removed
    StaleA stale PR or issue subject to automated closure.
    on Sep 27, 2026
  11. oharboe commented on Oct 14, 2026

    @oharboe
    Collaborator

    @rovinski several items on this list move forward in #11723. They're there as options on generate_ram, each off by default, with tests that route the block and check what the option computes:

    • Banking: -banks, with -bank_columns to place banks side by side or stacked, -bank_order contiguous|interleaved, -rb_ports for banked read ports, and -bank_column_layout.
    • Cross-platform testing (asap7): -read_style and_or reads through an AOI22/NAND2/NOR2 tree, so asap7 needs no tristate cell. The asap7 tests place, route and simulate the block. -tracks gives generate_ram the tracks asap7's flows use.
    • Automatic master selection: each role (inverter, AND2, buffer, clock gate, AOI22, AO22, OR2, NAND2, NOR2, tie, address flop) is found by its Liberty function, and the smallest one is taken. -cells overrides any of them.
    • User-specified input buffer: -cells buffer <master>.
    • Exporting as a structured placement group: generate_ram_netlist -periphery unplaced keeps the core placed by construction and leaves the periphery for the parent to place. ORFS dissolves the core into the parent's rows, so there's no separate power grid and no halo.
    • Physical verification and testing: every option test routes its block. Detailed routing ends with no DRC violations, and ram_sim.tcl simulates the routed block against a model of what it should hold.
    • Formal verification: in bazel-orfs, kepler-formal checks the generated register files for equivalence against their RTL.

    The integration tests are in bazel-orfs: the same options through the ORFS flow on small designs, simulated against RTL designs (riscv32i, ibex), and equivalence-checked. I keep tests there when they have no obvious home in OpenROAD or ORFS without widening what those repositories test or depend on. OpenROAD is becoming Bazel-only. ORFS has more dependencies and installs them on the host, so for now testing in ORFS stays within its make flow. bazel-orfs can bring in a simulator and an equivalence checker as Bazel dependencies, without adding to either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions