Clock Constraints — Part 3
Welcome to Part3 in a series on Clock Constraints where I’m discussing different aspects of clock constraints from definitions to generated clocks and exceptions. In Part1 and Part2, we discussed how to define clocks and a few ways to infer clocks from the RTL in order to define generated clocks. In this part and the next, we’ll dive deeper into what happens after defining clocks and how they’re propagated.
Let’s approach this top-down. Meaning, I’ll give you the scope of what I’m trying to convey and then start bottom-up.
What do you see here?
- There are 3 clocks converging into a Multiplexer to start with.
- Different clocks are getting multiplexed before sending it out to sink flop Clock pins.
- Each of the source clocks could be coming from external interface or internally generated.
What’s the problem statement here?
- What’s the relationship between CLK-A , CLK-B and CLK-C. Why should we determine a relationship between all the clocks?
- What clocks should be propagated through these Multiplexers? Or is this even a question?
- Why can’t we just propagate all the clocks through for completeness of Static Timing Analysis.
By the end of this blog, I’ll do my best to answer the above questions. Let’s set aside the above circuit for the time being.
Clock Exceptions / Relationships :
Clock relationships in STA world are called Clock Exceptions. These are exceptions for Place & Route and STA tools to ensure the design is not too pessimistic
Note: Arrival window is an overlap of arrival times of aggressor/victim nets.
Why do we need Clock Relationships/ Exceptions:
To begin with, clock exceptions are critical for STA on multi-clock design. The reason being, there could be a large number of source clocks — external or internally generated using PLL, each of which could go through an array of clock generator circuits (as discussed in Part2) creating a large number of generated clocks. These generated clocks could go through Multiplexers often leading to complex reg2reg timing paths.
But why is this complex?
It’s a reg2reg path comprising of start-end points , each clocked w/ multiple clocks reaching their clock pins.
Let’s look at a simple case of two synchronous clocks feeding a Multiplexer and the o/p of the Mux driving sink flops FF1 and FF2.
If SEL is tied high(low) , omly CLK-B(CLK-A) propagates. This is usually the case when one clock is functional and the other is scan clock.
However, assuming SEL pin is not tied high/low, CLK-A and CLK-B (both functional & synchronous) propagate through the Multiplexer , giving rise to 4 cases below.
Regardless of what the clock exception is (clock relation between CLK-A and CLK-B) , Case 2 and 3 cannot happen because at any given time only 1 clock is active on CLK_OUT pin. But the tools today cannot infer that and perform STA for all 4 cases given above. By setting a logically exclusive exception on CLK-A and CLK-B, the tool excludes cases 2 & 3.
set_clock_groups -logically_exclusive -group “CLK-A” -group “CLK-B”
For all the paths downstream of the above Multiplexer, can we just propagate one functional clock instead of both? If so, which clock should we propagate?
Answer: We could propagate just one clock downstream of the Mux — provided there are no paths between
- Launch flops clocked by CLK-A/CLK-B before the Mux and Capture Flops clocked by CLK-OUT
- Launch flops clocked by CLK-OUT and Capture Flops clocked by CLK-A/CLK-B before the Mux
Consider #1 scenario below:
In the above circuit, FF2 gets either CLK-A / CLK-B. But FF1 gets CLK-A. In this scenario, case2 becomes valid. However, we have set a “logically_exclusive” exception that excludes case 2 from STA. This is a dangerous scenario. Therefore, it is important to understand the design architecture to a certain extent before setting exceptions.
In the above case, we could avoid adding a logically exclusive on CLK-A and CLK-B and instead only set false path between CLK-B and CLK-A
What happens when we have a FF3 which is clocked by CLK-B (before the Multiplexer) and a capture flop clocked by CLK-OUT. In this scenario, case 3 becomes valid too.
A more robust option is to define two generated clocks on CLK-OUT , one w.r.t CLK-A and the other w.r.t CLK-B and set a logically exclusive exception on the generated clocks. This would ensure that timing paths from Launch/capture flops (clocked before Mux ) to capture/launch flops (clocked after Mux ) are not missed, and the paths between flops after mux are not analyzed for cases 2/3 (which never happens)
- Create_generated_clock -name CLK_OUT_CLKA -source MUX/I0 -master_clock CLK-A MUX/OUT
- Create_generated_clock -name CLK_OUT_CLKB -source MUX/I1 -master_clock CLK-B MUX/OUT
- Set_clock_groups -logically_exclusive -group CLK_OUT_CLKA -group CLK_OUT_CLKB
To be continued in Part4…
