Don’t Shoot Yourself in the Foot With Timing Exceptions

Timing exceptions are ways of guiding design tools, primarily synthesis and static timing analysis (STA), but these days also place & route and perhaps other tools. Most paths in a design go from one register to the next register. Both registers are on the same clock, and the design needs to ensure that the signal can make it from the first register, through the logic gates, and get to the next register in time to meet the setup time there, and so successfully get clocked into that next register. Synthesis will pick appropriate cells to make it so, and STA will check that this was done correctly.

But what happens when that isn’t true. If the two registers are on different clocks, or if we don’t really care if the value is correctly latched since we are never going to use it, or it is only for a test mode that is run at low speed, or if we don’t latch the value until two clock cycles later. Then we need to tell the tools, and this is done using timing exceptions, typically in the SDC constraint file.

There are three main types of timing exception:

• asynchronous paths such as clock domain crossings (CDC)
• false paths: synchronous paths where the timing is not relevant
• multi-cycle paths: synchronous paths where the signal has more than one clock cycle to arrive

There are two types of problem with timing exceptions. The first is where there is a timing exception but we didn’t declare it. The tools will work hard to meet the constraint anyway, and if they succeed then there may be some waste but the design will work. On the other hand, we can declare a timing exception and tell the tools to ignore something, when it turns out it was important. This can be a real disaster, resulting in non-functional silicon that apparently passes all verification successfully.

Setting a false path (using set_false_path command in SDC) is used for the following reasons:

• asynchronous false path, most commonly where the path is between two separate clock domains and some sort of synchronizer or handshake protocol is being used. CVC verification is a must to ensure that this is all done correctly and that everyone on the design team is correctly interpreting the clock domains in the same way
• static source. It is common practice to declare a false path on a static signal (since it is static, there is no need for any optimization or checking). But in reality there are very few truly static signals in a design, just signals that change very rarely such as during manufacturing test.
• synchronous paths. Often these types of path may only be false in a particular implementation, or can cause glitches that the STA tool would have caught if the path was not declared false. Sometimes these are just slow paths and a safer approach is to declare them multicycle paths.

Setting a multicycle path (using set_multicycle_path in SDC) is done to relax timing requirements. However, care still needs to be taken with relaxed timing to ensure that races and glitches are not created and, indeed, that the functionality of the design and the relationship between the various stages is properly understood.

SpyGlass TXV (Timing eXception Verification) is a good way to verify these exceptions and catch many errors. This is increasingly important now that so much of a design is 3rd party IP where the RTL and the timing constraints are not well-understood by the SoC design team who didn’t create them.

A much more detailed white paperAvoiding Pitfalls While Specifying Timing Exceptions is available on Atrenta’s website here.