Static Timing Analysis (STA) is an integral part of backend design cycle. At each stage in the design cycle, it is imperative to check for timing violations by carrying out static timing analysis and do course correction, if required. A typical physical design cycle involves logic synthesis followed by test insertion, placement, clock tree synthesis and data routing. At each of these stages, we need to ensure that the timing is under control by running STA. Figure 1 below shows, on a higher level, different steps involved in physical design cycle; and how STA is an integral part of each of the stages.
Figure 1: STA as an integral part of physical design cycle |
The first step in physical design cycle is synthesis and test insertion followed by floorplanning and placement. Although, nowadays, some tools combine synthesis and placement to save on run time and efforts. At this level, STA is run with ideal clocks and estimated parasitic values either on the basis of fanout with a model known popularly as WLM (Wire Load model) or on the basis of actual placement of instances. Since, a lot of variables are not taken into account at this stage, it is preferred to meet setup timing with some margin so as to accommodate the degradation in setup timing due to those variables later in the design cycle. These variables include clock skew, uncommon path in clock network, data nets detouring during actual routing and crosstalk effects. When clock tree is built, we have actual clock skew numbers. So, STA needs to be run to check if the margins for clock skew need to be accommodated into some more optimization (area, power or timing) due to actual clock skews and uncommon clock paths being different than the margin assumed. Similarly, after data routing, we can run STA with actual parasitic values and crosstalk effects, thereby signing off timing using STA by running accross all possible corner scenarios.
No comments:
Post a Comment
Thanks for your valuable inputs/feedbacks. :-)