Sync + FIFO

I am not going to tell you that designing an async FIFO is hard, I hope
this doesn't affect your wizard status.

Bryan

"Bryan" <> wrote in message
news: oups.com...
> I am not going to tell you that designing an async FIFO is hard, I hope
> this doesn't affect your wizard status.

Then face up to his challenge.
If it isn't hard, you should be able to produce the reliable EMPTY-flag
detection and show it works in a couple of hours.

John_H

I believe few reply miss the point in saying that for example you
don't give complex design to new Eng and so on.
Async FIFO can be part of a simple design even as simple as FIFO in
Ethernet Receive Path of 10/100/1000 MAC (There are many more examples
of course) where the difference in clock is due to ppm's but never
the less it require the usage of Async FIFO (though once you understand
how to design one in many of those cases you can do "short cuts"
knowing the actual requirements).

And to the one refer to PLL, last time I learned PLL was Analog devices
and not digital unless you use DLL and such but even than DLL can only
"somewhat" be done using FPGA logic as the delay element are not
"fix" enough, so of course there is limit but to say to new Eng
don't learn how to make Async FIFO just because to design the next
Pentium might be too much for him is in my own opinion a bad judgment.

Obviously each one will guide as he/she find fit but as I see it just
as it is important to explains to new Eng the difference between the
usage of = and <= AND show how even though he should use <= for FF he
can still use = if he pay attention to the order and such the same go
with FIFO, first you explain and teach and THAN you show him
"shortcuts" which can include use of IP done by other.

And by the way as for the simulation feedback there is no reason not to
simulate Async FIFO, a bit more interesting than just one clock domain
FIFO but again not as difficult as design the next mission to mars.

One reason I believe some are "concern/afraid" is luck of
simulation and therefore loss of too much time in the Lab and than
concern that this will happen again.

There is a saying in Asic world that what you didn't test will be the
place where you will find your bug.
Regretly in the FPGA world since mistake do not cost huge sum's to
fix (even for metal fix) Eng tend to only check here and there and not
do good coverage testing.

Sure while in Asic you can spend easily 6 to 9 month testing in FPGA
you are not going to spend this amount of time but never the less you
should cover all major point and if the design is not too big there is
no reason to cover all point.

A good automatic testing using scripts logs memory etc can run and
cover in few days A LOT of your design and save you days and weeks not
to mention once you start building your test environment next time will
be faster and faster and who knows you might stop be warring of
teaching new Eng how to design Async FIFO and other BASIC Digital
design components.

And by the way talking about Xilinx and Metastable etc maybe since
Xilinx have so many Eng you can finally come with FF's that can be
associate to the second FF in the Synconizer so when we run post P&R
simulation we don't need to either play with the sdf or change the FF
to "home made FF" that can prevent X from passing.
And yes due to Metastable you don't know if it will go "too fast"
through and for that you can use $random to give different result when
there is violation.

Have fun and Enjoy the joy of Digital design.

Berty

Berty, let me answer only one paragraph: You wrote
"And by the way as for the simulation feedback there is no reason not
to
simulate Async FIFO, a bit more interesting than just one clock domain
FIFO but again not as difficult as design the next mission to mars."

It is much more difficult than a mission to mars, because a mission to
mars can be done, and has been done. Simulating asynchronous
clock-domain crossing cannot be done, because the number of timing
conditions is, by definition, infinite.
It is not my intent to scare anybody, but asynchronous design is
tricky, and the worst-case conditions are best explored in your head,
not by brute-force computer analysis.
(As far as I know, even SPICE cannot analyze metastability...)
Peter Alfke

Peter Alfke

I already have an async FIFO, but don't claim it takes wizardry to
design one. That would be calling myself a wizard. Anyone that blows
their own horn over FIFO design needs to come back down to earth.

Bryan

Well Bryan, if you have done it already, then you can easily answer my
challenge:

Assume a 1K-address deep FIFO implemented in a dual-ported RAM.
Design only the EMPTY-flag detect circuit that operates reliably at
totally asynchronous write and read clock frequencies of >300 MHz,
and show a test circuit that proves that this operation is reliable.
(Hint: The Virtex-4 BlockRAM does this job at up to 500 MHz worst
case).
Peter Alfke

Peter Alfke

Stop by any time you like and sign an NDA, I think you can figure out
where I am. I will be happy to show you my async FIFO schematic and
why it integrates with higher performance than a coregen type FIFO. I
don't design in VHDL or verilog because I am not a wizard, just an
average engineer.

Bryan

"Bryan" <> wrote in message
news: oups.com...
> Stop by any time you like and sign an NDA, I think you can figure out
> where I am. I will be happy to show you my async FIFO schematic and
> why it integrates with higher performance than a coregen type FIFO. I
> don't design in VHDL or verilog because I am not a wizard, just an
> average engineer.

Average engineers aren't pompous.
Do you even KNOW where the first real async FIFOs came from?

John_H

Then Peter isn't an average engineer. Whats the prize? Wizard hat? I
am always highly skeptical of anyone that claims to be the inventor of
ideas(that sounds pompous). I certainly didn't invent a new FIFO.
Just integrated it into my data path for the highest performance. If
you want to make the challenge tricky then also design the FIFO to
handle variable burst reads from 2 to 10 elements for all combinations
of write and read clock speeds up to the maximum, otherwise it is just
a simple fifo.

Bryan

Peter,
I have no doubt you wrote many FIFO that work ok, and believe it or not
many other Eng did it as well, and even simulate it.

We are all here for the fun and joy of Eng, so Lets not make it a
Contest of who have the bigger ....

A Better approach which I believe will be more suitable and more
education will be since you feel so strongly about the FIFO you design
why don't you write App note or white paper about how it is done so
other Eng that are not aware of how to make Async FIFO will see and
learn and who knows maybe some of us that know how will learn something
new as maybe you have new way, After all there are many way to design
Async FIFO's depend on the requirement and amount of resource
available. (e.g. Phase handler, PPM handler, in high out low, in low
out high, any to any and they can be with and without gray, using
pessimistic approach, and so on and so on).

Back to simulation yes you can simulate Async FIFO even if
theoretically you can have infinite number of condition, since many of
those infinite are the same, just like when you test SONET Frame you
can argue it is impossible since there is infinite number of
combination as each data can be differ gap between frame can be differ,
number of frame can be differ etc, and there are many more examples of
infinite condition which using finite number of test you can verify
very well your design assuming the test bench is done properly.

To give you an idea of one approach is have a script that generate two
value in define file which you later include in your simulation.
So for example the file output can be
`define clk1 19.9
`define clk2 24.9
in one time and in another time can be for example
`define clk1 36.1
`define clk2 10.8
and so on and so on, where the number and resolution depend on what you
want to test (Myself I run all in unix so this file is generated using
unix script, but I'm sure there is a way to do it also in window/dos
or what ever is your platform).

Another parameter which should be randomize is burst of data you write
and how many of them per simulation.
Than you compile all and at the end verify automatically that all work
ok and if so your script start all over.
After one night or what ever depend on how strong is your machine etc
you can cover all the ranges you wanted, as well as maybe some pre
define freq and definition for dedicated tests. Using 1ns/1ps or
1ps/10fs etc can help you get the resolution you need.

The important thing from my experience is once you did all your
dedicated test and verify all to let the $random(seed) work in the
ranges of value you want to cover as well as make sure the test run
automatically just as the verifier so when you run an overnight test
you get large range of coverage.
Of course you should keep all the seed that generate failer in the test
so in the morning you can re-generate the same condition that cause the
failer.

But as always the most important this is Have fun

Berty