The Solution to fakeram 2.0’s Limitations Is Not fakeram 3.0 — It’s the Flow We Already Have

[oharboe]

fakeram has been used to generate placeholder SRAM macros for use in RTL-to-GDS flows, you get .lib, .lef, and .gds views to proceed with testing OpenROAD and studying a design without having actual SRAM macros.

This is especially helpful with asap7 that does not and will not obtain in the future the ability to generate actual srams.

What fakeram 2.0 Is (and Isn’t)

fakeram 2.0 presents itself as a tool to "generate SRAMs," but under the hood, it is a small Python module that emits Liberty, LEF, and GDS files through print statements and static templates. It does not:

• Use the PDK or standard cell libraries
• Perform synthesis or layout
• Characterize delays or area based on actual parasitics
• Produce views consistent with real tool outputs

fakeram 2.0 plays to the understandable desire for a turnkey "SRAM generator"—but by creating files that look the part without meaningful modeling.

A Better Approach Using What We Already Have

Now that the OpenROAD toolchain and ORFS PDK integrations are mature and available, there is a practical and scalable alternative that avoids these problems entirely:

1. Write a small Verilog module that matches the SRAM or macro interface.
2. Insert simple logic (e.g. flip-flops, muxes) to approximate behavior or latency.
3. Run the module through the standard OpenROAD flow using ORFS.
4. Export .lib, .lef, and .gds using real synthesis, place-and-route, and extraction.

This yields:

• PDK-aware outputs — for instance, pin positions line up with expectations for detailed routing
• Usable Liberty views — approximate timing based on actual layout
• DRC-clean GDS — you can test detailed routing at a higher level

Example of mocking sram: https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/tree/master/flow/designs/asap7/riscv32i-mock-sram

Generalizes Beyond SRAMs

This method isn't just for mocking SRAMs. Any macro block with a defined interface can be mocked this way:

• Register files
• Multipliers
• Barrel shifters
• ALUs

It's a flexible and reusable technique that allows early progress on physical integration without needing finalized IP.

Recommendation

Rather than extending fakeram into a "3.0" version, the more reliable path forward is to use the toolchains and flows we already have—OpenROAD, ORFS, and a small amount of targeted Verilog—to build mock macros that are physically and logically consistent with the rest of the design.

This avoids the pitfalls of handcrafted views and brings macro modeling fully into the digital flow.

[maliberty]

Your suggestion is fine for a non-manufacturable PDKs like asap7/ng45. There are other uses cases where fakeram is more appropriate.

[oharboe]

Your suggestion is fine for a non-manufacturable PDKs like asap7/ng45. There are other uses cases where fakeram is more appropriate.

Sounds good.

What information is taken from the PDK and how does it make it into fakeram?

How are pins put in the right place?

Also, there is still the question of behavioral model match between fakeram and the RTL code.

How does fakeram know which behavioral model to use?

[oharboe]

Is there an example of how to use it to generate something reasonable?

area, aspect, timing, pin placement, blockages is what comes to mind.

[oharboe]

An example of where one can use mock SRAMs for real PDKs.

Let's say I want to find out if it is worth setting up ORFS/OpenROAD with a commercial modern PDK and I have a design that uses some SRAMs and I'd like to run that through ASAP7, but with somewhat realistic SRAMs from the commerical PDK, to get some sense of what results to expect.

1. Start with some existing RTL that is using some SRAMs, e.g. https://github.com/The-OpenROAD-Project/megaboom
2. Immediately the mismatch between what is provided by SRAM generators in the PDK and what is expected by the RTL becomes obvious. Either write wrappers to fit the existing SRAMs(can be tricky and time consuming as there can be a non-trivial difference in the behavioral model, pin names, etc.), or if you are lucky you have a tool like barstools to bridge this gap.
3. Generate a few SRAMs, study the reg2out and in2reg timing (there would be no in2out and reg2reg paths in an SRAM), then write a bit of Verilog using the Verilog SRAMs that gives similar timing. You can do this in OpenROAD by loading the .lib file and behavioral Verilog. You might see something like the below.
4. Project an area/floorplan for your SRAMs based on what you see from the PDK SRAM generator
5. Now you have a rough SRAM floorplan + Verilog that mimicks timing model and you can use OpenROAD to build your mock srams.
6. Build your design using these mock SRAMs and ASAP7to get a sense of what your design will look like in a modern node and answer broader architectural exploration questions and to see if there's a path forward with OpenROAD/ORFS.

It is also possible to mix the .lib file from the real PDK and the .lef file from an ASAP7 PDK (generated from behavioral Verilog in ORFS/OpenROAD) to get somewhat more relastic timing, but these are second order approximations at best when mixing two PDKs, so might not be worth the effort.

in2reg 200ps clock period - 63ps = 130ps. So 130ps to write to the SRAM.

reg2out 200ps - 130ps = 70ps. So 70ps to read from the SRAM.

[maliberty]

The process of investigating some rams and tuning others to match area/power/timing/pins is similar is either case. Its unclear the OR is adding that much value over something that generates them directly with near zero runtime overhead. Most of the effort is in correlation.

[rovinski]

@oharboe you'll find that trying to estimate SRAM timing was the subject of great scrutiny about 10-15 years ago which is how McPAT came to be in the first place. It is extraordinarily difficult to model SRAM timing without having very involved models which requires a lot of data from the PDK, as well as low-level SRAM design tradeoffs which FakeRAM current abstracts away for the user.

The notion of taking standard cells or other process-specific data won't get you that much further in estimation because SRAMs often use non-CMOS logic and other tricks to get them to be faster than standard cell designs. Using SPICE modeling is only helpful if you already have a model for the key components like the bit cell and the sense amplifier, otherwise other data is not really representative because SRAM uses separate processing rules than regular logic. Also, you cannot perform STA on an SRAM because it is not fully digital logic internally.

In other words, it's really hard to do much better than FakeRAM in terms of estimation until you go to a full implementation like OpenRAM. It would be a better idea to look at publications or other open data for the process you're looking at (or a similar process) and try to modify the numbers yourself in the .lib.

Also, FakeRAM doesn't produce .gds, it only produces .lef, .lib, and .v as far as I know.

[oharboe]

Things fall apart before you even get to FakeRAM or get fancy about SRAM and spice modelling.

If you have existing RTL, then the behavioral model wont match FakeRAM, almost certainly. The pin names wont even match.

MegaBoom illustrates this well. barstools exists for this reason. There is a plethora of behavioral models and that is not even counting register files, never mind multipliers and other macros such as barrel shifters.

By using mock RTL, you can get the semantics of the timing model right(which pins are in2reg, reg2out, in2out).

Then make the assumption of a small SRAM responding in a cycle and pick an area guess from a real PDK.

This is essentially MegaBoom's approch.

[rovinski]

I'm not following the argument exactly, but would this not be what a wrapper is for?

It sounds like FakeRAM maybe just doesn't offer the type of RAM you are looking for, in which case you can compose it from multiple 1rw RAMs, or FakeRAM would need additional support for (I'm guessing) 1r1w.

[oharboe]

Indeed barstools is a "wrapper" tool and indeed you can compose a register file or your SRAM of simpler SRAMs. However, at that point the timing area of the FakeRAM or PDK SRAMs are most approximate of what is possible.

So ... if there is no exact match, might as well use mock RTL to at least terminate timing paths of pins and in2reg, reg2out accurately and make a guess as to area.

In the forseable future OpenROAD will be able to assign power on a per module basis. mocked srams will then appear as separate items in a power report and some reasoning can be done. If SRAM power consumption is 0, we see that xxx dominates.

[QuantamHD]

But this is exactly what's done in industry when you have access to real SRAMs @oharboe. The foundry rarely provides SRAM sizes that match exactly what you want. You then need to compose SRAM primitives together in order to make what you want.

IMO the flow with fakeram should be something like try to meet your performance goals at the most conservative estimates for the process, and if your design is particularly sensitive to SRAMs I'm not sure there is viable alternative other than to get the memory compiler for your process.

[oharboe]

Yes, hence barstools.

Of course ASAP7 for megaboom does not have any SRAMs, so there mock RTL shines.

[benreynwar]

Somewhat related to this I'm trying to work out what the best approach is for estimating SRAM area and power for an open-source design space exploration run. I'd really like to be able to do it with open tools (even at the cost of some accuracy) since it'll be more shareable and reproducible. At the same time I don't want to get results that are totally different from what I'd get with proprietary PDKs and tools.

Using the skywater130 PDK it looks like I can get a fully open-source flow. I'm using bazel_orfs, and am adding in SRAM generation with OpenRAM, and stimulus generation with some cocotb tests. I don't have it working yet, but there's a path.

I'd also like to get results for a process node that's a bit more modern. I don't need a real PDK so ASAP7 would be fine, but I'm unsure what I should do there for the SRAM generation. Is https://github.com/ABKGroup/FakeRAM2.0 something that could give me reliable numbers? I don't want to build the memory macros using std cells because that will dramatically overestimate the area and power for the depths I'm looking at.

[maliberty]

There are no real rams for asap7 so everything is speculative. FakeRAM2.0 is a reasonable solution or @oharboe has his methodology I'm sure he is willing to expound.

[benreynwar]

Just looking at the FakeRAM2.0 repo it's hard to believe it generates reasonably accurate numbers. I think I'll take the approach of running DSE in skywater130 and FreePDK45 using OpenRAM to see how they compare, and then probably run with GF12LP and a proprietary memory compiler to see if the DSE conclusions are similar or not.

[maliberty]

OR does support GF12LP though we can't make the enablement public. If you are a GF customer we can generally get permission to share privately. You can contact https://precisioninno.com/ if you are interested.

[oharboe]

Mocking SRAMs in Verilog can be surprisingly powerful—especially for early prototyping, research flows, or when SRAM compiler models aren't available.

By writing your SRAM as synthesizable Verilog with the correct ports and behavior (e.g., synchronous read), you can generate a .lib with "infinitely fast" timing that still:

• Preserves correct timing path shape (e.g. paths terminate at flip-flops for sync read)
• Models sync vs async behavior properly for STA
• Works seamlessly with synthesis and OpenSTA—no black boxes or extra steps
• Avoids the need for Verilog wrappers around placeholder black-box SRAMs

Even though the timing isn't realistic, it's accurate in structure and sufficient for:

• Timing exploration
• Flow development
• Area/power estimation of the rest of the system (OpenROAD will output hierarchical Verilog in the not so distant future)