Thanks for the comments. There's definitely a lot that could be added, and if I get the time I am thinking of adding direct examples. The set_min/max_delay slides were thrown in last minute, which is why they tend to be packed without good examples. But it's just too difficult to cover everything. For example, on the metastability one:
Metastability occurs when the data transitions within the registers setup/hold requirements. The register goes to an intermediate "unkown" state. If the data and clock are truly asynchronous, then there is no way to avoid this. In most asynchronous transfers like this, the user does not care if the register gets a 1 or a 0 on that clock, just that it clearly goes to one of those values. If it does not, it can cause problems downstream. The most common case is when the metastable register feeds multiple destinations. For example, if it fed two bits of a state-machine, one path might see that register's "unknown" state as a 1, the other register might see it as a "0", and the state-machine would go into an undefined state and perhaps never recover. Not good.
Now, a common practive is to double(or triple, etc.) register the asynchronous signal into the new domain. How does this help? The first register can go metastable, as it's input is asynchronous. A metastable register in an "unknown" state will eventually fall to a valid state, whether it be a 1 or a 0. The common analogy is that it is a rock on the top of a curve, which will eventually roll down to the 1 or a 0. This process has odds that it will go to a known state within a certain amount of time. For example, it may be 1/10,000 metastable events that will still be "unknown", or at the top of the curve, after 1ns. It might be 1/1,000,000 after 2ns. It might be 1/1,000,000,000,000 after 4ns. So if you wait 4ns before recapturing the signal, you can be pretty sure that the metastability will have shaken out and the second register will always be a known 1 or 0, over the lifetime of the product. (I'm making the numbers up so far, so don't trust them too closely. Also note that ever transfer won't cause metastability. For example, if the signal switches approximately every 20ns, and the receive register's Tsu/Th window is only 200ps, then ~1/100 transfers would go metastable. And usually these signals transfer much less than that.)
Anyway, if our receiving double registers are driven by a 10ns clock, then we have a 10ns setup requirement between the two clocks. So let's say the fitter places and routes so the data delay is 9.999ns and it just makes timing. If the first register goes metastable and stays that way for 100ps, then that metastable condition will travel through 9.999ns of delay will be clocked into the second register. But if the user put a set_max_delay of 1.0ns on the path and it met timing, so the path was 1.0ns long between the double registers, then the first register could go metastable and have 9.0ns before it settles to a known state, at which point this known value would transfer to the destination register before it's latching clock, and the second register would never latch in the metastable event.
Admittedly, diagrams would help a lot with this, but hopefully that makes sense. Hopefully it also shows why there are a lot of examples, but by adding them all and properly explaining them, the presentation would get confusing and diluted(and that's assuming I had the time out of my normal job to take on such a task...) But keep asking questions.
Honored Contributor
