FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > FPGA

FPGA comp.arch.fpga newsgroup (usenet)

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 11-09-2007, 03:19 PM
Guest
 
Posts: n/a
Default 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 With Quote
  #2 (permalink)  
Old 11-09-2007, 07:58 PM
Guest
 
Posts: n/a
Default Re: ROM (altsyncram) corruption

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.


>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 With Quote
  #3 (permalink)  
Old 11-09-2007, 08:32 PM
Guest
 
Posts: n/a
Default Re: ROM (altsyncram) corruption

On Nov 9, 2:58 pm, [email protected] wrote:
> 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".


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 With Quote
  #4 (permalink)  
Old 11-09-2007, 10:37 PM
Symon
Guest
 
Posts: n/a
Default Re: ROM (altsyncram) corruption

<[email protected]> wrote in message
news:[email protected] s.com...
> On Nov 9, 2:58 pm, [email protected] wrote:
>> 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".

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

FYI, some of Xilinx's RAMs have a similar (maybe the same?) problem.
http://www.xilinx.com/support/answers/21870.htm
HTH., Syms.


Reply With Quote
  #5 (permalink)  
Old 11-10-2007, 12:38 AM
Peter Alfke
Guest
 
Posts: n/a
Default Re: ROM (altsyncram) corruption

On Nov 9, 2:37 pm, "Symon" <[email protected]> wrote:
> >

> FYI, some of Xilinx's RAMs have a similar (maybe the same?) problem.http://www.xilinx.com/support/answers/21870.htm
> HTH., Syms.


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 With Quote
  #6 (permalink)  
Old 11-10-2007, 01:59 AM
Guest
 
Posts: n/a
Default Re: ROM (altsyncram) corruption

On Nov 9, 7:38 pm, Peter Alfke <[email protected]> wrote:

> 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?


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

> 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.


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 With Quote
  #7 (permalink)  
Old 11-10-2007, 06:05 AM
Eric Smith
Guest
 
Posts: n/a
Default Re: ROM (altsyncram) corruption

Peter Alfke wrote:
> 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.


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 With Quote
  #8 (permalink)  
Old 11-10-2007, 06:34 AM
Peter Alfke
Guest
 
Posts: n/a
Default Re: ROM (altsyncram) corruption

On Nov 9, 10:05 pm, Eric Smith <[email protected]> wrote:
> Peter Alfke wrote:
> > 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.

>
> 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


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 With Quote
  #9 (permalink)  
Old 11-10-2007, 06:43 AM
Peter Alfke
Guest
 
Posts: n/a
Default Re: ROM (altsyncram) corruption

On Nov 9, 10:34 pm, Peter Alfke <[email protected]> wrote:
> On Nov 9, 10:05 pm, Eric Smith <[email protected]> wrote:
>
> > Peter Alfke wrote:
> > > 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.

>
> > 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

>

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

> 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 With Quote
  #10 (permalink)  
Old 11-11-2007, 01:26 AM
Allan Herriman
Guest
 
Posts: n/a
Default Re: ROM (altsyncram) corruption

On Fri, 09 Nov 2007 22:43:51 -0800, Peter Alfke <[email protected]>
wrote:

>On Nov 9, 10:34 pm, Peter Alfke <[email protected]> wrote:
>> On Nov 9, 10:05 pm, Eric Smith <[email protected]> wrote:
>>
>> > Peter Alfke wrote:
>> > > 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.

>>
>> > 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

>>

>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.


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 With Quote
  #11 (permalink)  
Old 11-11-2007, 01:59 AM
Peter Alfke
Guest
 
Posts: n/a
Default Re: ROM (altsyncram) corruption

On Nov 10, 5:26 pm, Allan Herriman <[email protected]> wrote:
> On Fri, 09 Nov 2007 22:43:51 -0800, Peter Alfke <[email protected]>
> wrote:
>
>
>
> >On Nov 9, 10:34 pm, Peter Alfke <[email protected]> wrote:
> >> On Nov 9, 10:05 pm, Eric Smith <[email protected]> wrote:

>
> >> > Peter Alfke wrote:
> >> > > 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.

>
> >> > 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

>
> >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.

>
> 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


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 With Quote
  #12 (permalink)  
Old 11-11-2007, 02:26 AM
Allan Herriman
Guest
 
Posts: n/a
Default Re: ROM (altsyncram) corruption

On Sat, 10 Nov 2007 17:59:40 -0800, Peter Alfke <[email protected]>
wrote:

>On Nov 10, 5:26 pm, Allan Herriman <[email protected]> wrote:
>> On Fri, 09 Nov 2007 22:43:51 -0800, Peter Alfke <[email protected]>
>> wrote:
>>
>>
>>
>> >On Nov 9, 10:34 pm, Peter Alfke <[email protected]> wrote:
>> >> On Nov 9, 10:05 pm, Eric Smith <[email protected]> wrote:

>>
>> >> > Peter Alfke wrote:
>> >> > > 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.

>>
>> >> > 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

>>
>> >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.

>>
>> 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

>
>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.


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.

> 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...


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 With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
LocalLink TEMAC Data Corruption morphiend FPGA 4 06-06-2007 12:17 PM
Virtex-4FX embeded MAC and Rocket-IO data corruption?? Marc Kelly FPGA 9 06-20-2006 08:22 PM
Virtex 4 FIFO16 blocks - Corruption ? Sylvain Munaut FPGA 18 12-07-2005 03:23 AM
Altera's altsyncram MAXIMUM_DEPTH Peter Sommerfeld FPGA 11 12-09-2003 10:16 PM


All times are GMT +1. The time now is 09:40 AM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved