Sync + FIFO

A

ALuPin

Guest
Hi,

what does have more advantages when trying to synchronize an incoming external
datastream:

1. Synchronize the data bus with some (two or three) register stages
and feed the sychronized data into a FIFO which is an additional
synchronization stage (write clock of FIFO has a different frequency
than the read clock)

OR

2. Feed the data bus directly into the FIFO and synchronize the data coming
out of the FIFO into some (two or three) register stages ?

I am very thankful for any comments.

Rgds
André
 
Just use an "asynchronous" FIFO design which is ideally suited for this
application. It uses a dual-ported RAM to separate the two clock
domains (write and read). And it can also handle the special cases of
EMPTY and FULL. That's where the two clock domains meet and where any
FIFO design gets tricky, We tested our Virtex-4 hard FIFO design (in
every BlockRAM) at 200 MHz write and ~500 MHz read clocking for many
hundred hours without any problems.
Peter Alfke, Xilinx
 
While the idea of using core made by the FPGA companies like Xilinx
Altera etc and while those core if done properly will give not only
good performance but also minimum use of resources I believe in this
case it is a fast solution which will work but a bad one.

Base on the way the question was put I believe the person want to have
asynchronous FIFO however have no knowledge how to do it.

In such case, to use something which was done by other, without the
understanding as how exactly the implementation is done and as such
what the pro and con, mean maybe solving the problem but without
getting the knowledge and understanding.

This is something like telling a new Math student who need to solve 1+1
or 5x7 not how to solve those equations but rather to buy a calculator
....

It might be a better solution if Xilinx have an App note as how to do
it and provide it and only after this Eng learn and understand the App
note and know how to make Async FIFO by himself, than he should use
Xilinx Core or Altera or anyone else for that matter.

Have fun.
 
Berty, I disagree.
While it is good for every young engineer to learn the basic skills,
designing an asynchronous FIFO is far from "basic".
Using a dual-ported RAM makes most of the design trivial, but the EMPTY
and FULL detection and arbitration at high asynchronous clock rates is
far from simple. I have a few patents and several magazine articles,
and Clifford Cummings has published extensively. It is still considered
wizardry, and grown men can get into deep arguments, since this
involves Gray counter decoding and metastability. It is much safer to
use a proven circuit designed by experts. It may sometimes be overkill,
but it works, and lets you spend your energy on the really important
and unique parts of your design.
Peter Alfke, Xilinx Applications
 
As a student that is about to enter the workforce in the US, I find
that I am lacking many of the skills that were mentioned in this
thread. I know what clock domain crossing is and I know that you can
do it with an asynch fifo, but I wouldn't know where to begin in
designing one. This kind of thing is simply not taught in school.
Static timing analysis is also not taught. Honestly strong VHDL isn't
taught either (and Verilog is not taught at all).

So my question to all of those seasoned gurus out there is where did
you learn things like clock domain crossing and static timing analysis?
Did you folks learn these things the hard way (screwing up and having
to pay for it)? Did you take a course? Did you guess your way through
it? I would love to learn these things, but frankly, I don't have a
clue where to start.

You may be asking why a person like me could even think of entering
into a marketplace without those skills, but I do have my other
qualities and my university has a very strong analog circuits program.
Also I have taught myself Verilog and have learned a lot of state
machine things and synthesis things.

Hopefully those in the know can provide information for all of those
students out there like me that don't know about advanced topics and
don't have a resource for learning them and don't know where to begin
looking for a resource.

And my input into this thread. I would say that the Xilinx built in
async FIFOs are going to be faster than hand designed. The reason is
simply that they have dedicated logic. If they are well tested (and
I'm willing to believe they are) and they're faster, then it's hard to
argue for spinning your own. The knowledge may be important (and I
think it is), but if there's a faster, already tested implementation
that is free, my pocket book and my time card are telling me that's the
way to go.

Thanks for the input,
Arlen
 
Arlen -

A good place to start learning about clock crossing and async fifos
is by looking at app notes from companies like Xilinx. Simply
realizing
the problem exists and realizing it is important is a great first step.

Issues in clock crossing are flip-flop metastability, passing
busses of data between domains, and Req/Ack handshaking
between domains.

Metastability is discussed in many papers that you can look for on the
web.
Basically if you violate the setup/hold time on a flip-flop, it's going
to
be angry for a while, ie, potentially in a non 1/0 state. I t may
hover
at an inbetween voltage level, it many oscillate a bit, it may take
longer to settle, etc. You r logic has to deal with this.
Traditionally,
a 2 stage flip-flop chain is considered good enough for this. This
solution depends on clock and data rates!

Passing data/address/counters between domains is trickier. Assume
you send an 8 bit value between domains. Because of delays in
the gates and in routing, each bit of the bus arrives at the target
flip-flops at a **slightly** different time. Because of this
difference,
when the targe clock tries to grab the data, it may latch some old
data and some new data. In a perfect world, all the incoming bits
would arrive at the exact same time and the target flip-flops would
grab ALL of either old or new data. In the real world, the target
flip flops will grab SOME new data and some old. So, if you
are passing fifo address pointers between domains, you have
potential problems in getting correct values at each clock edge.
Solution: look into Gray coded values to pass back and forth. Since
only one bit of a gray counter changes at a time, there is no problem
with the receiving flip flops.

Sending Req/Ack handshake between domains is another area that
can be trickier than one would like. There are efficient ways to do
this,
I'd suggest some Googling as part of your education.

Thought experiments in this area of domain crossing are very
educational.

Clock crossing is one area where you MUST be paranoid. The problems
in general are hard or impossible to simulate and hard to find in the
real world. Since they are semi-random, you can spend a lot of
effort tracking down a problem that only happens once an hour.

I hope this helps!

John P
 
I am not going to tell you that designing an async FIFO is hard, I hope
this doesn't affect your wizard status.
 
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, 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
 
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.
 
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
 
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.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top