Sync + FIFO

Berty wrote:


> 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).

Berty,

How do you handle the case of timing violations in timing simulations ?
It's usually difficult, and I remember having used VHDL configurations
to turn FlipFlops with timing models into models that do not propagate
X'es while performaing multiple clock domains timing simulation
(and the validation then becomes nil wrt timing violation).

In other words, I naively thought timing simulation wasn't the right tool
to validate asynchronous design, if only because of the "worst case only"
timing models, no MonteCarlo methods etc... I was more confident in
a human expert mind than on a timing simulator based on timings that
do not exist in the design.

I'm sure I'm going to learn something here (I'm NOT an asynchronous
design expert)

And I'm not ashamed to say that I am happy experts like you design the
asynchronous for me and let me focus on higher level issues :-)

Bert Cuzeau

Here is the URL for a FIFO description that I published a few months
ago.

http://www.xilinx.com/publications/...xc_v4fifo52.htm

But back to simulation:
I have tested metastability in our flip-flops, and I found that the
metastability-catching timing window has a width of
0.07 ns for a metastable-caused delay of 1 ns
0.07 femtoseconds for a metastable-caused delay of 1.5 ns.
For every extra half ns of delay, the window becomes a million times
smaller.
For a 2-ns delay you have to hit a timing bulls-eye of 10e-22 seconds.
Please tell me how you can simulate that...
Peter Alfke

What you ask has already occurred:  (see embedded links)

"Berty" <wooster.berty@gmail.com> wrote in message
news:1114809109.736832.199490@z14g2000cwz.googlegroups.com...
> 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).

How about :

http://tinyurl.com/aa9or
(http://www.xilinx.com/xlnx/xweb/xil...vPick=SUPPORT&s
SecondaryNavPick=&category=&iLanguageID=1&multPartNum=1&sTechX_ID=pa_fifo)

Or maybe:

http://www.eetimes.com/editorial/2000/design0003.html

"In 1970, Alfke invented the first FIFO integrated circuit, the Fairchild
3341"

This individual has made a career out of helping other engineers and it
seems there are some here who don't RESPECT what this man has done for the
average FPGA designer or UNDERSTAND his contributions across the last 4
decades.

I, for one, appreciate the whitepapers and articles contributed outside the
forum, the general help inside therse forums, and the contributions to the
industry as a whole.  Honestly, I don't understand the level of disrespect I
see in this conversation.  I never quite understood why "flaming" was such a
big issue on the usenet because I've stayed away from the less professional
venues.  Here I expect people to have a little homework under their belt
before making disparaging comments toward someone who KNOWS his business.



> 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

Having fun *is* important.  I appreciate the comments that may help others
explore the subject further and the insights you have into design and test.
But there are people who actually "are" experts out there.

My apologies, Berty, if it seems I'm coming across strong against *your*
post since it's more Bryan's comments that disturbed me, but those
whitepapers and App Notes ARE out there.

First personal opinion I don't generally like the word expert or
average or what ever. The fact someone did something in the past not
make him expert just as the fact if someone design dozen of chip's
don't make him an Asic Guru.
The only thing it does make one is have experience which a new designer
should listen to but as always with a bit of skepticism as even the
most experienced Eng can be wrong and even if not the newer Eng might
have better idea.

As for Async topic, the first step to simulate any clock domain
crossing is to have FF that are not just reg which you put in always @
(posedge ... but one with timing referance.

What I would suggest as first step is write something very simple with
clock crossing even a simple req/ack which is done in full handshake
something which is very simple, and than synthesis and place and route
it.

Once you have the post place and route netlist if you look on assume
you use xilinx the abc_timesim.v or if you use altera it will be abc.vo
you will see that the FF's are now coming from xilinx or altera
library file/directories, More over there is time overwrite in the sdf
file they both generate.

If now you will simulate your design you will have FF that have setup
and hold timing requirement to met and failing to do so will generate
"x" which is what you actually want to test and simulate.

Of course you can argue that this don't cover all the timing issue
but only catch some of them meaning let say the setup/hold is total of
2n compare to 20n period than you might argue that not all the 2n are
checked but for that I will answer that this is not important as the
important thing is to hit this time frame and get the X and see that
your system handle it properly.

Just like when you test a counter that can count up to let say 100 you
verify the 0 the 100 the freq on high and low but even if the counter
is for let say 100M you are not testing it for ALL freq from 0Hz to
100MHz so 0.00000...01 Hz and than 0.000000...02 Hz and so on.

Later on you can write your own FF with whatever timing you want and
optimize it to what ever you want to test.

The big drawback in using post place and route as you probably aware is
time, those simulation run much slower compare to the code you wrote
however even in very large design the relative size of the cross domain
part is very small and so a good approach is have quick test of this
part separately and only when happy move to simulate the complete
design.

This don't come to tell Spice simulation are not needed of course
they do but they are needed to verify the operation and characteristic
of the FF itself inside the FPGA (or the Asic for that matter) the
digital designer can rely on the above and not go into the Spice
modeling if he assume which is a reasonable assumption that those FF
was tested by the vendor and that the timing characteristic etc are
giving properly in the library files.

As for the URL for the FIFO in Xilinx site, while it is very nice
article with lots of color, unless I miss something it is basically
useless and the reason I say it is that as I see it good article
explain the theory and when it refer to "basic staff" which FIFO is
one of them it should be such that a new Eng that know how to write
code will be able to make the design base on this article and I believe
this is not the case with this article, and regretly this is true to
too many article out there.

Some how I got the feeling long ago that many time Eng believe they
have great design and want to tell everyone about it but on the same
time are concern someone will know how they did it so the write it in a
way you get some idea but not the whole solution, and for me unless we
are talking on break through technology where one is going to write
patent it is simple mean a very poor article which don't benefit the
Eng groups, and as a whole don't even benefit the writer as if the
complete detail was to be given, MAYBE someone would come with
enhancement that would make the design even better.

Many years back I had to design my first design that require a CRC and
at that time I tried to find answer to how it work how it was done and
so on.
All I found was few article that talk about the idea and general
abstract as how to do it but with no real implementation until after
some more research I finally found one article which show exactly how
it should be done, sure it was for only one bit of data but after this
article I had the path and could expand it to more bit as I needed.

The first articles I would probably give mark from poor to excellent
but they was all what I refer as "university articles", the last
one probably would get a C grade in the university but it got A from me
as Eng. Finally for the first time I not only understood what and why
but also the how, sure math equation are great but it might not be so
straightforward to figure from them that all you really need at the end
are some Xor's and FF's at least it was not clear to me at that
time.

Back to the Article and this tread I saw mention to the some difficult
empty have but for example I didn't saw any mention as for how it is
done in the URL (if I missed it do let me know where it mention as I
went through it quickly) and assume there was indeed no explanation to
how it was done than what does this article add to the Eng knowledge
base expect few more papers.
On the other hand if there is clear explanation and if this article is
such that new Eng can take it and write its own Async FIFO than there
is a reason and justification for this article.

No need to apologize the whole issue as I see it, is that if someone
have question we should try to give as much answer so he can use it and
not just vague detail.
We are here for the fun so lets not make it a competition of who did
more, as it serve nothing.
If someone is very knowledgeable and give answers to all difficult
question Eng in this group or any other group community etc will know
he is knowledgeable and no need to go and say "I'm" or "can you
do this and that" as it only bring "the bad out of us" instead of
the good.

And again FIFO while have its own complication is not something that
should be put aside or consider as "black magic" like EMI.
IF you are new designer the leader of your group will not give you huge
design and if there is Async FIFO he will no doubt check your design so
go ahead and try and learn so when you are the leader you know how it
is done and can teach the next gen of Eng.

Take a moment and think how long it will take you as someone who knows
how to design Async FIFO to teach someone knew the idea and concept as
well as the drawback. No need to do it for all flavor of FIFO's
enough to go with one as a start. Let say it will take you a whole day
(again I refer to the digital part without going into the physics of
the Metastable etc) than next FIFO will be 4 hour and nextw ill be 2
hour and before you know this Eng know how to design Async FIFO and
give better productivity as he is no more one more in the herd of IP
copy/paste Eng's.

Sure if the Async FIFO is deep enough and the freq is high enough you
might have eventually to do also some hand placement and you might
figure let use the vendor IP or any other reason but this should not be
in my opinion the first solution when it come to BASIC block of the
digital design.
On the other hand if you look for let say PCI and don't want to get
into understand how the PCI work than go ahead and use the IP core for
PCI but PCI is not BASIC block of digital design and this is the main
difference.

In article <1114556692.455174.18400@f14g2000cwb.googlegroups.com>,
Peter Alfke <peter@xilinx.com> wrote:
>Berty, I disagree.
>While it is good for every young engineer to learn the basic skills,
>designing an asynchronous FIFO is far from "basic".

I realize your credentials, but I will still have to disagree.

Asynchronous boundary crossings are even more common these days than
in previous decades (systems supporting a plethora or protocols and
standards, chips so big and fast that signals can't even cross it in one
clock cycle, etc.), and dealing with clock domain crossings needs to be
part of the basic toolkit of almost any competent digital design engineer.
If a system requires an async FIFO, there is a reasonable probability
that there are other async crossings involved.  An engineer who doesn't
understand the basic problem and solution space will possibly screw-up
somewhere other than the FIFO, especially if he/she doesn't even have
a basic understanding of even how to solve and not solve the problem
using at least some form of simplified logic structures.

Now if you want to do analog circuit design of full-custom ASIC flip-flops
to tweak the the metastability window a few picoseconds smaller at the
same statistical certainty level, I'll agree that that may no longer be
a basic skill.


IMHO. YMMV.
--
Ron Nicholson   rhn AT nicholson DOT com   http://www.nicholson.com/rhn/
#include <canonical.disclaimer>        // only my own opinions, etc.

In article <1114818211.545915.148920@o13g2000cwo.googlegroups.com>,
Peter Alfke <peter@xilinx.com> wrote:
>But back to simulation:
>I have tested metastability in our flip-flops, and I found that the
>metastability-catching timing window has a width of
>0.07 ns for a metastable-caused delay of 1 ns
>0.07 femtoseconds for a metastable-caused delay of 1.5 ns.
>For every extra half ns of delay, the window becomes a million times
>smaller.
>For a 2-ns delay you have to hit a timing bulls-eye of 10e-22 seconds.
>Please tell me how you can simulate that...

One engineering rule is that "there is no such thing a digital".  You
seem to understand that.  Digital logic is just a simplification of analog
electronics used well away from thresholds.  But another, more subtile
rule is that "there is no such thing as analog".  At 10e-22 seconds
you are closer to the limits of electrical and thermal noise, maybe
even quantum uncertainty.  Neither standard Spice, nor an event-driven
simulator will do.  You will need do a statistical analysis.

So you need to define "reliable" at some statistical level.  Before
throwing out a long string of nine's for your desired synchronizer failure
rate, you also might want to ask about thermal noise, ground noise, EMI,
crosstalk, environmental and package radiation, latent process faults
which passed chip test, solder reliability, etc. etc. and how those
might affect your total system failure rates.


IMHO. YMMV.
--
Ron Nicholson   rhn AT nicholson DOT com   http://www.nicholson.com/rhn/
#include <canonical.disclaimer>        // only my own opinions, etc.