|STA Using EDA tool (Part1)||STA Using EDA tool (Part2)|
Till Now, I have discussed so many basic about the STA and other topics but now the question is where and how we can use these basics in the real world. What’s the practical use of these basics? Someone asked me long time back that now a days, EDA tools are enough intelligent that they can solve the problem very easily and very well, then why should I know all the basics? He was right (not 100%), thing is tools are intelligent but up-to a certain limit. Still there are lot of things/settings which you have to set inside the tools (like options/ switches/ settings), before running those tools on your design.
Basics are pillars for any practical uses, but he was correct because until we don’t know how and where to use these basics, we will always have such questions.
I was thinking to capture the flow of STA (Static timing analysis) in general (independent of any specific EDA tool) but I faced a lot of problem in generalizing the different concepts. So I have used PrimeTime/Encounter Timing system (PT/ETS), which are industry standard EDA Tool for the Timing Analysis, for my Blog as a reference. I have captured only those info related to PT /ETS which is on the basis of my experience and easily available on the internet.
Note: For explanation purpose, there are chances that I have picked any example which is/are not supported by Primetime/ETS, so don’t consider this Blog as a user guide for Primetime/ETS. Please refer/contact Synopsys’ Document/support team for the any help related to PrimeTime and Cadence Community for any help related to Encounter Timing System.
Now before we start performing the Static Timing Analysis, we should know following type of info
- What type of analysis we want to perform?
- Whether tool is capable to do that?
- If yes, what should be the input data and in which format?
- What are the settings we have to do in that specific EDA tool?
Let’s start with the type of analysis/checking we can perform. There are different types of analysis we can do as per the complexity of the design / technology node /specification of design (or we can say the application of the design). Few of them are listed below (I am not going to describe the details of those in this blog because few are already discussed and few I will post later on).
- Types of Checking Performed
- Setup, hold, recovery, and removal constraints
- Clock-gating setup and hold constraints
- Minimum period and minimum pulse width for clocks
- Design rules (minimum/maximum transition time, capacitance, and fanout)
- Analysis Features
- Multiple clocks and clock frequencies Analysis
- Transparent latch analysis
- Simultaneous minimum/maximum delay analysis for setup and hold
- Best case (bc), worst case (wc), bc_wc, OCV/AOCV analysis
- Case analysis (analysis with constants or specific transitions applied to specified inputs)
- Mode analysis (analysis with module-specific operating modes, such as test mode, functional mode, scan mode )
- Bottleneck analysis (reporting of cells that cause the most timing violations)
- ECO analysis without modifying the original netlist, using inserted buffers, re-sized cells, and modified nets
- Signal Integrity Analysis (crosstalk effects between physically adjacent nets)
- Noise analysis
- Statistical Timing analysis
- Path based /Graph Based analysis
Now once you will choose the type of analysis, next is whether your Timing analysis tool support these type of analysis and till what accuracy. As such most of the analysis type is common and all the tools support these. But still it’s worth to check this before starting STA.
Now what should be the input data and in what format. Few of the necessary data are listed below with different type of formats.
- Design Netlist
- Verilog (.v)
- Timing Libraries
- Delay information
- Parasitic data
- Standard Parasitic Exchange Format (SPEF)
- Synopsys Binary Parasitic Format (SBPF)
- Reduced Standard Parasitic Format (RSPF).
- Timing constraints
Now in the Next Blog we will discuss all these in more detail.