resets on synplicity inferred RAMs

Hi all,

Has anyone seen any examples of Synplify Pro inferred rams that implement a reset input to clear the RAM contents? All of the synplicity examples I've seen do not show this. I also turned up a white paper on their website that said it was not possible but the paper is almost 5 years old so I'm hoping things have improved a bit.

Thx,

Chris P.

Reply to
chrispy35
Loading thread data ...

Show me the silicon where RAM contents can be reset. There are memories that allow the synchronous output register to be reset but I'm not aware of any RAM reset, only register arrays used as memory.

Reply to
John_H

How do you propose to reset the RAM? This isn't a limitation of synplicity, it is a limitation of the silicon. Some RAM has output registers, such as Xilinx's BRAM. The reset on those primitives only resets the output register, not the RAM contents.

Reply to
Ray Andraka

Why there is such a limitation. Why cant we pass a rest to all ram cells. Please advice me. Thanks and regards Sumesh V S

Reply to
vssumesh

The reason is the silicon does not support it, there is no reset line that clears the RAM. The reason it is not designed into the silicon is that adding a reset just about doubles the size of a RAM cell, plus requires a very high fan-out signal. The area and speed implications are both strong disincentives to including a reset that clears the whole array at once.

Reply to
Ray Andraka

Reply to
vssumesh

Suppose you want to reset a RAM memory of 512 kilowords with one reset signal and you are writing to it in chunks of 32 bits.

You could design a wrapper around it where you could have one flip flop per word that signifies if that particular word is valid or not. Once the wrapper gets the reset signal, all flip flops are set to zero. As soon as you write to a certain word, the corresponding flip flop is set to 1. Once you read from the RAM memory, the wrapper will output all zeroes if the signal from the valid flip flop corresponding to the read address is zero, otherwise it will output the value from the RAM memory.

This is of course rather hardware intensive because you have to keep track of 512 flip flops. It will also increase the critical path of your memory readout by quite much. But it will work regardless of how often your reset signal is asserted.

If you don't want to reset your RAM memory very often you have many more design alternatives. The easiest would be to double buffer your RAM memory. While you are working on data in one RAM memory you are clearing the other.

/Andreas

Reply to
Andreas Ehliar

'Easy' being a relative term another relatively easy approach is to simply add a wrapper around your inferred memory that receives the reset signal and then sequences through the memory writing it with 0.

After a reset, it means that the memory would not be available for reading or writing until the initialization has been completed. Alternatively it could mean that the wrapper has a relatively l--o--n--g reset time requirement (with the initialization being kicked off by the leading edge of reset) where the user is expected to keep reset asserted for a long enough period of time for the memory initialization to be completed.

KJ

Reply to
KJ

It's *possible* to create rams with resets in ASICs and FPGAs, just not at all recommended. In the ASICs, you will no longer be able to leverage the precompiled memory libraries available from the vendor. I know of no vendors that have memories with resets as part of their standard offering. In the Synplify tool, you can include a reset in your inference and the synthesizer will dutifully implement your memory in registers.

Another consideration: for large memories, consider the current surge required to change all those bits at once. While a 20k LUT device is expected to be completely reset with one pulse, would 20 18 kBit memories fare so well? There are too many reasons not to include a RAM reset and too many workarounds to include it.

You have the choice of running through the initialization in a separate routine or keeping track of what data has been modified with "dirty bits" as another poster suggested.

This idea is not new to electronics. There are plenty of people who have considered and rejected the idea for reasons of cost, power, practicality.

Reply to
John_H

A similar scheme would be to use smaller memories (such as 16 bit LUT RAMs) for the valid bits. The clear will take the number of clock cycles equal to the size of the smaller memories. This takes rather less hardware than an array of FFs.

--
Phil Hays (Xilinx, but speaking for myself)
Reply to
Phil Hays

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.