Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Sync + FIFO

Reply
Thread Tools

Sync + FIFO

 
 
Mike Treseler
Guest
Posts: n/a
 
      04-27-2005
ALuPin wrote:


> The external data stream I am talking about comes form an USB transceiver
> which sends the data synchronous to 60MHz clk which I can use in my FPGA
> as FIFO write clock.


Consider running your FPGA on the same clock.
Maybe you could collect the serial data
and handshake the bus synchronously.

-- Mike

 
Reply With Quote
 
 
 
 
info_
Guest
Posts: n/a
 
      04-27-2005
Berty wrote:
> Peter,
> While I understand your point I'm afraid this is why you see so many
> Eng that know just about nothing except copy paste of IP module.
> Of course Async FIFO is not as simple as shift register. And of course
> it involve some thinking and I would strongly recommend anyone who want
> to design such thing or for that matter any new design to have DR of
> more experience Eng to see how he did what he did and see how to
> improve or fix the wrong.
> I'm fully aware of the Empty Full having designed several FIFO of all
> type and flavor.
> Except for the obvious of the advantage of knowing what you do and
> example as for why you should know to design by yourself can be that
> Some FIFO depend on the implementation when they have one last entry
> will toggle the empty while other will not.
> Sometime this toggle can be more useful however if you know Zilch about
> how the FIFO was design you can do nothing and have to adapt yourself
> to what ever the core give even if this is not the best for the design
> you do.
> And talking about synconizers and Gray counter etc while to use them
> correctly is important this is not rocket science, Sure to give
> complete and full explanation of what Metastable is and the effect of
> it in clear way and not just using "wave hand" explanation can be
> challenging but the actual implementation once you understand the
> meaning of it is not so difficult that one have to pass it aside and
> use other proven code.
> I guess it all boil down to are you an Eng who want to be a copy/paste
> one or are you an Eng who want to know how to do thing and yes ONCE you
> know use other if they make sense, but even for this to tell if it make
> sense you need to understand and not just be another copy/paste-Eng as
> more and more I for one encounter.
>
> And all those who might give example on how they saved money, time etc
> by using other FIFO and not learning how to do it the right way are
> just an example as why you SHOULD learn and not just be copy paste one
> and use this as example to why to use other code.
>
> Back to Math using your own logic is equivalent to say to Eng you
> should learn how to do 1+1 however to do integral of X^2 from 0 to 2 is
> to complex so use calculator, I do hope university will not go with
> this logic and those that do well maybe from there we get all the
> copy-paste Eng's.
>
> Remember that any minute you "Waste" today for learn how to do it
> will pay thousands time in your future, when you have design which are
> not simple and there is no IP and you need to draw from your own
> experience, which if it involve only/mainly copy-paste without the
> knowledge mean you will never become ASIC leader or Architect of new
> complex designs and you will stay basic simple Designer, as no
> knowledge mean poor capability.
>


Interesting post too... however...
I sure am always extremely frustrated when I see people coding in HDL and
not knowing the basics, calling their VHDL code a "program", not knowing
what crossing clock domains is about, etc !

But on the other hand, we are in a competing world, and as a Project Manager
I would be VERY unhappy to see one engineer spend a week trying to write
his own dual clock Fifo and SOMEWHAT scared about the result (through
a synthesis tool in particular). As of what he would learn in the process
(no pun intended) I'm not very sure (verification of such a beast is not
obvious either). And the customer wouldn't see any advantage vs a
design using ready-made Fifo, but he WILL see a tangible advantage if we
spent an extra week implementing new innovative features (for the same budget).

But I sure taught my team all the many tricks I use when designing with FSMs.
We designed our own FFTs, they used to be superior to the vendors' in many
situations, but that's less and less the case, so we drop this know-how
(for FPGA) and we more and more use the standard megafunction.

I would say that there is room in-between these extremes (knowing nothing
and knowing everything)

In our courses, we do our best to teach really solid foundations and
stay focused on the issues that will make a difference between good
and poor design.
To me it's safe enough if the engineer clearly understands the issues,
& knows the principles of what the cores are made of and why, and
knows which to use in each situation.
I'm not sure it's so important anymore to fully understand the RISC
instruction set in the context of SOPC. It's a long time I didn't
code in assembly language.

My opinion indeed...
Thanks anyway for this exchange of views.


Bert Cuzeau
 
Reply With Quote
 
 
 
 
Marc Randolph
Guest
Posts: n/a
 
      04-28-2005
Berty wrote:
> Peter,
> While I understand your point I'm afraid this is why you see so many
> Eng that know just about nothing except copy paste of IP module.

[...]
> Back to Math using your own logic is equivalent to say to Eng you
> should learn how to do 1+1 however to do integral of X^2 from 0 to 2

is
> to complex so use calculator, I do hope university will not go with
> this logic and those that do well maybe from there we get all the
> copy-paste Eng's.

[...]

And where do you stop? By your own logic, they can't just stop at
doing integrals. You need to know how to derive all the integral
short-cuts that you use, for fear that someday while waiting for a bus,
someone holds a gun to your head and makes you re-derive the integral
of sin(x)dx. But you can't stop there either - you have to move on to
differential calculus and partial differential equations. But that's
not all, then you need to... (etc)

Moving back to the electronics world, how about other components in the
FPGA (or an ASIC)? Before I can use the PLL or CDR within the Rocket
I/O, should I understand it so well that I could design one myself?
What about the DCM? Do I need to be able to design my own latch-up
resistant, ESD protected, discrete input and output buffers before I
can use an ASIC vendors' IO cell? What about the optical transceiver
that I connected to the Rocket I/O - do I need to know exactly how the
pin diodes and laser drivers work before I can use an optical
transceiver?

Everyone is going to draw the line in different spots, based upon their
needs. Not everyone wants or needs to specialize in FIFO design. If
you can do it, great - it gives you a slight competitive advantage for
a few jobs out there (or turn it into a life-long job, as Peter has).
But that alone does not indicate

Having said all this, however, I have to agree with some of the
underlying points upon which you've placed your FIFO example... that
engineers need a firm understanding of the basics so that when they are
called upon to design something, they know where to start. Even more
importantly, they understand the limits of their knowledge, and if
necessary, know how to educate *themselves* further on the topic,
without much outside help. That's the true sign of an engineer - not
if they can design an async FIFO.

Have fun,

Marc

 
Reply With Quote
 
Peter Alfke
Guest
Posts: n/a
 
      04-28-2005
Well, I did design FIFOs,and in particular the asynchronous arbiter in
the Virtex-4 BlockRAM FIFO ( and the test methodology for it), and I
measured asynchronous behavior and metastable recovery. But these were
major efforts, and were based on many decades of design experience.
Xilinx can afford such exploration since we expect that many of our
customers will eventually benefit from it...
It's just not what you should entrust a junior engineer to do.
Let them grow up with synchronous logic, and carefully graduate to data
transfer across clock boundaries later. When you cannot simulate, you
really need to be both experienced and confident
Peter Alfke

 
Reply With Quote
 
Bryan
Guest
Posts: n/a
 
      04-28-2005
I think you highly under estimate the average engineer. I believe this
is because you only deal with people that can't get their designs to
work. There are a lot more out there that never need help and you
never hear from them. I would hate to think what engineers are
designing logic that can't design an async FIFO(actually I know one,
see bleow). My experience has shown that cut and paste does not
provide the best performance, it may provide the best time to market as
pointed out. When performance is more important than time to market
you design everything yourself and highly optimize it. Apparently you
only work with some below average junior engineers. We did have a
senior senior engineer that couldn't design his own async FIFO, just
goes to show there are below average people at all levels. That is the
same type of mentality that would not hire a person with less than 5
years experience. I hope the people with that mentality end up with
senior senior on their team.




Peter Alfke wrote:
> It's just not what you should entrust a junior engineer to do.


 
Reply With Quote
 
Peter Alfke
Guest
Posts: n/a
 
      04-28-2005
Well, Bryan, here is a test for a smart engineer:
Assume a 1K-address deep FIFO ( data width does not matter) 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 With Quote
 
johnp
Guest
Posts: n/a
 
      04-29-2005
Bryan -

Maybe I'm jaded since I'm a consultant, but a lot of engineers just
don't
understand subtle issues like clock domain crossing. I've had to clean
up so many bugs in this area that I can't count them all. Just when
you think
you've seen every way to send signals between clock domains
incorrectly,
a new way is invented.

Same comments on signal integrity issues. Too many designers still
think
the world is only 1's and 0's. Reflections? Crosstalk? What are
those?

Sorry for the minor rant, but if Xilinx can make async fifos easier,
maybe
the average designer can make reliable designs.

Yes, for custom case, you can may be able to create a smaller, more
optimized
design for a specific application, but for some engineers there effort
may be
better spent on the core of their design rather than re-creating a low
level
design block.

Peter - thanks for all the great input you have in this newsgroup!

John P

 
Reply With Quote
 
Bert Cuzeau
Guest
Posts: n/a
 
      04-29-2005
johnp wrote:
> Bryan -
>
> Maybe I'm jaded since I'm a consultant, but a lot of engineers just
> don't
> understand subtle issues like clock domain crossing. I've had to clean
> up so many bugs in this area that I can't count them all. Just when
> you think
> you've seen every way to send signals between clock domains
> incorrectly,
> a new way is invented.


We are a Design house plus we train about 300 engineers per year,
and I have exactly the _same_ experience a Bryan.

And what I see in the newsgroup doesn't tell me that every engineer
writing VHDL does it with a clear understanding of these issues and
of their solutions. I can only say for France, but here, the language
and Electronic Design is very poorly taught even in the most
prestigious Engineering schools (they don't even teach what Static
Timing Analysis is !). We train lots of young engineers, and they
have all the same feedback and stories.

In our consulting business we sometimes do kind of "PostMortem"
on designs that fail miserably, and the issues end up having a
very basic cause. Sort of 80-20 here too : 80% of the failures
have a very low complexity reason and could be avoided by
simple rules. The reason of failures (respins) in Asic design
as reported year after year by Synopsys seem to say as much
(with better figures, since beginners are not allowed here).

Another point I see is personal satisfaction.
It's rewarding to create a complex working system in a small
FPGA in a few days or weeks. It's no so satisfying to laboriously
recreate an inferior version of something done by others and
freely available. That's why, in our Educational Kit, I try to
set up fancy exercises and stay away from Trafic Light Controllers.
I think it's more fun to drive a thermometer chip, an LCD,or read
a Smart Card, or create a UART, and not much more complex.

Bert Cuzeau

 
Reply With Quote
 
gallen
Guest
Posts: n/a
 
      04-29-2005
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

 
Reply With Quote
 
johnp
Guest
Posts: n/a
 
      04-29-2005
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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
any body having complete code for synchronous fifo or know a link where fifo codes are available plz help chaitu VHDL 1 06-01-2007 07:03 PM
any body having complete code for a synchronous FIFO or know a link where FIFO codes are available chaitu VHDL 1 06-01-2007 03:45 AM
any body having complete code for a synchronous FIFO or know a link where FIFO codes are available chaitu VHDL 1 05-31-2007 03:31 PM
any body having complete code for a synchronous FIFO or know a link where FIFO codes are available chaitu VHDL 0 05-31-2007 02:28 PM
sync.rb difference between Sync::UN, Sync::EX and Sync::SH Trans Ruby 2 12-12-2005 02:43 PM



Advertisments