FPGA : Async FIFO, Programmable full - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: FPGA : Async FIFO, Programmable full
Yes, one can do "ptrA == ptrB" directly in gray... but if I want to do
"ptrA - ptrB" to know how much headroom I have, it does not work quite
as nicely, this does require G2B conversion.

For a gray implementation, it is probably preferable to generate a
straight gray counter and convert that to linear binary for local use to
avoid combinational paths and routing between the counter's registers
and the other domain's resync registers since it increases the risk
transcoding glitches (path delays + non-existing phase relation + ...)
getting through. With a binary counter, the gray conversion must be
registered on the local clock before resyncing to the other clock.

In any case, the most important point of any design always is: it has to
work.

Peter Alfke wrote:
Quoted text here. Click to load it

Re: FPGA : Async FIFO, Programmable full
Let's leave it at that. We won't agree, but then: we do not have to...
Peter Alfke
BTW, Google lists over 1000 patents on FIFOs.
A few of them are mine, but I could not believe the total number...

wrote:
Quoted text here. Click to load it


Re: FPGA : Async FIFO, Programmable full
Quoted text here. Click to load it

To agree, there would need to be an argument to agree on in the first
place. Since I was only proposing an alternative way of going about
pointer data domain crossing, the only thing possibly worth arguing over
is whether or not the approach is valid... and since I have used this
approach in an ASIC project, I have reasonable proof that it is.

Is it the best implementation? That answer is application-specific.

Quoted text here. Click to load it

The wheel has been patented a few times as well, there are way too many
duplicate, obvious and useless patents out there, it makes finding truly
relevant stuff an extremely tedious task.

 From what I have seen in FIFO patents, they suffer from the same
redundancy and irrelevance as other patents: they reinvent multi-bits
signal domain crossing, not FIFOs themselves. All claims beyond that are
frivolous at best - once the cross-over is done, everything beyond that
is easily 20+ years old common knowledge.

I am very much surprised to see that some async FIFO patents are under
10 years old... the gray code and DP-SRAM or register file FIFO combo is
much older than that AFAIK.

Quoted text here. Click to load it

Re: FPGA : Async FIFO, Programmable full
For what it is worth:
I designed the very first FIFO integrated circuit, the Fairchild 3341
in 1969/70. It was very popular for a while. But Fairchild did not
patent it.
Peter Alfke

wrote:
Quoted text here. Click to load it
agree, there would need to be an argument to agree on in the first
Quoted text here. Click to load it
has been patented a few times as well, there are way too many
Quoted text here. Click to load it


Re: FPGA : Async FIFO, Programmable full
I wonder if I should be jealous... on one hand, you got to do one-man IC
designs while on the other hand, the function alone is useless. All I
will ever see on the ASIC side is my functions representing only a
fraction of some 10M+ gates design.

Well, I suppose you probably envy younger designers for having access to
programmable logic from the very start... but that's probably offset by
the pride of having a hand in making FPGAs a reality for the rest of us :)

Peter Alfke wrote:
Quoted text here. Click to load it
agree, there would need to be an argument to agree on in the first
Quoted text here. Click to load it

Re: FPGA : Async FIFO, Programmable full
The big difference, for better or worse, is that, in the olden days,
you could, and you had to, understand everything down to the minutest
details. Whether it was building vacuum tube radios in the 'fifties,
leading a small group to design data processing equipment, and
re-invent germanium-transistor circuitry, core-memory drivers and
ultra-slow mag-tape radback in the 'sixties. Even as late as 1988, I
had the "pleasure" of completely taking apart and re-writing the Xilinx
data book. Pain and agony, but also the joy of tangible achievement.
Nowadays, the jobs are usually so complex that nobody can understand,
let alone create, the whole system. There is no way I could re-write
our product documentation. Too many words, too many specialties, and
too many fiefdoms.
On the other hand, the tools are now so incredibly more powerful that
jobs which almost killed us then, have now become trivial.
Who remembers looking for once-a-minute transient events on an analog
scope? Darken the room, and glue you face, pupils wide open, to the
Tektronix screen...

It's not a question of pride or envy, it is just dramatically differnt.
But, thank God, certain principles just carry over...
Peter Alfke

wrote:
Quoted text here. Click to load it
agree, there would need to be an argument to agree on in the first
Quoted text here. Click to load it


Re: FPGA : Async FIFO, Programmable full
Quoted text here. Click to load it
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



Re: FPGA : Async FIFO, Programmable full
Quoted text here. Click to load it

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

Re: FPGA : Async FIFO, Programmable full

Quoted text here. Click to load it
select
Quoted text here. Click to load it
different
Quoted text here. Click to load it

Having a single fifo with (in your case) 8 different flags come out at
those 8 different fill levels would accomplish the same thing.  The
only thing that needing muxing would be the 8 different flags not 8
entire fifos.  Software would write to a register which would select
one of the 8 pre-defined constants.

At some point though the logic required to generate an arbitrary number
of flags that are comparisons of the fill level to a set of fixed
constants becomes greater than the cost to compare the fill level to a
programmable register.  At what point that you cross that threshold
depends on the number of bits in the counter, but in the cases where
I've run across it was cheaper (in logic) and faster in performance to
do the multiple comparisons and select but that was with 4 sets of fill
levels....8 choices might just push you over.

I agree that lab testing to empirically find those optimal values can
be a pain when it means an FPGA rebuild but once beyond that and the
optimal values determined they usually tend to stay set in concrete.
Hard coding them in at that point would tend to give you less logic and
better performance (again, how much depends on the counter size).

Good example.

KJ


Site Timeline