Uninitialized reg in simulation vs. synthesis

[tggzzz]

The other reason is that an async reset is, um, asynchronous. Hence there is the possibility that the releasing the reset won't meet a register's setup and hold times, which might lead to behaviour that depends on the device/temperature/phase of moon.

There is a place for asynchronous logic, but those with a solid base in theory will know that it is extraordinarily difficult to get correct - and even then "correctness" presumes that only one input changes at any one time (which is unrealistic except in synchronous logic!).

And the problem is not the async reset itself, but the need to get out of it in a synchronous way...

... exactly as I stated!

TUsually large blocks of logic coming out of reset on two different clock cycles is not an issue, but if they are required to come out of reset precisely together, then you baked this interdependancy into the very functionality of your logic. In that case you forced the compiler to meet timing closure across the multiple large blocks just by the way you designed it.

Precisely.

It may work relatively easily in small designs where you aren't pushing the clock rate, but it doesn't scale very well.

A problem with the FPGA place-and-route tools is that the detailed placement is a fractal function of the specific design (and apparently the phase of moon!); a trivial change can cause significant speed variation or timing margins. Yes, you can lock down the placement of parts of a design, but then routing becomes more problematic. NP complete problems are bitches

[SiliconWizard]

There's at least one case for which an async reset can't be avoided - to ensure a definite state in the absence of a clock.

Accepted, although I haven't personally come across that situation.

That's quite possible, but the situation can actually happen more frequently than we think.

Even without thinking of anything fancy, just take any design which controls the clock - you may run into this.
Another range of examples is when the oscillator that provides the clock takes more time to start/stabilize than the FPGA takes to be fully configured, which can happen with PLLs for instance.

A typical example I have run into a couple times: designs with several clock domains, with at least one clock domain for which the clock could stop (and start) at any moment, and for which you'd need to put some signals in this clock domain in a definite state when there is no clock running. There is no way you can do that in a synchronous way only. The approach I used was to monitor said clock with a process clocked from another clock domain (in which its own clock was guaranteed to run at all times), then generate a 'reset' signal if it detected the absence of clock in the other domain - reset signal that would be asynchronous for this other domain. This worked fairly well. I can give a concrete example: designs using an FTDI part (FT2232H/FT232H) in synchronous mode. In this mode, the FTDI chip provides the clock for the FIFO - but this clock only gets out of the IC when the IC is put in the synchronous mode, which is software controlled. So from the FPGA's POV, this clock can be in any state (running, not running) at any point in time. If you don't implement this reset mechanism, your FSM(s) controlling the FTDI chip can get stuck in any state and this won't be recoverable.

As you said - even if this looks obvious - an asynchronous reset is asynchronous. In which case you'd need one? Obviously in cases where synchronous resets aren't appropriate.

People used to writing HDL exclusively for FPGAs tend to be kind of biased towards them - which makes sense. So this is particularly true for this asynchronous reset thing due to how most FPGAs are structured. It can be appropriate when writing HDL for ASICs. This is why (unless as others have said, I run/expect to run into issues meeting timings) I usually write HDL that can be more or less used both on FPGAs and synthesized on silicon later on  - unless I have a very specific reason not to.

Something "hidden" in that whole discussion (although it has been mentioned regarding initialization) is that even if you don't explicitely implement async resets, most FPGAs have a GSR structure that ensures an initial state upon configuration. Strictly speaking, this can be seen as an asynchronous reset (that just happens to take a different path.)

[tggzzz]

Agreed.

You can't completely escape asynchronous signals, but every single one needs specific justification and careful examination.

I remember asking my university tutor what happens if setup and hold times aren't met. I remember being disappointed in the waffly answer. The saving grace was that metastability was only just being recognised and quantified in the literature

[SiliconWizard]

You can't completely escape asynchronous signals, but every single one needs specific justification and careful examination.

Yes. The same should be said about most of what we do, actually (but I admit we often tend to use "recipes" instead.)

I remember asking my university tutor what happens if setup and hold times aren't met. I remember being disappointed in the waffly answer. The saving grace was that metastability was only just being recognised and quantified in the literature

From what I've seen, this topic is still relatively poorly taught these days, unless you take advanced courses at PhD level - I don't think I'm exxagerating here. It gets worse. I've seen a number of young engineers getting our of their master's with an apparently decent command of HDLs - until your realize they don't know how to deal with clock domain crossing whatsoever.

And related to the bias for FPGAs I talked about above: I think many university courses don't really teach the specifics of FPGAs, so students tend not to really grasp them. Which in turn makes them not really understand what is specific to FPGAs and what is more general for digital design.

[tolpe]

And related to the bias for FPGAs I talked about above: I think many university courses don't really teach the specifics of FPGAs, so students tend not to really grasp them. Which in turn makes them not really understand what is specific to FPGAs and what is more general for digital design.

I could name a few prominent technical universities teaching "old school" VHDL knowledge which can be basically thrown away with new technologies (or when deviating  from the local altera or xilinx monopolies that some schools have). It still tends to take years of practise in job to make a best score master student write robust designs.
In my opinion academics should go back to good old 74xx breadboard practise before starting anything like VHDL or Verilog. Then the next thing is, learning the standard constructs inferring into the wanted logic. This kinda works ok in most cases, *if* some overhead was not in the way.
Instead of working with logic, most students seem to get stuck with the complex semantics of language and complexity of vendor tools.

With respect to the omnipresent reset issues, I found the MyHDL approach very elegant, which sticks the sync or async behaviour properties into the signal declaration. So you can switch your design easily for architecture specific inference, like for ASIC targets (where everything must be reset, explicitely - unless in a ROM cell). Learning to read Verilog or VHDL is still important, but for understanding logic, the language complexities and creating designs particular in VHDL are debatable.

[tggzzz]

You can't completely escape asynchronous signals, but every single one needs specific justification and careful examination.

Yes. The same should be said about most of what we do, actually (but I admit we often tend to use "recipes" instead.)

Appropriate proven "design patterns" are thoroughly good. They reduce design & documentation time, and have a higher probability of avoiding stupid errors.

Stackexchange is full of recipes to be used - and promptly forgotten. No, I am not a fan of stackexchange.

I remember asking my university tutor what happens if setup and hold times aren't met. I remember being disappointed in the waffly answer. The saving grace was that metastability was only just being recognised and quantified in the literature

From what I've seen, this topic is still relatively poorly taught these days, unless you take advanced courses at PhD level

How can there even be any PhD courses? At that level you are supposed to be selecting and doing something novel.

- I don't think I'm exxagerating here. It gets worse. I've seen a number of young engineers getting our of their master's with an apparently decent command of HDLs - until your realize they don't know how to deal with clock domain crossing whatsoever.

They ought to realise where the dragons are, and some proven techniques. They won't necessarily have used them.

And related to the bias for FPGAs I talked about above: I think many university courses don't really teach the specifics of FPGAs, so students tend not to really grasp them. Which in turn makes them not really understand what is specific to FPGAs and what is more general for digital design.

That wouldn't bother me too much, provided they have a solid grounding in the basics and can think how an FPGA or CPLD or etc maps onto the fundamentals. Metastability is one such fundamental.

Overall, if a course is designed for one employer or job, then it is an apprenticeship or technician course - and that is just fine. An engineering course should teach the fundamentals that willlast a career and avoid teaching today's tech/tools. Those details can and will be learned on the job.

[NorthGuy]

Instead of working with logic, most students seem to get stuck with the complex semantics of language and complexity of vendor tools.

Just as electricians who know every detail of local electric codes, but may not know the Ohm's law. Such are times.

[tggzzz]

Instead of working with logic, most students seem to get stuck with the complex semantics of language and complexity of vendor tools.

Just as electricians who know every detail of local electric codes, but may not know the Ohm's law. Such are times.

That's not a bad analogy.

OTOH I've always liked the story of the wandering Indian holy man that owned three posessions: lunghi, shoes, and megaphone. Those were essential to his lifestyle.

[SiliconWizard]

How can there even be any PhD courses? At that level you are supposed to be selecting and doing something novel.

But you still have a lot to learn.
I don't know about all PhD programs in all parts of the world, but taking advanced courses as part of your doctoral studies is not uncommon at all. Your original research is the dominant part of it of course, but you usually also have to take somes specific courses and also do some teaching in order to complete your PhD.
Example: https://www.epfl.ch/education/phd/doctoral-studies-structure/

And related to the bias for FPGAs I talked about above: I think many university courses don't really teach the specifics of FPGAs, so students tend not to really grasp them. Which in turn makes them not really understand what is specific to FPGAs and what is more general for digital design.

That wouldn't bother me too much, provided they have a solid grounding in the basics and can think how an FPGA or CPLD or etc maps onto the fundamentals. Metastability is one such fundamental.

I don't quite agree here. The very discussion in this thread (and in many other thread here) shows the problem. Those topics are still very poorly taught as far as I've seen. IME, most students don't grasp metastability issues well or know how to handle them.

As to what is specific to FPGAs, the topic here would be an example, to understand why some vendors advise against async resets, whereas others don't, for instance. Also regarding signal initialization. Whereas they will work as expected on most FPGAs these days, they are certainly not synthesizable in general directly on silicon, so you typically get a range of different problems for initiliazing your signals properly.

To me, this is kind of fundamental knowledge.

[tggzzz]

I don't disagree, particularly about variability of PhDs and general knowledge.

Nonetheless, metastability is pretty fundamental.

[fourfathom]

I don't quite agree here. The very discussion in this thread (and in many other thread here) shows the problem. Those topics are still very poorly taught as far as I've seen. IME, most students don't grasp metastability issues well or know how to handle them.

As to what is specific to FPGAs, the topic here would be an example, to understand why some vendors advise against async resets, whereas others don't, for instance. Also regarding signal initialization. Whereas they will work as expected on most FPGAs these days, they are certainly not synthesizable in general directly on silicon, so you typically get a range of different problems for initiliazing your signals properly.

To me, this is kind of fundamental knowledge.

I think much of this could be considered domain-specific knowledge, but yes, metastability is one area that should probably be taught in a general digital design engineering course.

But I could be wrong -- I'm self-taught (no degree whatsoever) and began doing this stuff back in the days of RTL logic and using plastic tracing templates to draw my schematics.  I cut my digital teeth on telecom systems having multiple asynchronous clocks and signals (from DC to 10 GHz) and ended the design portion of my career with Verilog and gate arrays.  So I have no idea how this stuff is taught in school now.

[Berni]

I had a FPGA course as part of my electronics engineering degree. Haven't really gotten much useful knowledge out of it.

It was mostly like. Here is what a FPGA is and what it does. Here is what the Xilinx tools look like (And told to download and install it by next class because its a huge download as usual). Here is how you set up a test bench and simulate it. Then the rest turned into a digital logic class of... this is how you build an adder, this is how you build a MUX, this is how you build RAM, this is how you build a state machine (with i think no mention of state encoding types). Then you also get to run a few designs on a dev board to see the process and that is it.

Metastability? We never even heard about clock crossing or even timing analysis.

[tggzzz]

I had a FPGA course as part of my electronics engineering degree. Haven't really gotten much useful knowledge out of it.

It was mostly like. Here is what a FPGA is and what it does. Here is what the Xilinx tools look like (And told to download and install it by next class because its a huge download as usual). Here is how you set up a test bench and simulate it. Then the rest turned into a digital logic class of... this is how you build an adder, this is how you build a MUX, this is how you build RAM, this is how you build a state machine (with i think no mention of state encoding types). Then you also get to run a few designs on a dev board to see the process and that is it.

Metastability? We never even heard about clock crossing or even timing analysis.

That sounds about right. There is a terrible amount of "push this button" associated with FPGA toolsets - and that becomes obsolete very rapidly.

When I first thought about not observing t_s/t_h (which lead to my understanding metastability), FPGAs were a decade in the future. All the fundamental work was done w.r.t. mainframe computer and long-distance plesiochronous telecom systems.

Arguably, plesiochronous systems are a particularly nasty use case.

[mfro]

IMHO, although it doesn't hurt, you do not need to understand metastability to get your timings right.

It just needs the common sense that the data must be there before the clock. Just as you can't read a letter you didn't receive yet.

Metastability is a lot more complex topic than just that.

[tggzzz]

IMHO, although it doesn't hurt, you do not need to understand metastability to get your timings right.

It just needs the common sense that the data must be there before the clock. Just as you can't read a letter you didn't receive yet.

Exactly how do you guarantee that in a system with three unrelated clocks? (Or even two, but three makes the irreducable problem explicit)

Consider the effects that will be visible in plesiochronous systems where you have data arriving from several unrelated systems.

There are computing equivalents that most people choose not to think about; they too cause "interesting" system failures.

Background:
Here is the famous <2 page letter: http://ibm-1401.info/AnomalousSynchronizer_ChaneyMolnar_IEEE1973.pdf
Here are one of the author's recent thoughts, almost certainly "TL;DR" https://www.arl.wustl.edu/~jst/cse/260/glitchChaney.pdf

[mfro]

IMHO, although it doesn't hurt, you do not need to understand metastability to get your timings right.

It just needs the common sense that the data must be there before the clock. Just as you can't read a letter you didn't receive yet.

Exactly how do you guarantee that in a system with two unrelated clocks?

With the only thing that helps: proper synchronisation.

In the simplest case, a clocked shift register. In more difficult cases, with an asynchronous FIFO (admitted, writing an asynchronous FIFO *is* difficult, but I don't know anybody doing that other than for purely academic purpose anyway).

You do not need to fully understand all the details of metastability to use these, it all boils down to the requirement for the data arriving before the capture clock.

[tggzzz]

IMHO, although it doesn't hurt, you do not need to understand metastability to get your timings right.

It just needs the common sense that the data must be there before the clock. Just as you can't read a letter you didn't receive yet.

Exactly how do you guarantee that in a system with two unrelated clocks?

With the only thing that helps: proper synchronisation.

In the simplest case, a clocked shift register. In more difficult cases, with an asynchronous FIFO (admitted, writing an asynchronous FIFO *is* difficult, but I don't know anybody doing that other than for purely academic purpose anyway).

You do not need to fully understand all the details of metastability to use these, it all boils down to the requirement for the data arriving before the capture clock.

Of course, but those are mere workarounds since you can never ensure that, to use your phrase, "that the data must be there before the clock".

As for async FIFOs, your experience is limited: they are far more than only of academic interest. They are sufficiently important that Mouser lists 102 different discrete IC async FIFOs, and DigiKey lists 816. You don't make and sell discrete ics that are only of academic interest

Nowadays they are usually buried inside an FPGA, where different clock domains meet.

[mfro]

As for async FIFOs, your experience is limited: they are far more than only of academic interest. They are sufficiently important that Mouser lists 102 different discrete IC async FIFOs, and DigiKey lists 816. You don't make and sell discrete ics that are only of academic interest

You most likely don't buy async FIFOs at Mouser and cram them into your VHDL design, do you?
I didn't say async FIFOs are not important (of course they are), I said nobody would write them from scratch but probably would use what the FPGA vendors supply.

[tggzzz]

As for async FIFOs, your experience is limited: they are far more than only of academic interest. They are sufficiently important that Mouser lists 102 different discrete IC async FIFOs, and DigiKey lists 816. You don't make and sell discrete ics that are only of academic interest

You most likely don't buy async FIFOs at Mouser and cram them into your VHDL design, do you?

Please don't create strawman arguments by deliberately snipping relevant paragraphs. That just annoys people and makes you look foolish. In this case, which bit of this don't you understand?

Nowadays they are usually buried inside an FPGA, where different clock domains meet.

Then you claimed:

I didn't say async FIFOs are not important (of course they are), I said nobody would write them from scratch but probably would use what the FPGA vendors supply.

Is that what you had that in mind when you did write:

(admitted, writing an asynchronous FIFO *is* difficult, but I don't know anybody doing that other than for purely academic purpose anyway).

[NorthGuy]

It just needs the common sense that the data must be there before the clock. Just as you can't read a letter you didn't receive yet.

And after. You need to hold your letter until it is read.

Of course, you can figure out how to do timing analysis using common sense. You just need to think for few hours (or few days).

The problem is that people try to do away with structural things (such as gates and flops), and try to concentrate on behavioural things - find good language constructs (VHDL has so many ...) and such. Then it's getting very difficult to link their design to the timing requirements of flip flops. Newton's laws are also common sense, yet they haven't been discovered for thousands of years - people didn't think in the right direction.

[mfro]

I didn't say async FIFOs are not important (of course they are), I said nobody would write them from scratch but probably would use what the FPGA vendors supply.

Is that what you had that in mind when you did write:

(admitted, writing an asynchronous FIFO *is* difficult, but I don't know anybody doing that other than for purely academic purpose anyway).

Apologize if my statement wasn't clear enough. I thought it was obvious when I stated nobody writes async fifos that I didn't mean nobody uses async fifos (let alone when I said before you need them for more complex synchronisers)?

[Bassman59]

It just needs the common sense that the data must be there before the clock. Just as you can't read a letter you didn't receive yet.

And after. You need to hold your letter until it is read.

Exactly.

Consider: you have a data bus with a data valid flag, generated on one clock. The data bus is driven with a new value at the same time the flag is asserted.

In the other clock domain, you synchronize the flag, perhaps using two flip-flops in series clocked by that destination clock. Logic in that destination domain recognizes the assertion of the synchronized flag and latches the data bus. At the same time, a "clear flag" signal goes back to the source domain to do exactly that -- clear the data-valid flag.

I am not convinced that the data bus needs to be synchronized to the destination domain's clock. Only the flag needs such.

The timing analysis must be considered, with a path constraint. The assumption made above is that the data bus settles at the destination latches before the flag is recognized.

You may not even need the handshake. If the destination domain is faster than the source domain, you just synchronize the flag, detect its assertion and when that's true you latch your data bus. If the destination domain is slower than the source domain, the source needs to keep the flag true long enough to be recognized in the destination domain. So if your source clock is 100 MHz and your destination clock is 25 MHz, assert the flag (in the source domain) for 8 clocks.

There are many ways to handle this.

[Berni]

Yep that's the whole point behind holding the data.

It has to stay on the bus long enough for the other end to look at it and use it. This also brings into why designs are made synchronous if possible. If the other side knows exactly when to look at the data then the data only needs to be there for 1 clock cycle (Or even just half a clock cycle in DDR) before the bus can already put new data on it.

But usually when i do need to do clock crossing i just stick a small FIFO in there so its not my problem anymore.

[mfro]

... So if your source clock is 100 MHz and your destination clock is 25 MHz, assert the flag (in the source domain) for 8 clocks...

In that example (with both clocks being exact multiples), you often don't need synchronisers at all (provided both clocks stay synchronous, i.e. are driven by the same PLL).

You just need to make sure you hold your signals long enough in the fast clock domain so that your slow domain can see them.