SRAM Email from Microsemi - CN17019

[dohzer]

Did anyone else get the email from Microsemi the other day essentially saying that the SRAM Read Clock and Read Address should be generated in the same clock domain or data will be corrupted? This really confused me.

"Data in the block SRAM gets corrupted when the read address (READ_ADDR) and the read clock (RD_CLK) are asynchronous. This issue occurs when the design has two independent clock domains: one for the read/write clock of the SRAM and another for the read address generation. No failure occurs when the memory is functioning in synchronous mode. Any IGLOO, ProASIC3, Fusion, SmartFusion, or RT ProASIC3 device could have this issue."

Why would they need to explicitly explain that?
Isn't that just common practice?

See CN17019.
https://www.microsemi.com/document-portal/doc_download/137549-cn17019-igloo-proasic3-fusion-smartfusion-and-rt-proasic3-data-corruption-in-block-sram-when-used-in-designs-with-multiple-clock-domains (.pdf file)

[dmills]

I would expect data READ FROM a BRAM where you were fail to meet timing to be corrupt, but this seem to be saying that the act of reading the data while failing to meet timing CORRUPTS THE MEMORY CONTENTS, not at all the same thing.

Now managing to trigger this looks like exposing a bug in your HDL, so this sort of fits into the "Doctor it hurts when I do this" category, but even in the presence of such a bug, this would be unexpected behaviour so better it be documented, especially for customers looking to push to ASIC where timings may be slightly different. 

Regards, Dan.

[dohzer]

but this seem to be saying that the act of reading the data while failing to meet timing CORRUPTS THE MEMORY CONTENTS, not at all the same thing.

Yeah, that's what I found really bizarre. It does say "read/write clock", but why would the read address alter the memory contents?
There must be some strange "read clock vs write clock" timing requirement, or maybe a single address bus for both reads and writes. Hmmm....
I'm going to have to look at their SRAM-related app notes and data sheets to see if they give any clues.

[amyk]

It sounds like the sense amplifiers are erroneously transferring one row to another.

Reminds me of this: https://www.linusakesson.net/scene/safevsp/

More info: http://user.engineering.uiowa.edu/~vlsi1/notes/lect19-sram-dcm.pdf

[cstratton]

"Data in the block SRAM gets corrupted when the read address (READ_ADDR) and the read clock (RD_CLK) are asynchronous

This type of issue has been historically common with FPGA block RAMs - Xilinx has written about it, and I've personally seen it with Altera

In fact I saw it with a "ROM" - had an SDR design that was clocked (directly or by a multiple of) a low phase noise external sample clock source that didn't necessarily lock immediately.  Originally though calculating garbage data during startup if the clock was briefly glitching was no big deal - but it turned out that violating timing on the filter coefficient ROM would lastingly corrupt its contents until the config bitstream was reloaded.

An FPGA block ROM of course is just a RAM with no designed write mechanism, and whatever implementation detail that makes violating address setup timing dangerous (shorting cells to one another? mis-sequencing of the bitline circuitry?) existed for the "ROM" usage just as much as RAM usage.

Effective solution was to use the clock source's lock signal to create an enable for the internal memories (probably through some safety delay; it was years ago so I don't remember all the details)

[dohzer]

shorting cells to one another? mis-sequencing of the bitline circuitry?

That makes a lot of sense!
Thanks for that info. I'd never even really thought about a *ROM* being corrupted in those ways.