Static Timing Analysis Application Note 1.0 Abstract Static Timing Analysis (STA), accompanied by a static timing signoff methodology, provides a viable solution to timing verification of large gate-level synchronous designs. Functional integrity is verified with event-driven simulation or Formal Verification while timing is verified with STA. This is the primary difference between recent simulation-based signoff methodologies and STA-based signoff methodologies.
analysis. Furthermore, the intention intention is to create an understanding of the most common design constraints and list or define those design constraints required by AMI Semiconductor (AMIS) in in an STA signoff flow. flow. The overall goal is to ensure that the design information passed from the circuit designer to AMIS will be complete and accurate. The current STA tool used at AMIS is Synopsys’ PrimeTime (PT).
The objective of this application note is to describe the basics of STA and develop an understanding of timing
2.0 STA Basics STA involves three steps. Firstly, timing paths paths within the design are identified. The delay of each path is then calculated. Finally, the path delay is compared against the path timing constraint specified in the design.
cells. Endpoints include primary output ports and and data pins of sequential cells. cells. The timing paths paths in Figure 2.0 are represented with dotted arrows. arrows. The signals A and CLK are primary input ports; the signal DOUT is a primary output port.
Identifying Timing Paths Each path has a startpoint startpoint and an endpoint. endpoint. Startpoints include primary input ports and clock pins of sequential
Figure 2.0 Identifying timing paths for a simple D-type circuit.
Paths are grouped according to the clocks controlling their endpoints. These groups groups are called “path groups.” groups.” The default path group comprises all paths not associated with a defined clock. Examples are clock clock gating elements, recovery/removal checks, and paths to and from primary ports.
The circuit in Figure 2.1 represents typical timing paths present in a design. These are: input port to register register (path 1); register-to-register (path 2); register to output port (path 3); and input port to output output port (path 4). The process of deriving timing paths and assigning them to path groups is performed automatically automatically by Synopsys PT.
Static Timing Analysis Application Note
Figure 2.1 Timing paths in a typical design.
These types of paths would be grouped into path groups as determined by the endpoint clocks as shown in Figure 2.2.
CLK1
CLK2
path 1
path 2 DEFAULT path 3 path 4
Figure 2.2 Grouping timing paths paths according to endpoint clock.
STA Timing Constraints STA will compare each path delay against timing constraints. The dominant constraints are described as follows:
1) Setup. The maximum time that a data input pin of a sequential device must be stable before the clock (active edge) transition. 2) Hold. The minimum time that a data input pin of a sequential device must remain stable after the clock (active edge) edge) transition. See Figure 2.3.
Figure 2.3 Setup and hold times.
Static Timing Analysis Application Note 3) Recovery. The maximum time that an asynchronous control input pin must be stable after being de-asserted and before the next clock (active edge) transition. See Figure 2.4.
Figure 2.4 Recovery time.
4) Removal. The minimum time that an asynchronous control input pin must be stable before being de-asserted and after the previous clock (active edge) transition. See Figure 2.5.
Figure 2.5 Removal time.
5) Pulsewidth high. The length of time, after the rising edge of a clock, that the clock signal of a clocked device must remain high. See Figure 2.6.
Figure 2.6 High and low pulsewidth.
6) Pulsewidth low. The length of time, after the falling edge of a clock, that the clock signal of a clocked device must remain low. See Figure 2.6.
Static Timing Analysis Application Note Cell rise and fall times can cause pulsewidth degradation in the clock waveform by the time it reaches its destination. Pulsewidth constraints can also apply to other cell pins such as set, reset, and asynchronous ram control pins.
Glitch due to late arrival time of E Figure 2.7 Glitches caused by gating of clock signal.
Note: Additional information regarding STA can be found on the Synopsys web page at www.synopsys.com, and in the Synopsys online documentation.
7) Glitch detection. Glitches are usually caused when logic signals are allowed to gate the clock. The timing analyzer should search for such instances and report any possible glitches due to the gating logic. An example is shown in Figure 2.7.
Clipped pulse due to late arrival time of E
Static Timing Analysis Application Note 3.0 STA Constriant Definitions and AMIS Requirements Creating static timing analysis scripts containing design specific assertions, exceptions, and design environment information can be tedious and time consuming depending on the complexity and understanding of the design. Section 2.0 briefly described some of the information and design constraints that are essential for exhaustive and accurate
Figure 3.0 Design Files & Libraries.
timing analysis. This section describes the same information and design constraints as they relate specifically to the PT. This section will also present information that is required by AMIS at design hand-off, in order to provide accurate and timely STA results. The diagram in Figure 3.0 shows the flow used for STA with PT.
Static Timing Analysis Application Note ASIC Netlist The ASIC netlist must be gate-level, referencing only technology libraries and/or blocks that have a complete timing model. PT can read flat or hierarchical netlists in structural/gate-level VHDL, Verilog, EDIF, and Synopsys DB formats. ASIC Library The ASIC/technology libraries contain cell pinout, port capacitance, pin-to-pin timing arcs, timing constraints and other critical design information. Referencing multiple libraries is allowed, for example to direct the PT to a core cell library, a memory library, and a pad cell library. All libraries referenced in the netlist must be “visible” to the PT as it reads the netlist. In PT, libraries are made visible with the “search_path” and “link_path” variables. Two examples are shown: • pt_shell> set search_path ". /path/ami/synopsys/lib/ami500hxsc /path/ami/synopsys/lib/ami500hxpr" • pt_shell> set link_path "* ami500hxsc.db ami500hxpr.db" Black Box Models Black box models are timing models for hard macros or IP, including RAM, ROM, microprocessors, microcontrollers, and analog blocks. Hard macros or IP are generally too complex to be modeled as a library cell and are thus modeled using the Synopsys Liberty, Synopsys extracted timing or STAMP formats and then compiled into the Synospys .db format. PT can read Synopsys .db format directly. Black box models In addition to containing contain pin information and input to output timing paths, black box models must present a complete description of timing performance and possible modes of operation (for example, read versus write modes in a memory element). Synopsys Liberty and extracted timing models must be compiled in PT prior to analysis. This can be accomplished with the Synopsys library compiler “lc_shell” tool.
STAMP models must be compiled in PT prior to analysis. The following PT commands for compiling a STAMP model and reading a .db file are: • pt_shell> compile_stamp_model -model_file sram.mod data_file sram.data -ouput sram_model • pt_shell> read_db sram.db Synospys’ Liberty format is becoming the most widely used for modelling timing of complex and analog blocks. Important: Note that all customer-created models must be made available to AMIS at time of design hand-off in Liberty, STAMP .mod and .dat, or compiled .db format. Clocks All clocks used or referenced in the design must be specified. This includes definitions for system-level clocks and internally generated clocks along with their corresponding period, waveform characteristics (rise and fall times), latency, skew, transition time and source point. System Clocks STA supports analysis of the synchronous portion of a design, analyzing paths between sequential devices and ports. System clocks are those clocks that originate at primary input ports of the chip. The clock cycle time, rise and fall transitions within the cycle (duty cycle), and primary input port where the clock originates must be known for all system clocks (primary clock inputs). The PT “create_clock” command is used to specify system clocks for the design. Figure 3.1 shows a diagram of the required clock information. The following command shows the corresponding PT specification for the clock shown in figure 3.1.
pt_shell> create_clock -period 20 -waveform {0 10} CLK
CHIP BOUNDARY
CHIP
CLK
Figure 3.1 Diagrammatic view of required clock information.
Static Timing Analysis Application Note clocks or derived clocks. Derived clocks have to be defined since PT cannot determine skew and frequency due to complex connectivity and the use of sequential devices in the clock path. Derived clocks can be derived from any system clock or other derived clocks in the design. Figure 3.2 shows example waveforms of system and divide-by-2 generated clocks.
Important: Note that all system clocks, their corresponding ports, cycle times, and waveforms are required. Derived Clocks A design may include internal clock dividers or other structures that produce new clock signals from a system clock. These types of clocks are referred to as generated
Figure 3.2 System and divide-by-2 generated clocks.
The PT “create_generated_clock” command is used to specify internally generated clocks in the design. The command requires the specification of the instance name of the device which generates the clock, instance pin name where the clock originates, clock reference name (the clock used to create the generated clock), the name of the generated clock signal, and the type of clock generation scheme that is being used (for example, divide-by, multiply,
or the frequency of the generated clock and the transition times of the rising and falling edges within the cycle). Figure 3.3 shows a diagram of the required clock information. The PT command below corresponds to the example shown in figure 3.3. pt_shell> create_generated_clock -name DIVLCK -source CLK -divide_by 2 FF_INST/Q
CHIP BOUNDARY
CHIP
Figure 3.3 Internally generated clocks.
Static Timing Analysis Application Note Important: Note that all derived clocks and their corresponding source clocks, as well as origination point (cell instance and pin), cycle times and waveforms, are required. Gated Clocks A gated clock signal is a clock signal where the clock network contains combinational logic other than inverters and buffers. For example, if a clock signal drives one input to a logic AND gate and a control/data signal is connected to other input, the output of the AND gate is a gated clock signal. PT will automatically run setup and hold checks on combinational gates in a clock path or warn of their existence. The gating device is treated similarly to a sequential device. Performing a setup check ensures the controlling signal is stable prior the active edge of the clock, thereby avoiding “clipping” of the gated clock signal. The hold check ensures that the controlling signal is stable for the duration of the clock pulse following its active edge,
thereby avoiding “glitching” of the gated clock signal. Figure 3.4 shows the potential problems with clock gating devices. It also shows the period during which the control signal can move with respect to the clock to avoid violations. PT uses a default value of 0.0 for the setup and hold checks. The hold is checked against the inactive edge of the clock. This is usually the falling edge since the majority of AMIS registers are rising edge triggered. The setup is checked against the active edge of the clock: usually the rising edge for AMIS registers. This type of setup and hold checking requires that the control/data signal remain stable during the clock pulse immediately following the active edge of the clock signal. This is usually the high pulse for AMIS registers. Therefore, the control signal can only change during the inactive pulse of the corresponding clock. See Figure 3.4.
Figure 3.4 Gated clock constraints.
Clock Cycle and Waveform The clock cycle or clock period is the time required for the clock signal to repeat. The clock waveform consists of the points in time, during the clock cycle, where the clock signal rises and falls. Clock Latency Latency is the delay in the clock path, and comprises two components: source latency and network latency. Source latency is the time a clock signal takes to propagate from its ideal waveform origin point to the clock definition point in the design. Network latency is the time a clock signal (rise or fall) takes to propagate from the clock definition point to a register clock pin. Network latency is often referred to as insertion delay. PT provides two alternative methods for representing clock latency: 1) Automatically compute latency by propagating delays along the clock network. This option is generally used after clock-tree synthesis when the clock network is completely buffered.
2) Estimated clock latency set using PT commands. This generally takes place prior to clock-tree synthesis. System clocks have ideal waveforms that ignore the delay effects of the clock network. Often, during pre-layout, the clock network is not completely defined. This requires that latency and skew be defined in order for the timing analysis to be accurate. Latency is simply delay in the clock line and must be estimated and applied to the clock during pre-layout timing analysis. If the gate-level netlist is generated through synthesis, the clock network should be unbuffered. In this case the clock node will appear similar to Figure 3.5 and will be overloaded, resulting in timing violations. Therefore, the latency in the clock line must be estimated and applied in the static timing analysis to mimic the expected latency of the clock network after clock-tree synthesis and layout.
Static Timing Analysis Application Note
Figure 3.5 Unbuffered clock network.
For example, if the clock latency of the clock network is estimated to be about 4.0ns, then the latency should be specified with the PT “set_clock_latency” command as shown below. One method of estimating the prelayout clock latency is using the ACCESS compute-clock-bufferparameters tool. The latency reported by compute-clockbuffer-parameters can be used directly in the set_clock_latency command. After the clock tree has been inserted in the design, the latency can be calculated directly using the PT “set_propagated_clock” command. The command below exemplifies the clock latency specification in PT. pt_shell> set_clock_latency 4.0 [get_clock CLK] Important: Note that the expected clock latency is required for all system clocks in the design. Clock Skew Clock skew is the difference between the arrival time of clock signals at different registers in one clock domain or between clock domains.
Similar to clock latency, PT provides two methods for representing clock skew: 1) Automatically compute skew by propagating delays along the clock network. This option is generally used after clock-tree synthesis when the clock network is completely buffered. 2) Estimated clock skew manually set using PT commands. This generally takes place prior to clock-tree synthesis. Clock skew is handled in the same manner as clock latency. During pre-layout, and immediately following synthesis, the skew must be estimated and applied to the clock node for correct timing analysis. A value of 400ps is a good estimate for the clock skew if the AMIS clock tree synthesis flow is being used. Application engineers and design engineers at AMIS can provide further assistance if required. After the clock tree has been inserted into the design, the skew can be calculated directly with the PT “set_propagated_clock” command. The command below exemplifies the clock skew specification in PT. pt_shell> set_clock_uncertainty 0.4 -setup [get_clock CLK] Important: Note that the expected clock skew is required for all clock domains in the design.
Static Timing Analysis Application Note Clock Transition Time The delay calculator built into PT automatically computes the transition times of core ports, cells and nets. Transition is also known as slew. Primary input ports or pad cells are an exception to this rule, as their input transition times are a function of the external driver and therefore must be specified. Similar to latency and skew, PT provides two methods of representing clock transition. 1) Automatically compute transition by propagating delays along the clock network. 2) Estimated clock transition times manually set using PT commands. This generally takes place prior to clock-tree synthesis and if the Standard Delay Format (SDF) data is not being annotated. Careful specification of clock transition is critical during prelayout where a clock tree is not present in the design. If the gate-level netlist is generated through synthesis, the clock network will be unbuffered. In this case the clock node will be overloaded resulting in long “clock to q” times in those registers driven by the clock. Excessive clock to q times result directly from the slow transition times present at the clock pins of the registers. Therefore, the transition time of the clock node must be estimated and specified in the static timing analysis, to mimic the actual transition time of the clock network after clock tree insertion and layout. The pre-layout clock transition time may be estimated using the ACCESS “compute-clock-buffer-parameters” tool. The transition time reported by this tool could be used directly in the PT “set_clock_transition” command. For more information about running compute-clock-bufferparameters, see the ACCESS documentation. After the clock tree has been inserted into the design, the clock transition times can be calculated directly using the PT “set_propagated_clock” command. Contact the factory for additional information regarding estimated clock latency, transition, and skew parameters. Design Assertions Design assertions include clocks and clock network delay information as described above. Design assertions also include external input delay, external output delay, wireload models, operating conditions, physical interconnect parasitic data, SDF, etc. Wireload Model A wireload model estimates the wire loading responsible for wire delays prior to placement and routing. Various
wireload models are provided in the technology library and one must be specified if generating timing with the STA tool. Wireload models of varying accuracy can be created and used during different phases of the design. Pre-Layout Estimated Wire Capacitance Prior to floorplanning or layout, wireload models are based on fanout and area. These models are generated with statistical data and are located in the technology library. AMIS wireload models estimate interconnect capacitance only. The PT “set_wire_load_model” command is used to set the wireload model to be used during pre-layout STA. pt_shell> set_wire_load_model -library ami350lxsc3 -name 400 The wireload model names in the standard cell technology libraries translate directly to the corresponding die size. The wireload model names in the gate array technology libraries are slightly different. Important: Note that the expected die size and/or wireload model are both required for static timing analysis. Post-Layout Wire Capacitance After routing, exact wire lengths and capacitances can be annotated into PT in the form of a parasitic file (SPEF) and/or SDF. Operating Conditions Operating conditions are used to specify any applicable process derating factor, as well as the operating temperature, operating voltage and an interconnect model type. Note that operating conditions must be specified in PT if the tool is to generate timing information. The operating conditions are defined in the technology libraries and include conditions such as; BEST-CASE-SPEEDCOMMERCIAL (BCC), BEST-CASE-SPEED-INDUSTRIAL (BCI), BEST-CASE-SPEED-MILITARY (BCM), WORST-CASESPEED-COMMERCIAL (WCC), WORST-CASE-SPEEDINDUSTRIAL (WCI), WORST-CASE-SPEED-MILITARY (WCM), and TYPICAL (TYP). Operating conditions are technology specific. The PT “set_operating_conditions” command is used to set the operating conditions for the design. pt_shell> set_operating_conditions -analysis_type bc_wc lib ami350lxsc3 -max WCI -min BCI Important: Note that the required device operating conditions must be provided.
Static Timing Analysis Application Note Input Delay The arrival time at an input port is typically relative to an external clock edge and mimics an external sequential data launching device. The external clock may either be the same clock that is used in the design, or a virtual clock. Input delay should include the clock to q delay of the external launching device and any delay in the logic driving the input port. Figure 3.6 provides a visual representation of input delay.
Input delay on clock ports should be regarded as clock source latency and should be treated differently than input delay on data ports. Clock source delay for system clocks is seldom used in the AMIS flow.
CHIP BOUNDARY
CHIP
Figure 3.6 Calculating input delay.
Input delay could be considered a percentage of the clock cycle required for the data to arrive at the port from the external launching register.
setup time of the input register. The PT “set_input_delay” command is used to specify input timing constraints for input data ports, as shown:
For example, in the circuit shown in Figure 3.6, the rising edge of the clock will launch data at the external register. The input data delay will then consist of the clock to q time of the external register plus the delay through the logic prior to the input port of the chip. Assuming the clock cycle is 10ns, then if this external typical delay is 7ns, then the input delay is 70% of the clock cycle. This indicates that 30% of the clock cycle time, or 3ns, is available for the data to travel from the input port through the chip input logic to the data pin of the input capture register if it is to meet the
pt_shell> set_input_delay -max -clock [get_clocks CLK] 7.0 [remove_from_collection [all_inputs] CLK] pt_shell> set_input_delay -min -clock [get_clocks CLK] 2.0 [remove_from_collection [all_inputs] CLK] Important: Note that the input delay and the name of the clock driving the external register are required for each data port in the design. The clock driving each external register must also be specified.
Static Timing Analysis Application Note Output Delay The time requirement of an output port is relative to an external clock edge and mimics an external sequential datacapturing device. The external clock may be the same clock that is used internally to the design or it could be a virtual clock. An output delay represents an external timing path from an output or I/O port to an external register. The maximum output delay value should be equal to the delay
of the longest path from the output port through any external logic to the external register data pin, plus the setup time of that register. The minimum delay should be equal to the length of the shortest path from the output port through any external logic to the register data pin, minus the hold time. Figure 3.7 provides a visual representation of output delay.
CHIP BOUNDARY CHIP
Figure 3.7 Calculating output delay.
The PT “set_output_delay” command is used to specify output delay timing, as follows: pt_shell> set_output_delay -max -clock [get_clocks CLKPAD] 4.5 [all_outputs] pt_shell> set_output_delay -min -clock [get_clocks CLKPAD] 1.5 [all_outputs]
Important: Note that the output delay and the name of the clock driving the external register are required for each output port in the design. The clock driving the external register must also be specified.
Static Timing Analysis Application Note SDF Standard Delay Format (SDF) contains cell and interconnect delay for the circuit. SDF can be generated from a number of sources. PrimeTime is the only accepted source of SDF files for XPA designs and SC designs below 0.25µm. in all other cases, ACCESS is the only accepted source of SDF data. SDF is loaded into PT subsequent to loading the netlist and provides the tool with the circuit timing and state device constraints.
Design Exceptions When determining maximum and minimum delay requirements, PT assumes single-cycle timing for all paths in a design. Single-cycle timing means that data propagates to its destination, or is expected to arrive at its destination point, in one clock cycle. Figure 3.8 shows D1 being launched at edge 0 of CLKL and D2 being captured at edge 1 of CLKC. The data is launched at edge 0 and captured at edge 1, propagating within a single clock cycle.
Physical Data Physical data includes custom wireload models from floorplanning, as well as extracted interconnect parasitic information from routing.
Figure 3.8 Single-Cycle timing.
In some situations, single-cycle timing may not be appropriate or achievable. For example, a path may require more than one clock cycle to propagate, or may start and end with the same clock edge. It is also possible that the path may be false. There are three exceptions that override the default single-cycle timing. These are false paths, multicycle paths and zero-cycle paths.
Multi-Cycle Paths and Zero-Cycle Paths Multi-cycle paths are those paths that require more than one clock cycle to propagate. Zero-cycle paths are those paths that are launched and captured with the same clock edge, or that are skewed due to large interconnect delays or intentional signal skewing techniques. Figure 3.9 illustrates a multi-cycle path. Assuming the clock cycle is 2ns and the delay through the buffer in the clock line is 3.2ns, the data will arrive at the capture register in the second clock cycle at clock edge 2 in the CLKC waveform of Figure 3.9.
Static Timing Analysis Application Note
Figure 3.9 Multi-Cycle path.
The PT “set_multicycle_path” command is used to specify multi-cycle paths as follows: pt_shell> set_multicycle_path 2 -setup -from FF1/C -to FF2/D Important: Note that the paths in the design that require more than one clock cycle to propagate must be specified at time of design hand-off. The information required is the instance name of the register where the
Figure 3.10 Zero-Cycle Timing.
path begins, the instance name of the register where the path ends, and the number of clock cycles required for the data to propagate. Figure 3.10 illustrates a zero-cycle path. Assuming the clock cycle is 2ns and the delay through the buffer in the clock line is larger than the clock-to-q delay of FF1, the data will be captured at FF2 by the same clock edge that launches the data from FF1 (edge 0 of CLKC).
Static Timing Analysis Application Note The PT “set_multicycle_path” command is used to specify zero-cycle paths as follows: pt_shell> set_multicycle_path 0 -setup -from FF1/C -to FF2/D Important: Note that all paths in the design that require zero clock cycle to propagate must be declared. The information required is the instance name of the register where the path begins and the instance name of the register where the path ends. False Paths False paths are those logic paths that exist but cannot be sensitized, or where analysis of the path is not required. False paths should be defined and excluded from analysis. False paths also include those paths that are launched and captured by unrelated clocks or asynchronous clocks. The PT “set_false_path” command is used to specify false paths as follows: pt_shell> set_false_path -from FF1/C -to FF2/D Important: Note that the false paths in the design must be provided. The information required is the instance name of the register and pin where the path begins and the instance name of the register and pin where the path ends. Analysis Static timing analysis exhaustively computes path timing for the ASIC design and compares the timing against the inherent design constraints based on the assertions and exceptions set by the designer. These constraints include setup, hold, pulsewidth, recovery and removal. Prior to commencing analysis, all paths in the design should have been constrained. PT allows for several types of analysis, as described in the following paragraphs. Single Operating Condition Analysis Analysis is performed with timing values for a single operating condition. For example, if reading the worst case timing numbers from an SDF file, setup and hold checks are
Figure 3.11 Exercising multiple functional modes.
calculated using only the worst case timing numbers. Two analysis runs would be required. The first run would check for setup violations using worst case timing numbers, followed by a second run to check for hold violations with best case timing numbers. Best/Worst Case Operating Conditions Analysis In this case, both the minimum and maximum operating conditions are specified. When reading the SDF for this type of analysis, PT reads both the best case timing numbers and the worst case timing numbers. Best case numbers are used when checking for hold violations and worst case numbers are used when checking for setup violations. Best/worst case analysis is more efficient than single operating condition analysis since setup and hold checking is completed in a single run. Case Analysis Case analysis allows timing analysis to be performed using logic constants or logic transitions (rising or falling) on ports or pins, to limit the signals propagated through the design. It can also be used for enabling or disabling conditional arcs from Liberty or STAMP models. Constants are propagated forward through the design. PT automatically detects pins tied high and low, and propagates the value. Case analysis is a path-pruning mechanism and is most commonly used for timing the device in a given operational configuration or functional mode. For example, case analysis can be used to compare normal circuit operation against scan or BIST operation. For exhaustive analysis of the design, every functional mode of operation should be analyzed. Depending on the complexity of the circuit, this can become time consuming. By providing comprehensive information at the earliest stages of timing analysis, a more complete analysis can be accomplished quickly and efficiently. Figure 3.11 illustrates functional modes and the information needed to analyze the circuit in a particular mode. The circuit has two modes of operation: scan mode and normal operating mode. If a constant high value is placed on the port "SCNMODE" the circuit is in scan operation. A constant low value will place the circuit in normal operation.
Static Timing Analysis Application Note The PT “set_case_analysis” command is used to specify design nodes with constant values and different functional modes of operation in the design as follows: pt_shell> set_case_analysis 0 [get_ports SCNMODE -filter {direction == in}] Important: Note that all functional circuit modes requiring analysis must be specified. The information required must include the mode-select values, as well as the ports, pins, or nets in the design at which each modeselect value should be applied, in order to put the design in a particular mode of operation. Mode Analysis Complex components (usually proprietary or third-party IP blocks) may have multiple timing paths that are dependent on the mode of operation of the device. For example, many of the RAM blocks have a read and a write mode, each having different timing characteristics. PT analyzes the timing of all paths, regardless of the functional mode. However, the designer may need to analyze the timing of a specific mode that disables timing arcs that do not occur in the given mode. Component modes must be coded into the Liberty or STAMP component model to be used. Modes are most common in Liberty and STAMP memory models. The PT “set_case_analysis” command can also be used for setting the mode of a component if the mode is defined and conditional on the state of a controlling pin. The PT “set_mode” command should be used when modes are defined but condition association is not used.
Violation Checks PT can perform the following timing checks: • Data Setup The setup time for each logic state at the data pin of each sequential device is checked. The setup time can be defined in relation to the rising or falling edge of the corresponding sequential device clock signal. • Data Hold The hold time for each logic state at the data pin of each sequential device is checked. The hold time can be defined in relation to the rising or falling edge of the corresponding sequential device clock signal. • Set/Reset Recovery The recovery check is similar to the data setup check and represents the minimum time that the asynchronous set or reset pin must be stable after being deasserted, and before the next active clock edge transition. • Set/Reset Removal The removal check is similar to the data hold check and represents the minimum time that the asynchronous set or reset pin must be stable before being deasserted and after the previous active clock edge transition. • Minimum Pulse Width Minimum pulse width is checked for each sequential device clock pin. • False Path PT has the ability to detect false paths with the “-true”, “false”, “-justify” options of the “report_timing” command. PT does not detect false paths automatically. • Zero-cycle Path Zero-cycle paths are not detected by PT. This can make timing reports very difficult to understand.
4.0 Example Scripts ****** Functional pre-layout PT script ****** #set sh_enable_page_mode true set sh_continue_on_error false #set sh_script_stop_severity E # define location of all libraries set search_path ". /tools/amilibs/synopsys/libs/amih180xxgca /tools/amilibs/synopsys/lib/amih180xxpr3 /tools/amilibs/synopsys/lib/amih180xxgea /tools/amilibs/synopsys/lib/amih180xxgma” # MAX CORNER libs – the core library should be the first in the link path set link_path "* amih180xxgca_max.db amih180xxgea_max.db amih180xxgma_max.db amih180xxpr3_max.db" read_verilog netlist_prelayout.v current_design TOP link # operating conditions vs reading SDF at prelayout # you have two options; (1) you can use PT to do the delay calculation with # wireload models and timing tables from the Synospys libraries, or (2) in # 0.35u technologies and above (including XPA), prelayout SDF can be generated # using ACCESS and then annotated into PT. You only need to use on of these. #(1) set_operating_conditions –analysis_type single WCI –library amih180xxgca_max set_wire_load_model –name XP568E –library amih180xxgca_max set_load 50 [all_outputs]
Static Timing Analysis Application Note # or #(2) #read_sdf -load_delay cell -analysis_type single -type sdf_max btw.sdf # make sure the SDF annotated clean #report_annotated_delay –list_not_annotated –cell > annotated_delay_max.rpt #report_annotated_check –list_not_annotated > annotated_check_max.rpt # clocking system # system-level clock definitions – clocks originating at top level primary input ports create_clock -period 10.0 -waveform {0 5.0} [get_ports CLK] # virtual clock for port timing create_clock -name VCLK -period 10.0 -waveform {0 5.0} # generated clocks definitions – clocks originating inside the design from another clock create_generated_clock –name GENCLK –source [get_ports CLK] –divide_by 2 [get_pins DFLOP/Q] # clock specs set_clock_uncertainty 0.05 get_clock CLK] set_clock_latency 3 [get_clocks CLK] set_clock_transition 0.4 [get_clock CLK] set_clock_uncertainty 0.05 [get_clock GENCLK] set_clock_transition 0.4 [get_clock GENCLK] set_clock_latency –source 3 [get_clock GENCLK] set_clock_latency 2 [get_clock GENCLK] # boundary constraints # set input constraints # 1.0/0.9 min/max input constraints at 100Mhz spec-ed by customer set_input_delay 9.1 -clock VCLK [remove_from_collection [all_inputs] [get_ports CLK]] # set output constraints # 1.5/5.5ns min/max clk to out @ 25pf and 100Mhz spec-ed by customer set_output_delay 4.5 -clock VCLK [all_outputs] # clock gating checks on/off #set timing_disable_clock_gating_checks true # constraints for functional mode where the design has DFT set_false_path -from [get_ports {TDI}] set_false_path -to [get_ports {TDO BISTDONE}] # functional bypass mode, set at the outputs of the TAP controller set_case_analysis 0 TRSTN set_case_analysis 0 [get_pins BSCN130/EXTEST] set_case_analysis 0 [get_pins BSCN130/IDCODE] set_case_analysis 0 [get_pins BSCN130/SAMPLE] set_case_analysis 0 [get_pins BSCN130/HIGHZ] set_case_analysis 0 [get_pins BSCN130/NSCAN] set_case_analysis 0 [get_pins BSCN130/NTTEST] set_case_analysis 0 [get_pins BSCN130/RAMBIST] set_case_analysis 1 [get_pins BSCN130/BYPASS] # reports check_timing –v > check_timing_setup.rpt check_timing –no_clock > no_clocks_max.rpt report_constraint –max_delay –all_violators > setup_short.rpt report_constraint –max_delay –all_violators -verbose > setup.rpt report_constraint –recovery –all_violators > recovery_short.rpt report_constraint –recovery –all_violators -verbose > recovery.rpt # MIN CORNER remove_design –all set link_path "* amih180xxgca_min.db amih180xxgea_min.db amih180xxgma_min.db amih180xxpr3_min.db" read_verilog netlist_prelayout.v
Static Timing Analysis Application Note current_design TOP link # operating conditions vs reading SDF at prelayout # you have two options; (1) you can use PT to do the delay calculation with # wireload models and timing tables from the Synospys libraries, or (2) in # 0.35u technologies and above (including XPA), prelayout SDF can be generated # using ACCESS and then annotated into PT. You only need to use on of these. #(1) set_operating_conditions –analysis_type single WCI –library amih180xxgca_min set_wire_load_model –name XP568E –library amih180xxgca_min set_load 50 [all_outputs] # or #(2) #read_sdf -load_delay cell -analysis_type single -type sdf_min btw.sdf # make sure the SDF annotated clean #report_annotated_delay –list_not_annotated –cell > annotated_delay_min.rpt #report_annotated_check –list_not_annotated > annotated_check_min.rpt # clocking system # system-level clock definitions – clocks originating at top level primary input ports create_clock -period 10.0 -waveform {0 5.0} [get_ports CLK] # virtual clock for port timing create_clock -name VCLK -period 10.0 -waveform {0 5.0} # generated clocks definitions – clocks originating inside the design from another clock create_generated_clock –name GENCLK –source [get_ports CLK] –divide_by 2 [get_pins DFLOP/Q] # clock specs set_clock_uncertainty 0.05 get_clock CLK] set_clock_latency 3 [get_clocks CLK] set_clock_transition 0.4 [get_clock CLK] set_clock_uncertainty 0.05 [get_clock GENCLK] set_clock_transition 0.4 [get_clock GENCLK] set_clock_latency –source 3 [get_clock GENCLK] set_clock_latency 2 [get_clock GENCLK] # boundary constraints # set input constraints # 1.0/0.9 min/max input constraints at 100Mhz spec-ed by customer set_input_delay 1.0 -clock VCLK [remove_from_collection [all_inputs] [get_ports CLKPAD]] # set output constraints # 1.5/5.5ns min/min clk to out @ 25pf and 100Mhz spec-ed by customer set_output_delay -1.5 -clock VCLK [all_outputs] # clock gating checks on/off #set timing_disable_clock_gating_checks true # constraints for functional mode where the design has DFT set_false_path -from [get_ports {TDI}] set_false_path -to [get_ports {TDO BISTDONE}] # functional bypass mode, set at the outputs of the TAP controller set_case_analysis 0 TRSTN set_case_analysis 0 [get_pins BSCN130/EXTEST] set_case_analysis 0 [get_pins BSCN130/IDCODE] set_case_analysis 0 [get_pins BSCN130/SAMPLE] set_case_analysis 0 [get_pins BSCN130/HIGHZ] set_case_analysis 0 [get_pins BSCN130/NSCAN] set_case_analysis 0 [get_pins BSCN130/NTTEST] set_case_analysis 0 [get_pins BSCN130/RAMBIST] set_case_analysis 1 [get_pins BSCN130/BYPASS]
Static Timing Analysis Application Note # reports check_timing –v > check_timing_hold.rpt check_timing –no_clock > no_clocks_min.rpt report_constraint –min_delay –all_violators > hold_short.rpt report_constraint –min_delay –all_violators -verbose > hold.rpt report_constraint –removal –all_violators > removal_short.rpt report_constraint –removal –all_violators -verbose > removal.rpt ****** Scan pre-layout PT script ****** #set sh_enable_page_mode true set sh_continue_on_error false #set sh_script_stop_severity E # define location of all libraries set search_path ". /tools/amilibs/synopsys/libs/amih180xxgca /tools/amilibs/synopsys/lib/amih180xxpr3 /tools/amilibs/synopsys/lib/amih180xxgea /tools/amilibs/synopsys/lib/amih180xxgma” # MAX CORNER libs – the core library should be the first in the link path set link_path "* amih180xxgca_max.db amih180xxgea_max.db amih180xxgma_max.db amih180xxpr3_max.db" read_verilog netlist_prelayout.v current_design TOP link # operating conditions vs reading SDF at prelayout # you have two options; (1) you can use PT to do the delay calculation with # wireload models and timing tables from the Synospys libraries, or (2) in # 0.35u technologies and above (including XPA), prelayout SDF can be generated # using ACCESS and then annotated into PT. You only need to use on of these. #(1) set_operating_conditions –analysis_type single WCI –library amih180xxgca_max set_wire_load_model –name XP568E –library amih180xxgca_max set_load 50 [all_outputs] # or #(2) #read_sdf -load_delay cell -analysis_type single -type sdf_max btw.sdf # make sure the SDF annotated clean #report_annotated_delay –list_not_annotated –cell > annotated_delay_max.rpt #report_annotated_check –list_not_annotated > annotated_check_max.rpt # clocking system # system-level clock definitions – clocks originating at top level primary input ports create_clock -period 100.0 -waveform {0 50.0} [get_ports CLK] # virtual clock for port timing create_clock -name VCLK -period 100.0 -waveform {0 50.0} # generated clocks definitions – clocks originating inside the design from another clock create_generated_clock –name GENCLK –source [get_ports CLK] –divide_by 2 [get_pins DFLOP/Q] # clock specs set_clock_uncertainty 0.05 get_clock CLK] set_clock_latency 3 [get_clocks CLK] set_clock_transition 0.4 [get_clock CLK] set_clock_uncertainty 0.05 [get_clock GENCLK] set_clock_transition 0.4 [get_clock GENCLK] set_clock_latency –source 3 [get_clock GENCLK] set_clock_latency 2 [get_clock GENCLK] # boundary constraints # set input constraints # 1.0/0.9 min/max input constraints at 100Mhz spec-ed by customer
Static Timing Analysis Application Note set_input_delay 9.1 -clock VCLK [remove_from_collection [all_inputs] [get_ports CLK]] # set output constraints # 1.5/5.5ns min/max clk to out @ 25pf and 100Mhz spec-ed by customer set_output_delay 4.5 -clock VCLK [all_outputs] # clock gating checks on/off #set timing_disable_clock_gating_checks true set_false_path -to [get_ports BISTDONE] # functional bypass mode, set at the outputs of the TAP controller set_case_analysis 0 TRSTN set_case_analysis 0 [get_pins BSCN130/EXTEST] set_case_analysis 0 [get_pins BSCN130/IDCODE] set_case_analysis 0 [get_pins BSCN130/SAMPLE] set_case_analysis 0 [get_pins BSCN130/HIGHZ] set_case_analysis 1 [get_pins BSCN130/NSCAN] set_case_analysis 0 [get_pins BSCN130/NTTEST] set_case_analysis 0 [get_pins BSCN130/RAMBIST] set_case_analysis 0 [get_pins BSCN130/BYPASS] # reports check_timing –v > check_timing_scan_setup.rpt check_timing –no_clock > no_clocks_scan_max.rpt report_constraint –max_delay –all_violators > setup_scan_short.rpt report_constraint –max_delay –all_violators -verbose > setup_scan.rpt report_constraint –recovery –all_violators > recovery_scan_short.rpt report_constraint –recovery –all_violators -verbose > recovery_scan.rpt # MIN CORNER remove_design –all set link_path "* amih180xxgca_min.db amih180xxgea_min.db amih180xxgma_min.db amih180xxpr3_min.db" read_verilog netlist_prelayout.v current_design TOP link # operating conditions vs reading SDF at prelayout # you have two options; (1) you can use PT to do the delay calculation with # wireload models and timing tables from the Synospys libraries, or (2) in # 0.35u technologies and above (including XPA), prelayout SDF can be generated # using ACCESS and then annotated into PT. You only need to use on of these. #(1) set_operating_conditions –analysis_type single WCI –library amih180xxgca_min set_wire_load_model –name XP568E –library amih180xxgca_min set_load 50 [all_outputs] # or #(2) #read_sdf -load_delay cell -analysis_type single -type sdf_min btw.sdf # make sure the SDF annotated clean #report_annotated_delay –list_not_annotated –cell > annotated_delay_min.rpt #report_annotated_check –list_not_annotated > annotated_check_min.rpt # clocking system # system-level clock definitions – clocks originating at top level primary input ports create_clock -period 100.0 -waveform {0 50.0} [get_ports CLK] # virtual clock for port timing create_clock -name VCLK -period 100.0 -waveform {0 50.0} # generated clocks definitions – clocks originating inside the design from another clock create_generated_clock –name GENCLK –source [get_ports CLK] –divide_by 2 [get_pins DFLOP/Q] # clock specs set_clock_uncertainty 0.05 get_clock CLK] set_clock_latency 3 [get_clocks CLK]
Static Timing Analysis Application Note set_clock_transition 0.4 [get_clock CLK] set_clock_uncertainty 0.05 [get_clock GENCLK] set_clock_transition 0.4 [get_clock GENCLK] set_clock_latency –source 3 [get_clock GENCLK] set_clock_latency 2 [get_clock GENCLK] # boundary constraints # set input constraints # 1.0/0.9 min/max input constraints at 100Mhz spec-ed by customer set_input_delay 1.0 -clock VCLK [remove_from_collection [all_inputs] [get_ports CLKPAD]] # set output constraints # 1.5/5.5ns min/min clk to out @ 25pf and 100Mhz spec-ed by customer set_output_delay -1.5 -clock VCLK [all_outputs] # clock gating checks on/off #set timing_disable_clock_gating_checks true set_false_path -to [get_ports BISTDONE] # functional bypass mode, set at the outputs of the TAP controller set_case_analysis 0 TRSTN set_case_analysis 0 [get_pins BSCN130/EXTEST] set_case_analysis 0 [get_pins BSCN130/IDCODE] set_case_analysis 0 [get_pins BSCN130/SAMPLE] set_case_analysis 0 [get_pins BSCN130/HIGHZ] set_case_analysis 1 [get_pins BSCN130/NSCAN] set_case_analysis 0 [get_pins BSCN130/NTTEST] set_case_analysis 0 [get_pins BSCN130/RAMBIST] set_case_analysis 0 [get_pins BSCN130/BYPASS] # reports check_timing –v > check_timing_scan_hold.rpt check_timing –no_clock > no_clocks_scan_min.rpt report_constraint –min_delay –all_violators > hold_scan_short.rpt report_constraint –min_delay –all_violators -verbose > hold_scan.rpt report_constraint –removal –all_violators > removal_scan_short.rpt report_constraint –removal –all_violators -verbose > removal_scan.rpt ****** Functional post-layout PT script ****** #set sh_enable_page_mode true set sh_continue_on_error false #set sh_script_stop_severity E # define location of all libraries set search_path ". /tools/amilibs/synopsys/libs/amih180xxgca /tools/amilibs/synopsys/lib/amih180xxpr3 /tools/amilibs/synopsys/lib/amih180xxgea /tools/amilibs/synopsys/lib/amih180xxgma” # MAX CORNER libs – the core library should be the first in the link path set link_path "* amih180xxgca_max.db amih180xxgea_max.db amih180xxgma_max.db amih180xxpr3_max.db" read_verilog netlist_prelayout.v current_design TOP link # operating are not needed at postlayout in most cases, since the operating # conditions are taken care of during SDF generation. read_sdf -load_delay cell -analysis_type single -type sdf_max btw.sdf # make sure the SDF annotated clean report_annotated_delay –list_not_annotated –cell > annotated_delay_max.rpt report_annotated_check –list_not_annotated > annotated_check_max.rpt
Static Timing Analysis Application Note # loading on outputs not needed, since it was specified during SDF generation # clocking system # system-level clock definitions – clocks originating at top level primary input ports create_clock -period 10.0 -waveform {0 5.0} [get_ports CLK] # virtual clock for port timing create_clock -name VCLK -period 10.0 -waveform {0 5.0} # generated clocks definitions – clocks originating inside the design from another clock create_generated_clock –name GENCLK –source [get_ports CLK] –divide_by 2 [get_pins DFLOP/Q] # propagate the clocks set_propagated_clock [all_clocks] # clock specs set_clock_uncertainty 0.05 get_clock CLK] set_clock_uncertainty 0.05 [get_clock GENCLK] # boundary constraints # set input constraints # 1.0/0.9 min/max input constraints at 100Mhz spec-ed by customer set_input_delay 9.1 -clock VCLK [remove_from_collection [all_inputs] [get_ports CLK]] # set output constraints # 1.5/5.5ns min/max clk to out @ 25pf and 100Mhz spec-ed by customer set_output_delay 4.5 -clock VCLK [all_outputs] # clock gating checks on/off #set timing_disable_clock_gating_checks true # constraints for functional mode where the design has DFT set_false_path -from [get_ports {TDI}] set_false_path -to [get_ports {TDO BISTDONE}] # functional bypass mode, set at the outputs of the TAP controller set_case_analysis 0 TRSTN set_case_analysis 0 [get_pins BSCN130/EXTEST] set_case_analysis 0 [get_pins BSCN130/IDCODE] set_case_analysis 0 [get_pins BSCN130/SAMPLE] set_case_analysis 0 [get_pins BSCN130/HIGHZ] set_case_analysis 0 [get_pins BSCN130/NSCAN] set_case_analysis 0 [get_pins BSCN130/NTTEST] set_case_analysis 0 [get_pins BSCN130/RAMBIST] set_case_analysis 1 [get_pins BSCN130/BYPASS] # reports check_timing –v > check_timing_setup.rpt check_timing –no_clock > no_clocks_max.rpt report_constraint –max_delay –all_violators > setup_short.rpt report_constraint –max_delay –all_violators -verbose > setup.rpt report_constraint –recovery –all_violators > recovery_short.rpt report_constraint –recovery -verbose –all_violators > recovery.rpt # MIN CORNER remove_design –all set link_path "* amih180xxgca_min.db amih180xxgea_min.db amih180xxgma_min.db amih180xxpr3_min.db" read_verilog netlist_prelayout.v current_design TOP link read_sdf -load_delay cell -analysis_type single -type sdf_min btw.sdf # make sure the SDF annotated clean report_annotated_delay –list_not_annotated –cell > annotated_delay_min.rpt report_annotated_check –list_not_annotated > annotated_check_min.rpt
Static Timing Analysis Application Note # clocking system # system-level clock definitions – clocks originating at top level primary input ports create_clock -period 10.0 -waveform {0 5.0} [get_ports CLK] # virtual clock for port timing create_clock -name VCLK -period 10.0 -waveform {0 5.0} # generated clocks definitions – clocks originating inside the design from another clock create_generated_clock –name GENCLK –source [get_ports CLK] –divide_by 2 [get_pins DFLOP/Q] # propagate the clocks set_propagated_clock [all_clocks] # clock specs set_clock_uncertainty 0.05 get_clock CLK] set_clock_uncertainty 0.05 [get_clock GENCLK] # boundary constraints # set input constraints # 1.0/0.9 min/max input constraints at 100Mhz spec-ed by customer set_input_delay 1.0 -clock VCLK [remove_from_collection [all_inputs] [get_ports CLKPAD]] # set output constraints # 1.5/5.5ns min/min clk to out @ 25pf and 100Mhz spec-ed by customer set_output_delay -1.5 -clock VCLK [all_outputs] # clock gating checks on/off #set timing_disable_clock_gating_checks true # constraints for functional mode where the design has DFT set_false_path -from [get_ports {TDI}] set_false_path -to [get_ports {TDO BISTDONE}] # functional bypass mode, set at the outputs of the TAP controller set_case_analysis 0 TRSTN set_case_analysis 0 [get_pins BSCN130/EXTEST] set_case_analysis 0 [get_pins BSCN130/IDCODE] set_case_analysis 0 [get_pins BSCN130/SAMPLE] set_case_analysis 0 [get_pins BSCN130/HIGHZ] set_case_analysis 0 [get_pins BSCN130/NSCAN] set_case_analysis 0 [get_pins BSCN130/NTTEST] set_case_analysis 0 [get_pins BSCN130/RAMBIST] set_case_analysis 1 [get_pins BSCN130/BYPASS] # reports check_timing –v > check_timing_hold.rpt check_timing –no_clock > no_clocks_min.rpt report_constraint –min_delay –all_violators > hold_short.rpt report_constraint –min_delay –all_violators -verbose > hold.rpt report_constraint –removal –all_violators > removal_short.rpt report_constraint –removal –all_violators -verbose > removal.rpt
Static Timing Analysis Application Note 5.0 Recommended Design Practices The ideal scenario for STA is a completely synchronous design having a single clock domain, no internally generated clocks (divide-by or otherwise), no feedback loops, no clock gating, no additional test logic, no multicycle paths or false paths, etc. These types of designs are seldom encountered. In order to maximize the efficiency and speed of STA, restrictions must be imposed on design styles and methodologies. The following guidelines should be borne in mind. 1) Run separate STA for different modes of circuit operation such as functional mode, scan mode, BIST, etc. Create separate timing scripts for each mode of operation that can be used repetitively, since STA is run throughout the design flow. Test mode pins and logic values should be documented to further assist STA of all operational modes. If a JTAG controller is used, case analysis can be used on the outputs of the instruction registers to put the design into a given mode. The following example constrains the design for functional mode STA (BYPASS mode) where JTAG, scan, BIST, and nandtree test structures have been inserted among additional JTAG modes.
set_case_analysis 0 [get_ports TRSTN] set_case_analysis 0 [get_pins BSCN130/EXTEST] set_case_analysis 0 [get_pins BSCN130/IDCODE] set_case_analysis 0 [get_pins BSCN130/SAMPLE] set_case_analysis 0 [get_pins BSCN130/HIGHZ] set_case_analysis 0 [get_pins BSCN130/NSCAN] set_case_analysis 0 [get_pins BSCN130/RAMBIST] set_case_analysis 0 [get_pins BSCN130/BYPASS] Where JTAG is not used, other test structures such as BIST and scan are inserted and controlled by primary design ports. In this scenario, case analysis must be specified on the test ports to constrain the design. 2) Avoid combinational feedback loops. Combinational loops are asynchronous since the signal must often iterate several times through the loop before settling to its final value. Combinational loops must be verified with dynamic simulation. Most combinational loops can be replaced with synchronous logic. The Design Compiler will issue warnings when combinational loops are encountered during synthesis. Unavoidable combinational loops should be isolated in a block of hierarchy and simulated to verify timing. PT breaks loops by disabling a timing arc that will least affect other paths. Figure 5.0 represents a timing loop and location where PT will break the loop (arc b to q where the arrow is located in the OR gate).
Logic Loop
Figure 5.0 Disabling a timing arc to break a combinational loop.
3) Avoid self-timed and master/slave circuitry. This is asynchronous logic that must be simulated separately. 4) Understand asynchronous clock domains, minimize generated clocks, and minimize clock domains in general. Best design practice is to avoid clock domains, internally generated clocks and cross clock domain paths wherever
possible. Generated clocks pose a problem when they are not documented and result in unconstrained sections of the design. A fixed phase relationship must exist between the startpoint and endpoint clocks that cross clock domains. Clocks may be single phase, multiple phase, or multiple frequency devices.
Static Timing Analysis Application Note In the case of multiple frequency clocks, the designer must pay attention to the base period over which the clock waveforms repeat. The base period is defined by the lowest common multiple of the all clock periods. If this base period is more than ten times larger than the shortest clock period, long runtimes and excessive memory requirements will result. For example, if a register with a 10ns clock feeds another register with a 10.1ns clock, there is no reasonable base period. PT will attempt to find a base period and phase relationship, resulting in excessive memory consumption
and runtime. Consequently the resulting setup requirement is very restrictive. These types of paths should be verified with simulation and considered asynchronous during STA. If the clocking schemes are understood, considerable time can be saved during STA. Figure 5.1 illustrates how PT treats a path crossing multiple frequency clock domain. pt_shell> create_clock –period 4 –waveform {3 4} [get_ports CLK1] pt_shell> create_clock –period 3 –waveform {1 2} [get_ports CLK2])
setup
setup
Figure 5.1 Multiple frequency clock domain analyzed by Synopsis PT.
PT can analyze paths clocked by single phase, multiple phase, and multiple frequency clocks. However, for each path, a fixed phase relationship must exist between the startpoint and endpoint clocks. Clocks that do not have a fixed phase relationship are considered asynchronous. It is important to remember that if paths between clocks have different frequencies, there must be an acceptable base period over which all clock waveforms repeat. If no such period can be determined, clock paths such as these can be pruned from analysis by setting false paths between the clocks. The timing for these paths would then need to be verified with dynamic simulation. 5) Identify and document clock gating devices. The name of each gating structure instance should be documented. PT has the ability to check gating devices where one pin is a clock and all others are data signals. Designers should also bear in mind the advice given in Section 2.0 of this application note regarding glitch detection. PT does not handle the scenario where more than one pin of a gate is driven by a clock signal. This will cause incorrect timing and is usually difficult to uncover because PT does not warn of this situation and does not have the ability to determine the resulting clock waveform by combining the multiple input clock waveforms with the functionality of the gate. If multiple clocks are driving multiple pins of the gate, PT will propagate through the gate the first defined clock it finds. 6) Determine and document the validity of bi-directional feedback loops as early as possible. By default, PT breaks paths through bi-directional I/O cells. If any or all of these
paths are valid, they must be taken into account with the following PT variables: “timing_disable_internal_inout_cell_paths” and “timing_disable_internal_net_arcs”. With these set to false (checking turned on), the bidirectional feedback paths that are not valid must then be removed from the timing with false_path or set_disable_timing constraints. The remainder of the feedback paths will be checked. 7) Identify and document timing exceptions. Exceptions include: false paths; paths that take more than one clock cycle to propagate (multi-cycle path); paths that are launched and captured by the same clock edge (zero-cycle path); combinational loops and the best location to break them; asynchronous clock domains; locations of generated clocks inside the device; any other exceptions defined by the designer. The designer should provide a complete set of timing exceptions/constraints at the time of design handoff. If these are not made available, the alternative is to build a top-level PT script and attempt to find the timing exceptions through iterations of STA and discussions with the designer. This makes for unacceptably long verification cycles. 8) Output loading and I/O constraints. Correct output capacitance loading should be defined at the beginning of any analysis since it affects output timing. I/O constraints include input and output delays external to the design. These values should be specified for all I/Os except primary clock ports. I/O timing constraints must be specified for PT
Static Timing Analysis Application Note with regard to external requirements. Input delay is defined as the delay from the clock pin of the external register to the input port, including any logic delay between the external register and the input port. See Figure 5.2. set_input_delay 4.2 –clock CLK [get_ports P16]
Figure 5.2 Input delay.
Output delay represents the external timing path from an output port to an external register. The maximum output delay should be the longest path delay to the register data pin, plus the setup time of the register. The minimum output delay should be the shortest delay path to the
Figure 5.3 Output delay.
register data pin, minus the hold time of the register. See Figure 5.3. set_output_delay –min 1.75 –clock CLK [get_ports OUT1] set_output_delay –max 3.7 –clock CLK [get_ports OUT1]
Static Timing Analysis Application Note Customers frequently specify output timing to be clock-toout timing. This is, in fact, the timing from the internal output register to the output port. In this scenario, the output timing has to be modified slightly to force PT to check the constraint correctly. In the event that the output delay is given as a clock-to-out specification, the input delay is as described above. The maximum output delay is the difference between the clock period and the maximum output specification. The minimum output delay is –1 times the minimum output specification. For example, if the clockto-out specification is defined as 4ns max. and 1ns min., where the clock speed is 6.67ns (150MHz), the output delays would be specified in PT as “set_output_delay –max 2.67 –clock CLK [get_ports OUT1]” and “set_output_delay –min –1.0 –clock CLK [get_ports OUT1]”. 9) Latches and time borrowing. PT uses time borrowing when timing paths to latches, in order to correctly account for the duration for which the latch is transparent. Latches
complicate timing analysis and make the reports difficult to understand. Use of latches should be avoided where possible. 10) Although the timing for RAM, pulse generators and write-enable (WE) pins must be verified via simulation, asynchronous RAM read timing can be analyzed using STA. Asynchronous RAMs cannot be timed in STA, but the asynchronous read cycle of some RAMs can be timed if either the RAM is properly constrained to the read mode operation or if the model allows for read timing analysis. In most cases, the RAM must be constrained, since the AMIS models are not built for different modes of operation in STA. A common flow is to place and route and then simulate the RAM and pulse generator, subsequently modifying the layout to add or subtract delay from the pulse generator to achieve the required delay and pulse width to the RAM’s WE pin.
6.0 Conclusion Static Timing Analysis (STA) requires the identification of timing paths throughout an entire design, followed by calculation of the delay of each path and final comparison of the path delay with the path timing constraints specified in the design. Large, gate level synchronous designs depend on automatic tools capable of carrying out STA, and successful
completion of STA is essential in order for the design to pass final signoff. Designers who are aware of guidelines and best practice in relation to signal timing issues, as well as the limitations of automatic STA tools, will be best equipped to submit designs that will meet the specified STA performance with minimum effort, and proceed quickly to final signoff.
7.0 Revision Control Date February 26, 2003 March 11, 2003
Page -
April 6, 2003
-
AMI Semiconductor www.amis.com
Description Contact Initial Publication Khris Kofford Reordered sections Inserted missing graphics Incorporated reviewer comments.
