FPGA : Async FIFO, Programmable full

Hi In designing asynchronous FIFOs we have to use Gray code read/write pointers.

And while using gray code I know how to generate full and empty flags.

But i would like to get ideas from experienced designers how to generate Programmable full or programmable empty flags

Thanks in advance

rgds bijoy

"bijoy" <pbijoy@rediffmail.com> wrote in message 
news:eea0fde.-1@webx.sUN8CHnE...
> Hi In designing asynchronous FIFOs we have to use Gray code read/write 
> pointers.
>
Well, no, you don't _HAVE_ to. You can use ordinary binary counters just 
fine, as long as you design the clock domain crossing bit properly.
>
> And while using gray code I know how to generate full and empty flags.
>
Perhaps you could share this with the V4 FIFO designers! :-) Sorry Peter!
>
> But i would like to get ideas from experienced designers how to generate 
> Programmable full or programmable empty flags
>
> Thanks in advance
>
> rgds bijoy
>
I use binary counters for my FIFOs. A Google search shows that arithmetic is 
difficult on gray coded numbers.
e.g. http://www.altera.com/literature/an/an083_01.pdf

There may well be a trick other than converting to binary, let us know if 
you find it!
HTH, Syms. 

Symon wrote:

> "bijoy" <pbijoy@rediffmail.com> wrote in message 
> 
>>Hi In designing asynchronous FIFOs we have to use Gray code read/write 
>>pointers.
> 
> Well, no, you don't _HAVE_ to. You can use ordinary binary counters just 
> fine, as long as you design the clock domain crossing bit properly.

But crossing the clock domain with binary counter is hard to do correctly,
it needs some kind of handshake protocol. It's not enough to just put
dual flops to each counter bit like with gray coding.

--Kim

"Kim Enkovaara" <kim.enkovaara@iki.fi> wrote in message 
news:VKSfh.926$8i5.325@reader1.news.saunalahti.fi...
> Symon wrote:
>
>> "bijoy" <pbijoy@rediffmail.com> wrote in message
>>>Hi In designing asynchronous FIFOs we have to use Gray code read/write 
>>>pointers.
>>
>> Well, no, you don't _HAVE_ to. You can use ordinary binary counters just 
>> fine, as long as you design the clock domain crossing bit properly.
>
> But crossing the clock domain with binary counter is hard to do correctly,
> it needs some kind of handshake protocol. It's not enough to just put
> dual flops to each counter bit like with gray coding.

A useful compromise is to have counters in binary, so you can have fast 
arithmetic, and then convert from binary to Gray-code, cross the clock 
domain, and then convert back again to do the pointer comparison. While 
there is some latency, it is usually easier than a bi-directional handshake.

Cheers,

         -Ben- 

You can read these papers by Cliff Cummings on aSynchronous FIFO
design:

http://www.sunburst-design.com/papers/CummingsSNUG2002SJ_FIFO1.pdf
http://www.sunburst-design.com/papers/CummingsSNUG2002SJ_FIFO2.pdf

There is a wrong way and a right way to convert binary to Gray count
values:
The wrong way hangs the (simple!) combinatorial conversion logic (XORs)
on the binary outputs. That does you no good, since the Gray code will
just reflect the binary transient errors.
The right way takes the D inputs of the binary counter (, converts them
independently to Gray and registers them in their own flip-flops. Now
you have two parallel rgisters, both counting in step, the first in
binary, the other in Gray, and there are no funny decoding spikes.
BTW, only Gray counter outputs have the feature that you can compare
two asynchronous counters for identity, without transient errors.
If the Gray code does not come from a counter, it might change multiple
bits per transition...
Fast asynchronous FIFOs with configurable flag values are definitely
not a trivial design exercise. We got it right in Virtex-5, after a
silly oversight in Virtex-4.
Peter Alfke


On Dec 13, 6:31 am, "Ben Jones" <ben.jo...@xilinx.com> wrote:
> "Kim Enkovaara" <kim.enkova...@iki.fi> wrote in messagenews:VKSfh.926$8i5.325@reader1.news.saunalahti.fi...
>
> > Symon wrote:
>
> >> "bijoy" <pbi...@rediffmail.com> wrote in message
> >>>Hi In designing asynchronous FIFOs we have to use Gray code read/write
> >>>pointers.
>
> >> Well, no, you don't _HAVE_ to. You can use ordinary binary counters just
> >> fine, as long as you design the clock domain crossing bit properly.
>
> > But crossing the clock domain with binary counter is hard to do correctly,
> > it needs some kind of handshake protocol. It's not enough to just put
> > dual flops to each counter bit like with gray coding.A useful compromise is to have counters in binary, so you can have fast
> arithmetic, and then convert from binary to Gray-code, cross the clock
> domain, and then convert back again to do the pointer comparison. While
> there is some latency, it is usually easier than a bi-directional handshake.
> 
> Cheers,
> 
>          -Ben-

"bijoy" <pbijoy@rediffmail.com> wrote in message 
news:eea0fde.-1@webx.sUN8CHnE...
> Hi In designing asynchronous FIFOs we have to use Gray code read/write 
> pointers.
>
> And while using gray code I know how to generate full and empty flags.
>
> But i would like to get ideas from experienced designers how to generate 
> Programmable full or programmable empty flags
>
> Thanks in advance
>
Not to put a damper on the thread but I've found that there are probably 
very few applications for true programmable fifo flags inside a programmable 
chip that can be in-system updated like an FPGA.  By 'programmable flag' I'm 
assuming that we're talking about having some register that can be written 
to with some arbitrary number that will cause some associated fifo status 
flag to trigger when it reaches that level.  This arbitrary number is in 
some fashion controlled by software and is not and can not be known a 
priori.

There are applications where I'd like a flag to go off at 'almost full' or 
'almost empty' but those 'almost' conditions have always been able to be 
determined as hard fixed constants.  Maybe those levels are things like 7/8 
or 321/456 or .01 (just making up numbers here) but the point is that the 
point where I want a fifo flag to trigger has (for me at least) always been 
traceable back to known system parameters.  It could be that the trigger 
level is some bizzarro function of those system parameters but the end 
result is a known fixed number so generally what I will do is code the 
bizzarro function into the VHDL that instantiates the fifo to produce the 
constant that will be input as a generic input to the fifo that uses it to 
determine the flag status trigger levels.

True programmable flags where some outside software comes in and actually 
tells the fifo what specific level to trigger at came about back when fifos 
were mostly implemented as discrete parts and the suppliers of these little 
gens of course would have virtually no market for parts that trigger at 
levels like 7/8 or 321/456 or .01 so instead they came up with a mechanism 
to allow the user to program in an arbitrary level...which they did....and 
always (in my experience) did so with some constant that was determined from 
system parameters.

For those applications that fit the cases I've described and really can have 
fixed constants to determine possibly bizzaro trigger levels there is no 
need for any convoluted math or moving gray code to binary to do math.  Your 
gray code counter that keeps track of the depth is a finite state machine, 
there is exactly one state that needs to be matched to see if it corresponds 
to the equivalent of being 321/456 full.

If someone does have an application that really requires true programmable 
flags I'd be interested to hear about it.  The environment though is
- Fifo is inside a programmable part.
- That programmable part can be updated in system.

Presumably this would have to mean that the trigger levels can not be 
determined either empirically at design/design verification time or as a 
function of known system parameters but would (presumably) have to be a 
dynamic function of what is going on in a particular system at a particular 
time (i.e. something unique to the particular system at that point causes 
the software to go 'Woooah, I need to change that fifo trigger level from 
321/456 to 7/8 (or some such)'.

KJ 

KJ wrote:
> 
> If someone does have an application that really requires true programmable 
> flags I'd be interested to hear about it.  The environment though is
> - Fifo is inside a programmable part.
> - That programmable part can be updated in system.

I have many examples from telecom side. For example if you have some universal
interface card, that has each port configurable to different protocol (for
example STM1/4/16). That kind of big change in speed usually needs some changes
in fifo limits to get maximum efficiency. If you have for example 8 ports that
would need quite many different FPGA images to cover static settings. Also
partial reconfiguration in my opinion is little too dififficult way to handle
this problem.

Of course you can code the static values for each protocol and use mux to select
one of them to the fifo comparison logic. But it's easier just to add
one register and let the software to handle the values. Also usually maximum
efficiency needs some lab testing to find the optimal fifo values. And waiting
hours for new fpga after each change in the limits is not fun.

I have used programmable flags so many times in lab while debugging different
problems in the design, and while trying to understand the dynamics how different
limits affect interconnected fifo fystems between chips etc.


--Kim

>There is a wrong way and a right way to convert binary to Gray count
>values:
>The wrong way hangs the (simple!) combinatorial conversion logic (XORs)
>on the binary outputs. That does you no good, since the Gray code will
>just reflect the binary transient errors.
>The right way takes the D inputs of the binary counter (, converts them
>independently to Gray and registers them in their own flip-flops. Now
>you have two parallel rgisters, both counting in step, the first in
>binary, the other in Gray, and there are no funny decoding spikes.
>BTW, only Gray counter outputs have the feature that you can compare
>two asynchronous counters for identity, without transient errors.
>If the Gray code does not come from a counter, it might change multiple
>bits per transition...

<snip />
Whether that is the right answer rather depends on WHY the OP "has" to use
Gray Code, which is still not fully established.

BTW, there is a quite interesting article on Gray Code just posted at:
http://www.pldesignline.com/showArticle.jhtml?articleID=196604078

In an asynchronous FIFO, reading and writing is controlled by two
counters with independent clocks.
If you need to detect FULL or EMPTY, you compare the two counters for
identity.
If you do that with binary counters, you are vulnerable to strange
decoding glitches, while multiple binary bits change (almost, but not
quite, simultaneously). You never have that problem with Gray counters,
where only one bit changes, from one state to the next.
Peter Alfke
=============
RCIngham wrote:
> >There is a wrong way and a right way to convert binary to Gray count
> >values:
> >The wrong way hangs the (simple!) combinatorial conversion logic (XORs)
> >on the binary outputs. That does you no good, since the Gray code will
> >just reflect the binary transient errors.
> >The right way takes the D inputs of the binary counter (, converts them
> >independently to Gray and registers them in their own flip-flops. Now
> >you have two parallel rgisters, both counting in step, the first in
> >binary, the other in Gray, and there are no funny decoding spikes.
> >BTW, only Gray counter outputs have the feature that you can compare
> >two asynchronous counters for identity, without transient errors.
> >If the Gray code does not come from a counter, it might change multiple
> >bits per transition...
>
> <snip />
> Whether that is the right answer rather depends on WHY the OP "has" to use
> Gray Code, which is still not fully established.
>
> BTW, there is a quite interesting article on Gray Code just posted at:
> http://www.pldesignline.com/showArticle.jhtml?articleID=196604078