B
Bryan
I am not going to tell you that designing an async FIFO is hard, I hope
this doesn't affect your wizard status.
this doesn't affect your wizard status.
J
John_H
Bryan said:
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.
B
Berty
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.
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.
P
Peter Alfke
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
"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
B
Bryan
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.
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.
P
Peter Alfke
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
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
B
Bryan
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.
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.
J
John_H
Bryan said:
Average engineers aren't pompous.
Do you even KNOW where the first real async FIFOs came from?
B
Bryan
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.
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.
B
Berty
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
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
I
info_
Berty wrote:
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
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
P
Peter Alfke
Here is the URL for a FIFO description that I published a few months
ago.
http://www.xilinx.com/publications/xcellonline/xcell_52/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
ago.
http://www.xilinx.com/publications/xcellonline/xcell_52/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
J
John_H
What you ask has already occurred: (see embedded links)
How about:
http://tinyurl.com/aa9or
(http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sGlobalNavPick=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.
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.
Berty said:
How about:
http://tinyurl.com/aa9or
(http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sGlobalNavPick=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.
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.
B
Berty
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.
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.
B
Berty
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.
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.
R
Ronald H. Nicholson Jr.
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.
R
Ronald H. Nicholson Jr.
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.