ASM vs. RAM

I think that would depend on the details of your ASM, including, but not limited to, whether or not your FPGA synthesis tools or ASIC foundry could implement it.

It sounds like might want a good old shift register, which may well take fewer CLBs in an FPGA than the same amount of static RAM implemented the same way. But it probably wouldn't be smaller than a block of built-in RAM, which seems pretty prevalent in FPGA's today.

Similarly, such a gizmo may save space in an ASIC vs. the same amount of RAM, but only if you compare apples to apples -- your ASIC vendor will have RAM blocks (both static and dynamic) that are hand-optimized. A hand-optimized ASM is probably going to be smaller than hand-optimized RAM, but if you just describe it in HDL and let the synthesizer loose on it, I doubt it'll be better than a RAM block and a sequencer.

Unless your project has the market behind it to pay for that hand optimization, or unless your chip vendor has ASM blocks for you, I think pre-made RAM plus a sequencer is going to be the way to go.

--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

Tim, thanks a lot!

So, the most reliable way is to request a foundry about its RAM and ASM blocks in form of physical IP or macros (sorry my incompetence). But can you or anyone else tell me on behalf of the foundry what could be the answer? I mean, what could be approximate rate of RAM to ASM in terms of die size and so on?

Just for sure - Am I correct that one logic cell (logic element) can hold

16 bits of a sequential shift register and thus to keep 1023x10 bits I need 1023*10/16=640 elemets as a margin?

--------------------------------------- Posted through

First of all, there seems to be some confusion regarding whether you target an ASIC or an FPGA. In Xilinx FPGAs some look-up tables (LUTs) can be used as shift registers. An older Xilinx FPGA with 4 input LUTs can store 16 entries whereas newer FPGAs like the Virtex-6 can store

32 bits in a single LUT used as a shift register.

Another way to get a very cheap long shift register might be to set a blockram into FIFO mode which is possible on some Xilinx FPGAs.

Do note that building a very long shift register would likely consume more power than a FIFO implemented using a blockram.

However, if you are mainly targetting ASICs, this kind of design feature in FPGAs is of little interest. I have been involved in a few ASICs, and I've never heard about auto-sequencing memorise being available as hard macros. However, I may just have missed something here.

Nevertheless, if we assume that such a memory would be implemented in roughly the same way as a regular SRAM memory (that is, using a 6T memory cell [1] together with row and column lines and sense amplifiers) I don't see that there could be much difference between an ASM and a RAM. (At least for larger memories.)

Also note that well optimized memory blocks in ASICs are much more area efficient than the equivalent memory implemented using standard gates. I've found the following numbers from an evaluation I did some time ago for a 130nm ASIC process:

• 512 bit register file memory in standard gates: 2.5 area units

• 65536 bit custom memory from a memory compiler: 33 area units

Note that the custom memory contains 128 times as many bits while being only 13 times larger. (Both memories were optimized for area.)

Anyway, as a comparison a 32 bit adder occupied from 0.21 to 1.0 area unit depending on whether it was optimized for area or speed. So the difference between a large custom memory and a large custom memory together with a few small adders/registers that you use for sequencing (effectively turning it into a FIFO) would be quite small. (You wouldn't even need to use adders, you could use LFSR registers to reduce the size of the sequencing circuit.)

However, it doesn't hurt to ask if the foundry knows about some very efficient ASM blocks. (If I understand your question correctly it might be better to ask for efficient FIFO blocks since it seems like your problem could be solved using a plain FIFO.)

I hope this is of some use to you when deciding on your architecture.

regards /Andreas

Ok, I understood. Thanks!

Just question about "using a 6T memory cell"

Does it mean 6 MOS transistors that handle and ouptut one bit?

And did I get correctly the main concern that 2D static RAM I can get from foundry is already overhead free, i.e. there is no penalty due to address decoding, and thus the additional optimization will not make sense?

--------------------------------------- Posted through

Static RAM needs 6 MOS transistors just to remember what it was told:

It still needs sense and address lines to get the data into and out of the memory.

Dynamic RAM just needs one MOS transistor and a capacitor, but you have to keep reminding it of what it should already know:

No, it's not that there's no penalty due to address decoding. It's that there's a WHOPPING BIG PENALTY for getting something outside the box: either you get something that's made up out of individual gates, and is therefore huge, or you have to HAND MAKE your ASM, which takes a huge amount of time.

Re-read what Andreas said about hand-made RAM vs. compiled. He's comparing the difference between the output of their "memory compiler" (which is hand optimized to generate nothing but RAM) and some memory that was specified with (I assume) plain old HDL.

A shift register made up from static cells is still going to need six MOS transistors per cell, although it's not going to need the addressing logic. But if it's not already made for you, then you're back to needing it to be hand made ($$$$$) or synthesized from gates (area area area).

Ditto a shift register made from dynamic cells, although then you'd be talking maybe two or three transistors / cell (I don't know my trivia well enough to say).

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html