Automatic SRAM inference and mock SRAM with timing for exploration

[oharboe]

Description

FPGA designs can have inferred SRAM. Inferred SRAM is supported by Yosys, but if it is inferred it is automatically converted to DFF, which makes the designs explode in size and time.

Suggested Solution

Automatic SRAM inference and mock SRAM insertion would greatly speed up and automate exploration

Additional Context

No response

[oharboe]

@tspyrou @maliberty I work around this for now by reducing the number of rows in the SRAMs and inlining DFF RAM. If I forget one, then the turnaround times blow up.

[maliberty]

You would be better off filing this against yosys. Mostly people generate rams and instantiate them explicitly in asic design. FPGAs have fixed memories so inferencing makes more sense as there is no real choice of ram configuration.

[oharboe]

You would be better off filing this against yosys. Mostly people generate rams and instantiate them explicitly in asic design. FPGAs have fixed memories so inferencing makes more sense as there is no real choice of ram configuration.

Yosys already does SRAM inference, so that is in place. I think the missing bit is in ORFS.

@tajayi Did some work on fakeram inference in ORFS, but it never made it into master

[maliberty]

What is missing in ORFS?

[oharboe]

What is missing in ORFS?

The automatic creation of the SRAM macros based upon the ram inferred by Yosys.

[oharboe]

@maliberty I can't the branch that @tajayi created in ORFS anymore, but as I recall, there were some scripts that parsed Yosys output, then invoked https://github.com/bespoke-silicon-group/bsg_fakeram to generate SRAM macros.

[maliberty]

In general RAM generation can be handled by many different tools (fakeram, openram, proprietary ram generators). Real generators have many options that the user will need to chose from. I think of this more as part of PDK setup than an OR function.

I don't recall the branch you are referring to. It must be years old.

[oharboe]

In general RAM generation can be handled by many different tools (fakeram, openram, proprietary ram generators). Real generators have many options that the user will need to chose from. I think of this more as part of PDK setup than an OR function.

Understood. It is precisely because of all this complexity that it is so valuable to have automated during exploration.

I don't recall the branch you are referring to. It must be years old.

Yes. It's years since @tajayi worked on OpenROAD....

[rovinski]

Yes, I recall the FakeRAM inference @tajayi worked on. It was really just a hack he did in a couple days. It never got beyond a proof-of-concept stage.

@maliberty what Tutu did was to take the output of the memory inference step in yosys which identifies verilog memory arrays and then generate a FakeRAM configuration. FakeRAM is much easier to deal with than other memory compilers because it assumes an overly-optimistic aspect ratio and there's no need to explore multiple configurations.

There is a way in yosys to replace modules, and I am not sure if he got around to the post-elaboration stitching of the memory macro into the hierarchy.

Many companies internally implement a tool to do SRAM exploration. The big problem is that everyone reinvents the same solution because they have to interact with memory compilers which are under NDA and often have very poor user interfaces. Each compiler has to have a bespoke solution which makes scalability incredibly difficult.

Perhaps the open-source community would benefit from an example SRAM inference tool, but the main challenge would be in a heuristic or search function which identifies the point at which a memory array is better implemented as an SRAM. Without an exhaustive search, it's not always clear, especially depending on the PDK.

[oharboe]

Not in the cards currently.