ROM (altsyncram) corruption

Anyone ever seen the contents of an FPGA "rom" (made up of several Stratix M4k rams with one read only port) corrupted?

I have a design where the 80 mhz system clock is coming via the sample clock in-out path of a high performance ADC from an external low phase noise generator. If the clock glitches, cuts out, etc, the contents of some, but not all, of my FIR coefficient ROMs get scrambled.

The read ports of these ROMs are run from this clock, but it shouldn't be possible to write to them. I also have a RAM that is writeable, and it similarly gets scrambled.

I don't really want to use the clock PLLs, since my output registers need to be synchronized to the low phase noise source, which an FPGA PLL is not. I did some preliminary experiments with clocking most of the logic from a PLL and keeping only the input and output registers on the raw clock input, but I don't like working around a problem that in my opinion really shouldn't be happening.

Any ideas why clock glitches could corrupt the ROMs? Only theory I can come up with is that maybe a bunch of faster than usual edges kerchunk all the logic, overtaxing the instantaneous power supply.

Anyone seen something similar?

Reply to
cs_posting
Loading thread data ...

From "Cyclone II Device Handbook", volume 1, (Altera Corporation, Februrary 2007), page 2-28:

"Violating the setup or hold time on the memory block address registers could corrupt memory contents. This applies to both read and write operations".

Probably you should check the Stratix handbook for your case.

Reply to
MikeShepherd564

Interesting idea, as one discovery I made is that if I hold my logic in user reset while abusing the clock, it seems to survive, provided I bring it out of reset only under conditions of a clean clock.

Reset does nothing to the memory itself, but it does mean that the address register isn't changing.

Still, even if an explanation, this seems like it would be pretty spotty behavior for a "ROM" !

Reply to
cs_posting

FYI, some of Xilinx's RAMs have a similar (maybe the same?) problem.

formatting link
HTH., Syms.

Reply to
Symon

problem.http://www.xilinx.com/support/answers/21870.htm

This is correct,and we document it also, after having detected this accidentally.

If the RAM is selected, even if WE is inactive, a violation of the address set-up time CAN occasionally corrupt the RAM=ROM content. This may sound strange. How can anything write a data corruption when WE is inactive?

If address lines change at a certain place inside the specified set-up time window, then two different address decoders can be activated simultaneously, and interconnect different data locations through their sneak path. Ugly!

It's not very likely, but we have measured it. It is real.

Moral: Never violate the address timing with repect to the set-up time before the active clock edge. If you have to violate it, make sure that the Memory Enable signal is inactive, not only the Write Enable. Then there will be no problem whatsoever.

Peter Alfke, Xilinx Applications

Reply to
Peter Alfke

Yes, that's what had us all scratching our heads today!

Aha, now that actually makes sense. I wonder if the same mechanism is at fault for the very real behaviour I'm seeing in an Altera part when I turn the clock source on and off.

I have verified that deactivating the memory's clock enable will "protect" it from clock irregularities... unfortunately, the memory is in use nearly full time.

I've received a suggestion to use the PLL for the logic, and use the lock output to drive the memory enable... will have to try that next week. Clock PLL by itself reduced the risk of corruption substantially, but not to zero.

Reply to
cs_posting

Thanks for psting about the problem and the cause. Is this true of all Xilinx parts with BRAM? Is there any plan to "fix" it in future FPGAs?

Can I assume that the ISE post-P&R static timing analysis will generate an error if the BRAM address setup time will not be met? I"m not sure of the limitations of the static timing analysis, but I've never seen any such error reported, so maybe my designs are OK.

Eric

Reply to
Eric Smith

The problem is somewhat exotic. Violating address timing with respect to the clock would obviously always be a disaster when WE is active (You would write data into weird uncontrolled locations). Intuitively one might think that this should not be a problem in read mode, although the data output would of course be garbage. We had one user with asynchronously free-running address sequences, but his system ignored the output most of the time. He ws very surprised when he found the data contaminated. In his case the solution was trivial: Disable the BRAM whenever possible. I do not know about atomatic warnings. A clock is also called a "trigger", and it might be wise to remember the weapons-derived origin... Peter Alfke, Xilinx

Reply to
Peter Alfke

The problem may have been around for many years and several device generations. It obviously was a "sleeper", since nobody detected it, or was bothered by it, in hundreds of millions of working systems. There are no plans to"fix" it, since any change would severely reduce the RAM performance, Violating set-up time requirements just falls into the "don't do that !" category. Peter Alfke

Reply to
Peter Alfke

I detected it and was bothered by it. I eventually found what seemed to be an effective workaround, and moved on. This never got back to Xilinx however, since the local FAEs assumed it was a problem in my design and not in the silicon.

The workaround I discovered was to use a BUFGMUX to disable the clock to the fabric until a certain time after configuration. The DCMs would produce clock glitches during initial lock, and this was killing the ROMs. I also had an ROM integrity check that would cause the entire FPGA to be reconfigured for another attempt if an error was found.

Years later I found out what the problem really was. Now I would just use the enable line instead of the bufgmux.

Regards, Allan

Reply to
Allan Herriman

Allan, the clock glitches alone should not corrupt the ROM content. It also takes address changes coincident with the clock glitches, and moreover the BRAM must be clock-enabled to cause this bad action. So there are several ways around it, and disabling the RAM seems to be the most practical one. I put a warning into the Virtex-5 data book, but I assume it applies to many RAM generations and apparently also of more than one manufacturer, as evidenced by the original posting. This has to be fixed with a warning, for a cure would be worse than the disease... Peter Alfke

Reply to
Peter Alfke

I had the enable permanently on, and the addresses were coming from a FSM triggered by the same clock. Clock glitches due to DCM locking can change the ROM contents in that case.

I agree. It's simple enough to deal with once the root cause of the problem is understood.

My part was a V2P, btw.

Regards, Allan

Reply to
Allan Herriman

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.