Where are the ICE40 RAM models?

[sjalloq]

I'm using the 4-bit RAM primitive in my design, SB_RAM1024x4NR, but it doesn't seem to appear in the list of cells printed out when running synth_ice40. The cells_sim.v file has something called SB_RAM40_4K which doesn't appear in the ICE40 documentation.

[cliffordwolf]

SB_RAM40_4K which doesn't appear in the ICE40 documentation.

page 82: http://www.latticesemi.com/~/media/LatticeSemi/Documents/TechnicalBriefs/SBTICETechnologyLibrary201504.pdf

[sjalloq]

OK, so great, it appears in the documentation. But where are the rest of the primitives in the Yosys library?

Or perhaps this is lost in translation so I'll clarify. The Yosys library seems to only have a cell called SB_RAM40_4K. What is the user supposed to do when using the other listed RAM primitives and the tools complain that they don't know what they are?

[cliffordwolf]

SB_RAM40_4K is the only primitive that exists in the device. The others are what other vendors call "macros".

What is the user supposed to do when using the other listed RAM primitives and the tools complain that they don't know what they are?

There is nothing the "other primitives" can do that you can't do with SB_RAM40_4K (and its variations for inverted clocks). If you want to instantiate a primitive, instantiate SB_RAM40_4K.

"Users" usually should not instantiate any of those anyways. Simply write your Verilog code and let the tool infer block rams for you.

[sjalloq]

So this is how it has been done in the industry for years - using the vendor supplied "macros", or primitives as Lattice call them. That's why they detail the RTL instantiation details in the user guides. Specifically from the Memory user guide, "This section lists the iCE40 sysMEM EBR software primitives that can be instantiated in the RTL.".

So a design that synthesises in the Lattice or Synplify tool chains doesn't work with Yosys and requires extra wrapper.

[cliffordwolf]

using the vendor supplied "macros", or primitives as Lattice call them.

I think I have not expressed myself clearly, because obviously you have not understood yet the difference between macros and primitives.

Only SB_RAM40_4K is a primitive. You can call the others whatever you want, some vendors call them macros, but they are NOT primitives. They are simple wrappers around primitives for people who for some reason want to instantiate things manually, but don't understand how the actual hardware primitive works.

If you want similar wrappers in Yosys feel free to create them and create a pull request.

So this is how it has been done in the industry for years

Always a great argument. :)

It's because historically synthesis tools where really bad at inferring memories. And providing lots of convenience macros was the only thing vendors knew how to do.

Wanna live in the late 90s? Fine. Use the tools that existed back in the late 90s.

Wanna write those wrappers yourself and create a PR? Also fine.

But I have better things to do.

[sjalloq]

Perhaps you can use the argument that the older synthesis tools were not good at inferring memories but that is not the reason the industry still instantiates the macros (I can't be bothered arguing nomenclature and prefer to use the naming that Lattice use to avoid confusion, but I'll use your "macro" from here on).

Take an ASIC design flow, for example, at a company like ARM producing IP, in the 90's or now. The ASIC flow uses RAM generators to build the RAMs used for synthesis. These library specific RAMs are placed in a Verilog wrapper in a directory parallel to the wrappers that instantiate the FPGA Block RAM versions. There will also be a simulation model version and you point your synthesis scripts to the correct path for the target implementation that you are building.

Instantiating the "macro" removes any ambiguity from anyone reading the code and allows the designer to specify the exact BRAM configuration that they want without having to worry about what the EDA tool thinks is the best implementation.

Now, I can see how a hacker or a student wouldn't really care about all that and would be happy letting the tools infer what they want, but the rest of us aren't.

I guess I'll go back to the 90's where the tools actually work. ;-p

[cliffordwolf]

Now, I can see how a hacker or a student wouldn't really care about all that and would be happy letting the tools infer what they want, but the rest of us aren't.

Then instantiate the actual device primitive, SB_RAM40_4K.

Or simply write the wrapper and create a PR as I pointed out above.

You claim to be an industry expert, so obviously you don't need me to do it: You are just to lazy to do the work yourself.

I guess I'll go back to the 90's where the tools actually work. ;-p

Okay, bye. I'm now locking this conversation.