Sync + FIFO

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.

Reply to
John_H
Loading thread data ...

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

Reply to
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

Reply to
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.

Reply to
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

Reply to
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.

Reply to
Bryan

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

Reply to
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.

Reply to
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

Reply to
Berty

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

Reply to
info_

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

formatting link

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
Reply to
Peter Alfke

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

How about:

formatting link

Or maybe:

formatting link

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

Reply to
John_H

That just means if he didn't work for fairchild back then it would have been Bob Smith that put the first FIFO to IC. That line convinces you he was the first person to invent a FIFO?

Fairchild

Reply to
Bryan

Nowhere did I claim that he was the first person to invent a FIFO. There appear to have been some discrete implementations as discussed a few years ago on this newsgroup. Fortunately during that discussion, people regarded accomplishment and years of expertise as worth something.

You appear to claim that "anyone" can design a bulletproof asynchronous FIFO and that anyone who believes that the discipline is difficult is trying to pull the wool over other engineers' eyes to make themselves look "holier than though."

Well, though art thick.

Accomplished. Published. Insightful. Helpful.

What are you?

Reply to
John_H

Brian, you are really getting obnoxious when you write about something you do not understand. Yes, the FIFO-IC was my original idea, and I cajoled Fairchild management for a whole year to let me design it, because I thought it would become a good product, but Marketing had a hard time understanding. The 3341 became very successful, and later was second-sourced by AMD. And there had never been an integrated FIFO before it.

It may be difficult for you to understand, but many products can still be born out of one person's idea, conviction, and drive. And one person can make a difference. I hope you also will do some time... Peter Alfke

Reply to
Peter Alfke

The original generalization should have read as follows: Designing an Async FIFO may prove too hard for some junior engineers. Not a blanket statement that designing one is not to be entrusted to junior engineers. That implies that "anyone" who is a junior engineer cannot design an async FIFO(and bulletproof is always implied). So I would say he is just as thick.

Reply to
Bryan

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.

Reply to
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.

Reply to
Berty

Hi,

I think you guys have scared Andre away(how do you do that tick mark on top of the e?). I havn't seen him in this discussion since he first started this thread.

I'm currently working on my senior design project and came accross this thread. I'm not sure what's all big hoopla is all about? I've actually have an ASYNC FIFO in my design. The design is targeted for a Spartan eval board. I've decode my EMPTY flag off the read clock and the FULL flag off the write clock using grey-code counters. Targeting a Xilinx device with clock buffers will minimize clock skew. My design seemed to be running fine. It took me about a day to come up with this design. Are there more to it than what I have done?

If I had ran acrross this thread sooner, I dont think I would have tried to do the design myself. With all the expert opinions on how hard all of this is, I would have been scared to attempt it myself. Maybe my design was not done correctly. I would be happy to send my schematics to you guys for reviews.

So when I graduate from school, I'm sure my title will have "junior engineer" in it. I will definitely wait until I get promoted to senior engineer before I attempt to do my first ASYNC FIFO. Seemed like my best bet is to go ahead and cut and paste from one of Xilinx already proven design. Would I have to learn VHDL now too? Does Xilinx have a schematic version?

Reply to
tom

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         // only my own opinions, etc.
Reply to
Ronald H. Nicholson Jr.

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.