DC fifo behaviour at underflow/overflow

We all know that a fifo should operate without getting empty or full. Does

anybody have experience of what sort of output disorder can one expect
when
operating in the wrong state (underflow or overflow).

I am asking that because naturally one thinks of some data samples getting
lost
when a fifo is in this wrong state but I am facing another output pattern
at 
final system output and trying to find a cause. The pattern I get is an 
odd/even offset by some 8 samples in one case or every 8th sample
duplicated in 
another case. For case1 if I realign that stream it gets correct so I am
not 
actually losing samples. The system is too large and remotely tested and
there
is not much room to do any test at the time being. 

I have suspicion of a dc fifo in the path that may enter wrong 
state(underflow/overflow). It is altera dc fifo in stratix iv writing on
~368MHz clock and reading on ~245MHz, 32bits wide and 8 words deep.

Any thoughts appreciated

Kaz	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

"kaz" <3619@embeddedrelated> wrote in message 
news:GLidnQK34ou08lHNnZ2dnUVZ_tGdnZ2d@giganews.com...
> We all know that a fifo should operate without getting empty or full. Does
>
> anybody have experience of what sort of output disorder can one expect
> when
> operating in the wrong state (underflow or overflow).
>
> I am asking that because naturally one thinks of some data samples getting
> lost
> when a fifo is in this wrong state but I am facing another output pattern
> at
> final system output and trying to find a cause. The pattern I get is an
> odd/even offset by some 8 samples in one case or every 8th sample
> duplicated in
> another case. For case1 if I realign that stream it gets correct so I am
> not
> actually losing samples. The system is too large and remotely tested and
> there
> is not much room to do any test at the time being.
>
> I have suspicion of a dc fifo in the path that may enter wrong
> state(underflow/overflow). It is altera dc fifo in stratix iv writing on
> ~368MHz clock and reading on ~245MHz, 32bits wide and 8 words deep.
>
> Any thoughts appreciated
>
> Kaz
>


I would never let a FIFO over or under flow. You should always stop writing 
to the FIFO if the full flag is set and discard the input data stream. If 
the empty flag is set you should not read from the FIFO - instead output 
known dummy data (invariably I output all zero's).

Following this rule the behaviour of the FIFO is  totally predictable.

Andy 

>
>I would never let a FIFO over or under flow. You should always stop
writing 
>to the FIFO if the full flag is set and discard the input data stream. If

>the empty flag is set you should not read from the FIFO - instead output 
>known dummy data (invariably I output all zero's).
>
>Following this rule the behaviour of the FIFO is  totally predictable.
>
>Andy 
>

Thanks Andy. No question that fifo is meant to be working away from
underflow
or overflow. What I am asking is there any known patterns that could
emerge
- after all - within this unpredictibility. Here I am asking about known 
symptoms of wrong behaviour really.

Kaz	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

"kaz" <3619@embeddedrelated> wrote in message 
news:AaydnUTdO7FfE1HNnZ2dnUVZ_iydnZ2d@giganews.com...
> >
>>I would never let a FIFO over or under flow. You should always stop
> writing
>>to the FIFO if the full flag is set and discard the input data stream. If
>
>>the empty flag is set you should not read from the FIFO - instead output
>>known dummy data (invariably I output all zero's).
>>
>>Following this rule the behaviour of the FIFO is  totally predictable.
>>
>>Andy
>>
>
> Thanks Andy. No question that fifo is meant to be working away from
> underflow
> or overflow. What I am asking is there any known patterns that could
> emerge
> - after all - within this unpredictibility. Here I am asking about known
> symptoms of wrong behaviour really.
>
> Kaz
>

Depends how the FIFO is constructed.

If it is as a dual port RAM with an incrementable write pointer on the input 
port, and an incrementable read pointer on the output port then if you fill 
it to full - stop writing - then keep pulling data from the read port it 
will act as a circular buffer with data that will repeat over a number of 
cycles which will equal the FIFO length.

You can work out other scenarios for this architecture yourself, for sure.

Andy

>
>"kaz" <3619@embeddedrelated> wrote in message 
>news:AaydnUTdO7FfE1HNnZ2dnUVZ_iydnZ2d@giganews.com...
>> >
>>>I would never let a FIFO over or under flow. You should always stop
>> writing
>>>to the FIFO if the full flag is set and discard the input data stream.
If
>>
>>>the empty flag is set you should not read from the FIFO - instead
output
>>>known dummy data (invariably I output all zero's).
>>>
>>>Following this rule the behaviour of the FIFO is  totally predictable.
>>>
>>>Andy
>>>
>>
>> Thanks Andy. No question that fifo is meant to be working away from
>> underflow
>> or overflow. What I am asking is there any known patterns that could
>> emerge
>> - after all - within this unpredictibility. Here I am asking about
known
>> symptoms of wrong behaviour really.
>>
>> Kaz
>>
>
>Depends how the FIFO is constructed.
>
>If it is as a dual port RAM with an incrementable write pointer on the
input 
>port, and an incrementable read pointer on the output port then if you
fill 
>it to full - stop writing - then keep pulling data from the read port it 
>will act as a circular buffer with data that will repeat over a number of

>cycles which will equal the FIFO length.
>
>You can work out other scenarios for this architecture yourself, for
sure.
>
>Andy
>
>
>

My crucial point is:
Is there anyway this altera fifo will break up the stream into another
stream 
with even samples ahead of its odd half by 8 samples?

Kaz	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

>
>My crucial point is:
>Is there anyway this altera fifo will break up the stream into another
>stream 
>with even samples ahead of its odd half by 8 samples?
>
>Kaz	   
>					
>---------------------------------------		
>Posted through http://www.FPGARelated.com
>

Let me rephrase the problem. 
It may not be that the presumed fifo problem is a case of
underflow/overflow 
but rather it is a timing problem or both mixed up.

dc fifos protect against metastability to some degree but a failure could
occur.
The cross-domain paths are made false by default understandably. So is't a

case of loss of functionality for some time intermittently that has to be 
accepted. The error stays for several tens of msec then disappears. Don't
we 
expect fifos to recover more quickly(its internal sync pipeline is set to
3).

Kaz
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

On Sat, 15 Dec 2012 09:47:35 -0600, kaz wrote:


>>"kaz" <3619@embeddedrelated> wrote in message
>>news:AaydnUTdO7FfE1HNnZ2dnUVZ_iydnZ2d@giganews.com...
>>> >
>>>>I would never let a FIFO over or under flow. You should always stop
>>> writing
>>>>to the FIFO if the full flag is set and discard the input data stream.
> If
>>>
>>>>the empty flag is set you should not read from the FIFO - instead
> output
>>>>known dummy data (invariably I output all zero's).
>>>>
>>>>Following this rule the behaviour of the FIFO is  totally predictable.
>>>>
>>>>Andy
>>>>
>>>>
>>> Thanks Andy. No question that fifo is meant to be working away from
>>> underflow or overflow. What I am asking is there any known patterns
>>> that could emerge - after all - within this unpredictibility. Here I
>>> am asking about
> known
>>> symptoms of wrong behaviour really.
>>>
>>> Kaz
>>>
>>>
>>Depends how the FIFO is constructed.
>>
>>If it is as a dual port RAM with an incrementable write pointer on the
> input
>>port, and an incrementable read pointer on the output port then if you
> fill
>>it to full - stop writing - then keep pulling data from the read port it
>>will act as a circular buffer with data that will repeat over a number
>>of
> 
>>cycles which will equal the FIFO length.
>>
>>You can work out other scenarios for this architecture yourself, for
> sure.
>>
>>Andy
>>
>>
>>
>>
> My crucial point is:
> Is there anyway this altera fifo will break up the stream into another
> stream with even samples ahead of its odd half by 8 samples?


I saw a DC (dual clock) FIFO do something like that once.  It was in a 
Xilinx part, but the design error would apply equally well to an Altera 
part or an ASIC.


It was part of an IP core that a client had bought.  To make a 64 bit 
wide FIFO, the IP developer had used two 32 bit wide FIFOs in parallel. 
The two FIFOs had independent control circuits.

Of course, as a dual clock FIFO, one can't really make any guarantees 
about the depth immediately after an asynchronous reset when the clocks 
are running, and indeed the two halves of the FIFO would start with 
different depths sometimes.  There was no circuit to check for this state 
and get them back into sync and the end result was until the next reset, 
32 bit chunks of data were swapped around.


Regards,
Allan

On Dec 15, 8:14=A0pm, "kaz" <3619@embeddedrelated> wrote:
> >My crucial point is:
> >Is there anyway this altera fifo will break up the stream into another
> >stream
> >with even samples ahead of its odd half by 8 samples?
>
> >Kaz
>
> >---------------------------------------
> >Posted throughhttp://www.FPGARelated.com
>
> Let me rephrase the problem.
> It may not be that the presumed fifo problem is a case of
> underflow/overflow
> but rather it is a timing problem or both mixed up.

The symptoms look exactly like underflow/overflow.

>
> dc fifos protect against metastability to some degree but a failure could
> occur.
> The cross-domain paths are made false by default understandably. So is't =
a
>
> case of loss of functionality for some time intermittently that has to be
> accepted. The error stays for several tens of msec then disappears. Don't
> we
> expect fifos to recover more quickly(its internal sync pipeline is set to
> 3).
>

According to the dcfifo help, value of 3 is internally translated to
1, which for very high clock rates that you are using is almost
certainly insufficient. Try 4.


> Kaz
>
> ---------------------------------------
> Posted throughhttp://www.FPGARelated.com

Did you pay attention to DELAY_RDUSEDW/DELAY_WRUSEDW parameters?
Altera's default value (1) is unintuitive and, in my experience, tends
to cause problems. If you rely on exact values of rdusedw or wrusedw
ports for anything non-trivial, I'd recommend to set respective
DELAY_xxUSEDW to 0.
I'd also set OVERFLOW_CHECKING/UNDERFLOW_CHECKING to "OFF" and do
underflow/overflow prevention in my own logic.

BTW, personally, I wouldn't use Altera's 8-deep FIFOs, they don't
appear to be as well tested as their deeper relatives. Or, may be,
it's just me.

Many thanks for your contributions.

The fifo I am using is very basic: 32 bits wide, 8 words deep, no reset,
3 stage synchroniser, write and read connected directly(combinatorially)
to
full/empty flags, word count not used, clocks(wr/rd 368/245).

I am trying to put my head deeper into how a fifo might work internally.
Assuming a simplest case, I understand the write pointer is clocked by
write 
clock and it increments on write request (counting is binary or Gray).
The read pointer mirrors that on the read side.

The signals that cross the clock domain are the empty/full flag (in my case

as I am not using the word counts).

What now mystifies me is that if anything went wrong be it flow issue or 
timing then wouldn't these counters just increment from where they might
have 
landed implying self recovery, excluding the case that read pointer is
ahead 
of write pointer (as assumed in my case because samples are read out 
correctly each but misaligned).

I mean to get 8 samples odd/even misalignment I can only think of pointers

going crazy or address arriving crazy but regular.


Kaz



	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

On Dec 16, 12:39=A0pm, "kaz" <3619@embeddedrelated> wrote:
> Many thanks for your contributions.
>
> The fifo I am using is very basic: 32 bits wide, 8 words deep, no reset,
> 3 stage synchroniser, write and read connected directly(combinatorially)
> to
> full/empty flags, word count not used, clocks(wr/rd 368/245).
>
> I am trying to put my head deeper into how a fifo might work internally.
> Assuming a simplest case, I understand the write pointer is clocked by
> write
> clock and it increments on write request (counting is binary or Gray).

Gray.

> The read pointer mirrors that on the read side.
>
> The signals that cross the clock domain are the empty/full flag (in my ca=
se
> as I am not using the word counts).

No, it does not work like that.
The signals that cross clock domains are:
* write pointer - resynchronized variant of it is used in the rdclk
clock domain to generate rdempty and rdusedw
* read pointer - resynchronized variant of it is used in the wrclk
clock domain to generate wrempty and wrusedw

>
> What now mystifies me is that if anything went wrong be it flow issue or
> timing then wouldn't these counters just increment from where they might
> have
> landed implying self recovery, excluding the case that read pointer is
> ahead
> of write pointer (as assumed in my case because samples are read out
> correctly each but misaligned).

Your write clock is faster than your read clock, so, supposedly, your
wrreq has <100% duty cicle, right?
The exact effect of underflow/overflow will depend on specific pattern
applied to wrreq.

You wrote above that wrreq is connected directly to wrfull. Does it
mean that wrreq depends *only* on wrfull or does wrreq logic equation
has some additional terms?

>
> I mean to get 8 samples odd/even misalignment I can only think of pointer=
s
>
> going crazy or address arriving crazy but regular.
>
> Kaz
>
> ---------------------------------------
> Posted throughhttp://www.FPGARelated.com