Static Timing 1

Static Timing Analysis (STA), accompanied by a static timingsignoff methodology, provides a viable solution to timingverification of large gate-level synchronous designs.Functional integrity is verified with event-driven simulationor Formal Verification while timing is verified with STA. Thisis the primary difference between recent simulation-basedsignoff methodologies and STA-based signoffmethodologies.

The objective of this application note is to describe thebasics of STA and develop an understanding of timing

analysis. Furthermore, the intention is to create anunderstanding of the most common design constraints andlist or define those design constraints required by AMISemiconductor (AMIS) in an STA signoff flow. The overallgoal is to ensure that the design information passed fromthe circuit designer to AMIS will be complete and accurate.

The current STA tool used at AMIS is Synopsys’ PrimeTime(PT).

Static Timing Analysis Application Note

1.0 Abstract

STA involves three steps. Firstly, timing paths within thedesign are identified. The delay of each path is thencalculated. Finally, the path delay is compared against thepath timing constraint specified in the design.

Identifying Timing PathsEach path has a startpoint and an endpoint. Startpointsinclude primary input ports and clock pins of sequential

cells. Endpoints include primary output ports and data pinsof sequential cells. The timing paths in Figure 2.0 arerepresented with dotted arrows. The signals A and CLK areprimary input ports; the signal DOUT is a primary outputport.

2.0 STA Basics

AMI Semiconductor1

www.amis.com

Figure 2.0 Identifying timing paths for a simple D-type circuit.

Paths are grouped according to the clocks controlling theirendpoints. These groups are called “path groups.” Thedefault path group comprises all paths not associated witha defined clock. Examples are clock gating elements,recovery/removal checks, and paths to and from primaryports.

The circuit in Figure 2.1 represents typical timing pathspresent in a design. These are: input port to register (path1); register-to-register (path 2); register to output port (path3); and input port to output port (path 4). The process ofderiving timing paths and assigning them to path groups isperformed automatically by Synopsys PT.


AMI Semiconductor2

www.amis.com

These types of paths would be grouped into path groups asdetermined by the endpoint clocks as shown in Figure 2.2.

STA Timing ConstraintsSTA will compare each path delay against timingconstraints. The dominant constraints are described asfollows:

1) Setup. The maximum time that a data input pinof a sequential device must be stable before theclock (active edge) transition.

2) Hold. The minimum time that a data input pin ofa sequential device must remain stable after theclock (active edge) transition. See Figure 2.3.

Figure 2.1 Timing paths in a typical design.

Figure 2.2 Grouping timing paths according to endpoint clock.

Figure 2.3 Setup and hold times.

path 1 path 2

path 3path 4

CLK2CLK1

DEFAULT


AMI Semiconductor3

www.amis.com

3) Recovery. The maximum time that anasynchronous control input pin must be stableafter being de-asserted and before the nextclock (active edge) transition. See Figure 2.4.

4) Removal. The minimum time that anasynchronous control input pin must be stablebefore being de-asserted and after the previousclock (active edge) transition. See Figure 2.5.

5) Pulsewidth high. The length of time, after therising edge of a clock, that the clock signal of aclocked device must remain high. See Figure2.6.

6) Pulsewidth low. The length of time, after thefalling edge of a clock, that the clock signal of aclocked device must remain low. See Figure 2.6.

Figure 2.4 Recovery time.

Figure 2.5 Removal time.

Figure 2.6 High and low pulsewidth.


AMI Semiconductor4

www.amis.com

Cell rise and fall times can cause pulsewidth degradation inthe clock waveform by the time it reaches its destination.Pulsewidth constraints can also apply to other cell pins suchas set, reset, and asynchronous ram control pins.

7) Glitch detection. Glitches are usually causedwhen logic signals are allowed to gate the clock.The timing analyzer should search for suchinstances and report any possible glitches due tothe gating logic. An example is shown in Figure2.7.

Note: Additional information regarding STA can be found onthe Synopsys web page at www.synopsys.com, and in theSynopsys online documentation.

Figure 2.7 Glitches caused by gating of clock signal.

Clipped pulse due tolate arrivaltime of E

Glitch due tolate arrivaltime of E


AMI Semiconductor5

www.amis.com

Creating static timing analysis scripts containing designspecific assertions, exceptions, and design environmentinformation can be tedious and time consuming dependingon the complexity and understanding of the design. Section2.0 briefly described some of the information and designconstraints that are essential for exhaustive and accurate

timing analysis. This section describes the same informationand design constraints as they relate specifically to the PT.This section will also present information that is required byAMIS at design hand-off, in order to provide accurate andtimely STA results. The diagram in Figure 3.0 shows theflow used for STA with PT.

Figure 3.0 Design Files & Libraries.

3.0 STA Constriant Definitions and AMIS Requirements


AMI Semiconductor6

www.amis.com

ASIC NetlistThe ASIC netlist must be gate-level, referencing onlytechnology libraries and/or blocks that have a completetiming model. PT can read flat or hierarchical netlists instructural/gate-level VHDL, Verilog, EDIF, and Synopsys DBformats.

ASIC LibraryThe ASIC/technology libraries contain cell pinout, portcapacitance, pin-to-pin timing arcs, timing constraints andother critical design information. Referencing multiplelibraries is allowed, for example to direct the PT to a corecell library, a memory library, and a pad cell library. Alllibraries referenced in the netlist must be “visible” to the PTas 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 ModelsBlack box models are timing models for hard macros or IP,including RAM, ROM, microprocessors, microcontrollers,and analog blocks. Hard macros or IP are generally toocomplex to be modeled as a library cell and are thusmodeled using the Synopsys Liberty, Synopsys extractedtiming or STAMP formats and then compiled into theSynospys .db format. PT can read Synopsys .db formatdirectly. Black box models In addition to containing containpin information and input to output timing paths, black boxmodels must present a complete description of timingperformance and possible modes of operation (for example,read versus write modes in a memory element).

Synopsys Liberty and extracted timing models must becompiled in PT prior to analysis. This can be accomplishedwith 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 modeland 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 usedfor modelling timing of complex and analog blocks.

Important: Note that all customer-created models mustbe made available to AMIS at time of design hand-off inLiberty, STAMP .mod and .dat, or compiled .db format.

ClocksAll clocks used or referenced in the design must bespecified. This includes definitions for system-level clocksand internally generated clocks along with theircorresponding period, waveform characteristics (rise and falltimes), latency, skew, transition time and source point.

System ClocksSTA supports analysis of the synchronous portion of adesign, analyzing paths between sequential devices andports. System clocks are those clocks that originate atprimary input ports of the chip.

The clock cycle time, rise and fall transitions within the cycle(duty cycle), and primary input port where the clockoriginates must be known for all system clocks (primaryclock inputs). The PT “create_clock” command is used tospecify system clocks for the design. Figure 3.1 shows adiagram of the required clock information. The followingcommand shows the corresponding PT specification for theclock shown in figure 3.1.

pt_shell> create_clock -period 20 -waveform {0 10} CLK

Figure 3.1 Diagrammatic view of required clock information.

CHIPBOUNDARY

CHIP

CLK


AMI Semiconductor7

www.amis.com

Important: Note that all system clocks, their correspondingports, cycle times, and waveforms are required.

Derived ClocksA design may include internal clock dividers or otherstructures that produce new clock signals from a systemclock. These types of clocks are referred to as generated

clocks or derived clocks. Derived clocks have to be definedsince PT cannot determine skew and frequency due tocomplex connectivity and the use of sequential devices inthe clock path. Derived clocks can be derived from anysystem clock or other derived clocks in the design. Figure3.2 shows example waveforms of system and divide-by-2generated clocks.

The PT “create_generated_clock” command is used tospecify internally generated clocks in the design. Thecommand requires the specification of the instance name ofthe device which generates the clock, instance pin namewhere the clock originates, clock reference name (the clockused to create the generated clock), the name of thegenerated clock signal, and the type of clock generationscheme that is being used (for example, divide-by, multiply,

or the frequency of the generated clock and the transitiontimes of the rising and falling edges within the cycle). Figure3.3 shows a diagram of the required clock information. ThePT command below corresponds to the example shown infigure 3.3.

pt_shell> create_generated_clock -name DIVLCK -sourceCLK -divide_by 2 FF_INST/Q

Figure 3.2 System and divide-by-2 generated clocks.

Figure 3.3 Internally generated clocks.

CHIPBOUNDARY

CHIP


AMI Semiconductor8

www.amis.com

Important: Note that all derived clocks and theircorresponding source clocks, as well as origination point(cell instance and pin), cycle times and waveforms, arerequired.

Gated ClocksA gated clock signal is a clock signal where the clocknetwork contains combinational logic other than invertersand buffers. For example, if a clock signal drives one inputto a logic AND gate and a control/data signal is connectedto other input, the output of the AND gate is a gated clocksignal. PT will automatically run setup and hold checks oncombinational gates in a clock path or warn of theirexistence. The gating device is treated similarly to asequential device. Performing a setup check ensures thecontrolling signal is stable prior the active edge of the clock,thereby avoiding “clipping” of the gated clock signal. Thehold check ensures that the controlling signal is stable forthe 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 gatingdevices. It also shows the period during which the controlsignal can move with respect to the clock to avoidviolations.

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 AMISregisters are rising edge triggered. The setup is checkedagainst the active edge of the clock: usually the rising edgefor AMIS registers. This type of setup and hold checkingrequires that the control/data signal remain stable duringthe clock pulse immediately following the active edge of theclock signal. This is usually the high pulse for AMISregisters. Therefore, the control signal can only changeduring the inactive pulse of the corresponding clock. SeeFigure 3.4.

Clock Cycle and WaveformThe clock cycle or clock period is the time required for theclock signal to repeat. The clock waveform consists of thepoints in time, during the clock cycle, where the clock signalrises and falls.

Clock LatencyLatency is the delay in the clock path, and comprises twocomponents: source latency and network latency. Sourcelatency is the time a clock signal takes to propagate from itsideal waveform origin point to the clock definition point inthe design. Network latency is the time a clock signal (riseor fall) takes to propagate from the clock definition point toa register clock pin. Network latency is often referred to asinsertion delay.

PT provides two alternative methods for representing clocklatency:1) Automatically compute latency by propagating delaysalong the clock network. This option is generally used afterclock-tree synthesis when the clock network is completelybuffered.

2) Estimated clock latency set using PT commands. Thisgenerally takes place prior to clock-tree synthesis.

System clocks have ideal waveforms that ignore the delayeffects of the clock network. Often, during pre-layout, theclock network is not completely defined. This requires thatlatency and skew be defined in order for the timing analysisto be accurate.

Latency is simply delay in the clock line and must beestimated and applied to the clock during pre-layout timinganalysis. If the gate-level netlist is generated throughsynthesis, the clock network should be unbuffered. In thiscase the clock node will appear similar to Figure 3.5 and willbe overloaded, resulting in timing violations. Therefore, thelatency in the clock line must be estimated and applied inthe static timing analysis to mimic the expected latency ofthe clock network after clock-tree synthesis and layout.

Figure 3.4 Gated clock constraints.


AMI Semiconductor9

www.amis.com

For example, if the clock latency of the clock network isestimated to be about 4.0ns, then the latency should bespecified with the PT “set_clock_latency” command asshown below. One method of estimating the prelayoutclock latency is using the ACCESS compute-clock-buffer-parameters tool. The latency reported by compute-clock-buffer-parameters can be used directly in theset_clock_latency command. After the clock tree has beeninserted in the design, the latency can be calculated directlyusing the PT “set_propagated_clock” command. Thecommand below exemplifies the clock latency specificationin PT.

pt_shell> set_clock_latency 4.0 [get_clock CLK]

Important: Note that the expected clock latency isrequired for all system clocks in the design.

Clock SkewClock skew is the difference between the arrival time ofclock signals at different registers in one clock domain orbetween clock domains.

Similar to clock latency, PT provides two methods forrepresenting clock skew:1) Automatically compute skew by propagating delays

along the clock network. This option is generally usedafter clock-tree synthesis when the clock network iscompletely 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, theskew must be estimated and applied to the clock node forcorrect timing analysis. A value of 400ps is a good estimatefor the clock skew if the AMIS clock tree synthesis flow isbeing used. Application engineers and design engineers atAMIS can provide further assistance if required. After theclock tree has been inserted into the design, the skew canbe calculated directly with the PT “set_propagated_clock”command. The command below exemplifies the clock skewspecification in PT.

pt_shell> set_clock_uncertainty 0.4 -setup [get_clock CLK]

Important: Note that the expected clock skew is requiredfor all clock domains in the design.

Figure 3.5 Unbuffered clock network.


AMI Semiconductor10

www.amis.com

Clock Transition TimeThe delay calculator built into PT automatically computesthe transition times of core ports, cells and nets. Transitionis also known as slew. Primary input ports or pad cells arean exception to this rule, as their input transition times are afunction of the external driver and therefore must bespecified.

Similar to latency and skew, PT provides two methods ofrepresenting clock transition.1) Automatically compute transition by propagating delaysalong the clock network.

2) Estimated clock transition times manually set using PTcommands. This generally takes place prior to clock-treesynthesis and if the Standard Delay Format (SDF) data is notbeing annotated.

Careful specification of clock transition is critical during pre-layout where a clock tree is not present in the design. If thegate-level netlist is generated through synthesis, the clocknetwork will be unbuffered. In this case the clock node willbe overloaded resulting in long “clock to q” times in thoseregisters driven by the clock. Excessive clock to q timesresult directly from the slow transition times present at theclock pins of the registers. Therefore, the transition time ofthe clock node must be estimated and specified in the statictiming analysis, to mimic the actual transition time of theclock network after clock tree insertion and layout.

The pre-layout clock transition time may be estimated usingthe ACCESS “compute-clock-buffer-parameters” tool. Thetransition time reported by this tool could be used directlyin the PT “set_clock_transition” command. For moreinformation about running compute-clock-buffer-parameters, see the ACCESS documentation. After theclock tree has been inserted into the design, the clocktransition times can be calculated directly using the PT“set_propagated_clock” command.

Contact the factory for additional information regardingestimated clock latency, transition, and skew parameters.

Design AssertionsDesign assertions include clocks and clock network delayinformation as described above. Design assertions alsoinclude external input delay, external output delay, wireloadmodels, operating conditions, physical interconnectparasitic data, SDF, etc.

Wireload ModelA wireload model estimates the wire loading responsible forwire delays prior to placement and routing. Various

wireload models are provided in the technology library andone must be specified if generating timing with the STAtool. Wireload models of varying accuracy can be createdand used during different phases of the design.

Pre-Layout Estimated Wire CapacitancePrior to floorplanning or layout, wireload models are basedon fanout and area. These models are generated withstatistical data and are located in the technology library.AMIS wireload models estimate interconnect capacitanceonly. The PT “set_wire_load_model” command is used toset the wireload model to be used during pre-layout STA.

pt_shell> set_wire_load_model -library ami350lxsc3 -name400

The wireload model names in the standard cell technologylibraries translate directly to the corresponding die size. Thewireload model names in the gate array technology librariesare slightly different.

Important: Note that the expected die size and/orwireload model are both required for static timinganalysis.

Post-Layout Wire CapacitanceAfter routing, exact wire lengths and capacitances can beannotated into PT in the form of a parasitic file (SPEF)and/or SDF.

Operating ConditionsOperating conditions are used to specify any applicableprocess derating factor, as well as the operatingtemperature, operating voltage and an interconnect modeltype. Note that operating conditions must be specified inPT if the tool is to generate timing information.

The operating conditions are defined in the technologylibraries and include conditions such as; BEST-CASE-SPEED-COMMERCIAL (BCC), BEST-CASE-SPEED-INDUSTRIAL(BCI), BEST-CASE-SPEED-MILITARY (BCM), WORST-CASE-SPEED-COMMERCIAL (WCC), WORST-CASE-SPEED-INDUSTRIAL (WCI), WORST-CASE-SPEED-MILITARY(WCM), and TYPICAL (TYP). Operating conditions aretechnology specific. The PT “set_operating_conditions”command is used to set the operating conditions for thedesign.

pt_shell> set_operating_conditions -analysis_type bc_wc -lib ami350lxsc3 -max WCI -min BCI

Important: Note that the required device operatingconditions must be provided.


AMI Semiconductor11

www.amis.com

Input Delay The arrival time at an input port is typically relative to anexternal clock edge and mimics an external sequential datalaunching device. The external clock may either be thesame clock that is used in the design, or a virtual clock.Input delay should include the clock to q delay of theexternal launching device and any delay in the logic drivingthe input port. Figure 3.6 provides a visual representation ofinput delay.

Input delay on clock ports should be regarded as clocksource latency and should be treated differently than inputdelay on data ports. Clock source delay for system clocks isseldom used in the AMIS flow.

Input delay could be considered a percentage of the clockcycle required for the data to arrive at the port from theexternal launching register.

For example, in the circuit shown in Figure 3.6, the risingedge of the clock will launch data at the external register.The input data delay will then consist of the clock to q timeof the external register plus the delay through the logicprior to the input port of the chip. Assuming the clock cycleis 10ns, then if this external typical delay is 7ns, then theinput delay is 70% of the clock cycle. This indicates that30% of the clock cycle time, or 3ns, is available for the datato travel from the input port through the chip input logic tothe data pin of the input capture register if it is to meet the

setup time of the input register. The PT “set_input_delay”command is used to specify input timing constraints forinput data ports, as shown:

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 theclock driving the external register are required for eachdata port in the design. The clock driving each externalregister must also be specified.

Figure 3.6 Calculating input delay.

CHIPBOUNDARY

CHIP


AMI Semiconductor12

www.amis.com

Output DelayThe time requirement of an output port is relative to anexternal clock edge and mimics an external sequential data-capturing device. The external clock may be the same clockthat is used internally to the design or it could be a virtualclock. An output delay represents an external timing pathfrom an output or I/O port to an external register. Themaximum output delay value should be equal to the delay

of the longest path from the output port through anyexternal logic to the external register data pin, plus thesetup time of that register. The minimum delay should beequal to the length of the shortest path from the outputport through any external logic to the register data pin,minus the hold time. Figure 3.7 provides a visualrepresentation of output delay.

The PT “set_output_delay” command is used to specifyoutput delay timing, as follows:

pt_shell> set_output_delay -max -clock [get_clocksCLKPAD] 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 ofthe clock driving the external register are required foreach output port in the design. The clock driving theexternal register must also be specified.

Figure 3.7 Calculating output delay.

CHIPBOUNDARY

CHIP


AMI Semiconductor13

www.amis.com

SDFStandard Delay Format (SDF) contains cell and interconnectdelay for the circuit. SDF can be generated from a numberof sources. PrimeTime is the only accepted source of SDFfiles for XPA designs and SC designs below 0.25µm. in allother cases, ACCESS is the only accepted source of SDFdata. SDF is loaded into PT subsequent to loading thenetlist and provides the tool with the circuit timing andstate device constraints.

Physical DataPhysical data includes custom wireload models fromfloorplanning, as well as extracted interconnect parasiticinformation from routing.

Design ExceptionsWhen determining maximum and minimum delayrequirements, PT assumes single-cycle timing for all paths ina design. Single-cycle timing means that data propagates toits destination, or is expected to arrive at its destinationpoint, in one clock cycle. Figure 3.8 shows D1 beinglaunched at edge 0 of CLKL and D2 being captured at edge1 of CLKC. The data is launched at edge 0 and captured atedge 1, propagating within a single clock cycle.

In some situations, single-cycle timing may not beappropriate or achievable. For example, a path may requiremore than one clock cycle to propagate, or may start andend with the same clock edge. It is also possible that thepath may be false. There are three exceptions that overridethe default single-cycle timing. These are false paths, multi-cycle paths and zero-cycle paths.

Multi-Cycle Paths and Zero-Cycle PathsMulti-cycle paths are those paths that require more thanone clock cycle to propagate. Zero-cycle paths are thosepaths that are launched and captured with the same clockedge, or that are skewed due to large interconnect delaysor intentional signal skewing techniques. Figure 3.9illustrates a multi-cycle path. Assuming the clock cycle is2ns and the delay through the buffer in the clock line is3.2ns, the data will arrive at the capture register in thesecond clock cycle at clock edge 2 in the CLKC waveform ofFigure 3.9.

Figure 3.8 Single-Cycle timing.


AMI Semiconductor14

www.amis.com

The PT “set_multicycle_path” command is used to specifymulti-cycle paths as follows:

pt_shell> set_multicycle_path 2 -setup -from FF1/C -toFF2/D

Important: Note that the paths in the design that requiremore than one clock cycle to propagate must bespecified at time of design hand-off. The informationrequired is the instance name of the register where the

path begins, the instance name of the register where thepath ends, and the number of clock cycles required forthe data to propagate.

Figure 3.10 illustrates a zero-cycle path. Assuming the clockcycle is 2ns and the delay through the buffer in the clockline is larger than the clock-to-q delay of FF1, the data willbe captured at FF2 by the same clock edge that launchesthe data from FF1 (edge 0 of CLKC).

Figure 3.9 Multi-Cycle path.

Figure 3.10 Zero-Cycle Timing.


The PT “set_multicycle_path” command is used to specifyzero-cycle paths as follows:

pt_shell> set_multicycle_path 0 -setup -from FF1/C -toFF2/D

Important: Note that all paths in the design that requirezero clock cycle to propagate must be declared. Theinformation required is the instance name of the registerwhere the path begins and the instance name of theregister where the path ends.

False PathsFalse paths are those logic paths that exist but cannot besensitized, 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 andcaptured by unrelated clocks or asynchronous clocks.

The PT “set_false_path” command is used to specify falsepaths as follows:

pt_shell> set_false_path -from FF1/C -to FF2/D

Important: Note that the false paths in the design mustbe provided. The information required is the instancename of the register and pin where the path begins andthe instance name of the register and pin where the pathends.

AnalysisStatic timing analysis exhaustively computes path timing forthe ASIC design and compares the timing against theinherent design constraints based on the assertions andexceptions set by the designer. These constraints includesetup, hold, pulsewidth, recovery and removal. Prior tocommencing analysis, all paths in the design should havebeen constrained. PT allows for several types of analysis, asdescribed in the following paragraphs.

Single Operating Condition AnalysisAnalysis is performed with timing values for a singleoperating condition. For example, if reading the worst casetiming numbers from an SDF file, setup and hold checks are

calculated using only the worst case timing numbers. Twoanalysis runs would be required. The first run would checkfor setup violations using worst case timing numbers,followed by a second run to check for hold violations withbest case timing numbers.

Best/Worst Case Operating Conditions AnalysisIn this case, both the minimum and maximum operatingconditions are specified. When reading the SDF for thistype of analysis, PT reads both the best case timingnumbers and the worst case timing numbers. Best casenumbers are used when checking for hold violations andworst case numbers are used when checking for setupviolations. Best/worst case analysis is more efficient thansingle operating condition analysis since setup and holdchecking is completed in a single run.

Case AnalysisCase analysis allows timing analysis to be performed usinglogic constants or logic transitions (rising or falling) on portsor pins, to limit the signals propagated through the design.It can also be used for enabling or disabling conditional arcsfrom Liberty or STAMP models. Constants are propagatedforward through the design. PT automatically detects pinstied high and low, and propagates the value. Case analysisis a path-pruning mechanism and is most commonly usedfor timing the device in a given operational configuration orfunctional mode. For example, case analysis can be used tocompare normal circuit operation against scan or BISToperation.

For exhaustive analysis of the design, every functional modeof operation should be analyzed. Depending on thecomplexity of the circuit, this can become time consuming.By providing comprehensive information at the earlieststages of timing analysis, a more complete analysis can beaccomplished quickly and efficiently. Figure 3.11 illustratesfunctional modes and the information needed to analyzethe circuit in a particular mode. The circuit has two modesof operation: scan mode and normal operating mode. If aconstant high value is placed on the port "SCNMODE" thecircuit is in scan operation. A constant low value will placethe circuit in normal operation.

AMI Semiconductor15

www.amis.com

Figure 3.11 Exercising multiple functional modes.


AMI Semiconductor16

www.amis.com

****** 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 librariesset 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 pathset link_path "* amih180xxgca_max.db amih180xxgea_max.db amih180xxgma_max.db amih180xxpr3_max.db"read_verilog netlist_prelayout.vcurrent_design TOPlink

# 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_maxset_wire_load_model –name XP568E –library amih180xxgca_maxset_load 50 [all_outputs]

The PT “set_case_analysis” command is used to specifydesign nodes with constant values and different functionalmodes 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 modesrequiring analysis must be specified. The informationrequired must include the mode-select values, as well asthe ports, pins, or nets in the design at which each mode-select value should be applied, in order to put the designin a particular mode of operation.

Mode AnalysisComplex components (usually proprietary or third-party IPblocks) may have multiple timing paths that are dependenton 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 thetiming of all paths, regardless of the functional mode.However, the designer may need to analyze the timing of aspecific mode that disables timing arcs that do not occur inthe given mode. Component modes must be coded intothe Liberty or STAMP component model to be used. Modesare most common in Liberty and STAMP memory models.The PT “set_case_analysis” command can also be used forsetting the mode of a component if the mode is definedand conditional on the state of a controlling pin. The PT“set_mode” command should be used when modes aredefined but condition association is not used.

Violation ChecksPT can perform the following timing checks: • Data Setup

The setup time for each logic state at the data pin of eachsequential device is checked. The setup time can bedefined in relation to the rising or falling edge of thecorresponding sequential device clock signal.

• Data Hold The hold time for each logic state at the data pin of eachsequential device is checked. The hold time can bedefined in relation to the rising or falling edge of thecorresponding sequential device clock signal.

• Set/Reset RecoveryThe recovery check is similar to the data setup check andrepresents the minimum time that the asynchronous set orreset pin must be stable after being deasserted, andbefore the next active clock edge transition.

• Set/Reset RemovalThe removal check is similar to the data hold check andrepresents the minimum time that the asynchronous set orreset pin must be stable before being deasserted andafter the previous active clock edge transition.

• Minimum Pulse Width Minimum pulse width is checked for each sequentialdevice 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 maketiming reports very difficult to understand.

4.0 Example Scripts


# 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 portscreate_clock -period 10.0 -waveform {0 5.0} [get_ports CLK]# virtual clock for port timingcreate_clock -name VCLK -period 10.0 -waveform {0 5.0}# generated clocks definitions – clocks originating inside the design from another clockcreate_generated_clock –name GENCLK –source [get_ports CLK] –divide_by 2 [get_pins DFLOP/Q]

# clock specsset_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 customerset_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 DFTset_false_path -from [get_ports {TDI}]set_false_path -to [get_ports {TDO BISTDONE}]# functional bypass mode, set at the outputs of the TAP controllerset_case_analysis 0 TRSTNset_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]

# reportscheck_timing –v > check_timing_setup.rptcheck_timing –no_clock > no_clocks_max.rptreport_constraint –max_delay –all_violators > setup_short.rptreport_constraint –max_delay –all_violators -verbose > setup.rptreport_constraint –recovery –all_violators > recovery_short.rptreport_constraint –recovery –all_violators -verbose > recovery.rpt

# MIN CORNERremove_design –allset link_path "* amih180xxgca_min.db amih180xxgea_min.db amih180xxgma_min.db amih180xxpr3_min.db"read_verilog netlist_prelayout.v

AMI Semiconductor17

www.amis.com


AMI Semiconductor18

www.amis.com

current_design TOPlink

# 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_minset_wire_load_model –name XP568E –library amih180xxgca_minset_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




# 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 customerset_output_delay -1.5 -clock VCLK [all_outputs]




AMI Semiconductor19

www.amis.com

# reportscheck_timing –v > check_timing_hold.rptcheck_timing –no_clock > no_clocks_min.rptreport_constraint –min_delay –all_violators > hold_short.rptreport_constraint –min_delay –all_violators -verbose > hold.rptreport_constraint –removal –all_violators > removal_short.rptreport_constraint –removal –all_violators -verbose > removal.rpt

****** Scan pre-layout PT script ******





# 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_maxset_wire_load_model –name XP568E –library amih180xxgca_maxset_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




# boundary constraints# set input constraints# 1.0/0.9 min/max input constraints at 100Mhz spec-ed by customer


AMI Semiconductor20

www.amis.com

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 customerset_output_delay 4.5 -clock VCLK [all_outputs]


set_false_path -to [get_ports BISTDONE]# functional bypass mode, set at the outputs of the TAP controllerset_case_analysis 0 TRSTNset_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]

# reportscheck_timing –v > check_timing_scan_setup.rptcheck_timing –no_clock > no_clocks_scan_max.rptreport_constraint –max_delay –all_violators > setup_scan_short.rptreport_constraint –max_delay –all_violators -verbose > setup_scan.rptreport_constraint –recovery –all_violators > recovery_scan_short.rptreport_constraint –recovery –all_violators -verbose > recovery_scan.rpt

# MIN CORNERremove_design –allset link_path "* amih180xxgca_min.db amih180xxgea_min.db amih180xxgma_min.db amih180xxpr3_min.db"read_verilog netlist_prelayout.vcurrent_design TOPlink

# 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_minset_wire_load_model –name XP568E –library amih180xxgca_minset_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


# clock specsset_clock_uncertainty 0.05 get_clock CLK]set_clock_latency 3 [get_clocks CLK]


AMI Semiconductor21

www.amis.com

set_clock_transition 0.4 [get_clock CLK]




set_false_path -to [get_ports BISTDONE]# functional bypass mode, set at the outputs of the TAP controllerset_case_analysis 0 TRSTNset_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]

# reportscheck_timing –v > check_timing_scan_hold.rptcheck_timing –no_clock > no_clocks_scan_min.rptreport_constraint –min_delay –all_violators > hold_scan_short.rptreport_constraint –min_delay –all_violators -verbose > hold_scan.rptreport_constraint –removal –all_violators > removal_scan_short.rptreport_constraint –removal –all_violators -verbose > removal_scan.rpt

****** Functional post-layout PT script ******





# 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 cleanreport_annotated_delay –list_not_annotated –cell > annotated_delay_max.rptreport_annotated_check –list_not_annotated > annotated_check_max.rpt


AMI Semiconductor22

www.amis.com

# loading on outputs not needed, since it was specified during SDF generation


# propagate the clocksset_propagated_clock [all_clocks]

# clock specsset_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 customerset_output_delay 4.5 -clock VCLK [all_outputs]



# reportscheck_timing –v > check_timing_setup.rptcheck_timing –no_clock > no_clocks_max.rptreport_constraint –max_delay –all_violators > setup_short.rptreport_constraint –max_delay –all_violators -verbose > setup.rptreport_constraint –recovery –all_violators > recovery_short.rptreport_constraint –recovery -verbose –all_violators > recovery.rpt

# MIN CORNERremove_design –allset link_path "* amih180xxgca_min.db amih180xxgea_min.db amih180xxgma_min.db amih180xxpr3_min.db"read_verilog netlist_prelayout.vcurrent_design TOPlink

read_sdf -load_delay cell -analysis_type single -type sdf_min btw.sdf# make sure the SDF annotated cleanreport_annotated_delay –list_not_annotated –cell > annotated_delay_min.rptreport_annotated_check –list_not_annotated > annotated_check_min.rpt


AMI Semiconductor23

www.amis.com


# propagate the clocksset_propagated_clock [all_clocks]

# clock specsset_clock_uncertainty 0.05 get_clock CLK]set_clock_uncertainty 0.05 [get_clock GENCLK]




# reportscheck_timing –v > check_timing_hold.rptcheck_timing –no_clock > no_clocks_min.rptreport_constraint –min_delay –all_violators > hold_short.rptreport_constraint –min_delay –all_violators -verbose > hold.rptreport_constraint –removal –all_violators > removal_short.rptreport_constraint –removal –all_violators -verbose > removal.rpt


AMI Semiconductor24

www.amis.com

The ideal scenario for STA is a completely synchronousdesign having a single clock domain, no internallygenerated clocks (divide-by or otherwise), no feedbackloops, no clock gating, no additional test logic, nomulticycle paths or false paths, etc. These types of designsare seldom encountered. In order to maximize theefficiency and speed of STA, restrictions must be imposedon design styles and methodologies. The followingguidelines should be borne in mind.

1) Run separate STA for different modes of circuit operationsuch as functional mode, scan mode, BIST, etc. Createseparate timing scripts for each mode of operation that canbe used repetitively, since STA is run throughout the designflow. Test mode pins and logic values should bedocumented to further assist STA of all operational modes.If a JTAG controller is used, case analysis can be used onthe outputs of the instruction registers to put the designinto a given mode. The following example constrains thedesign for functional mode STA (BYPASS mode) whereJTAG, scan, BIST, and nandtree test structures have beeninserted 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 BISTand scan are inserted and controlled by primary designports. In this scenario, case analysis must be specified onthe test ports to constrain the design.

2) Avoid combinational feedback loops. Combinationalloops are asynchronous since the signal must often iterateseveral times through the loop before settling to its finalvalue. Combinational loops must be verified with dynamicsimulation. Most combinational loops can be replaced withsynchronous logic. The Design Compiler will issue warningswhen combinational loops are encountered duringsynthesis. Unavoidable combinational loops should beisolated in a block of hierarchy and simulated to verifytiming. PT breaks loops by disabling a timing arc that willleast affect other paths. Figure 5.0 represents a timing loopand location where PT will break the loop (arc b to q wherethe arrow is located in the OR gate).

5.0 Recommended Design Practices

Figure 5.0 Disabling a timing arc to break a combinational loop.

3) Avoid self-timed and master/slave circuitry. This isasynchronous logic that must be simulated separately.

4) Understand asynchronous clock domains, minimizegenerated clocks, and minimize clock domains in general.Best design practice is to avoid clock domains, internallygenerated clocks and cross clock domain paths wherever

possible. Generated clocks pose a problem when they arenot documented and result in unconstrained sections of thedesign. A fixed phase relationship must exist between thestartpoint and endpoint clocks that cross clock domains.Clocks may be single phase, multiple phase, or multiplefrequency devices.

Logic Loop


AMI Semiconductor25

www.amis.com

In the case of multiple frequency clocks, the designer mustpay attention to the base period over which the clockwaveforms repeat. The base period is defined by thelowest common multiple of the all clock periods. If this baseperiod is more than ten times larger than the shortest clockperiod, long runtimes and excessive memory requirementswill result.

For example, if a register with a 10ns clock feeds anotherregister with a 10.1ns clock, there is no reasonable baseperiod. PT will attempt to find a base period and phaserelationship, resulting in excessive memory consumption

and runtime. Consequently the resulting setup requirementis very restrictive. These types of paths should be verifiedwith simulation and considered asynchronous during STA. Ifthe clocking schemes are understood, considerable timecan be saved during STA. Figure 5.1 illustrates how PTtreats a path crossing multiple frequency clock domain.

pt_shell> create_clock –period 4 –waveform {3 4} [get_portsCLK1]pt_shell> create_clock –period 3 –waveform {1 2} [get_portsCLK2])

PT can analyze paths clocked by single phase, multiplephase, and multiple frequency clocks. However, for eachpath, a fixed phase relationship must exist between thestartpoint and endpoint clocks. Clocks that do not have afixed phase relationship are considered asynchronous. It isimportant to remember that if paths between clocks havedifferent frequencies, there must be an acceptable baseperiod over which all clock waveforms repeat.

If no such period can be determined, clock paths such asthese can be pruned from analysis by setting false pathsbetween the clocks. The timing for these paths would thenneed to be verified with dynamic simulation.

5) Identify and document clock gating devices. The nameof each gating structure instance should be documented.PT has the ability to check gating devices where one pin is aclock and all others are data signals. Designers should alsobear in mind the advice given in Section 2.0 of thisapplication note regarding glitch detection. PT does nothandle the scenario where more than one pin of a gate isdriven by a clock signal. This will cause incorrect timing andis usually difficult to uncover because PT does not warn ofthis situation and does not have the ability to determine theresulting clock waveform by combining the multiple inputclock waveforms with the functionality of the gate. Ifmultiple clocks are driving multiple pins of the gate, PT willpropagate through the gate the first defined clock it finds.

6) Determine and document the validity of bi-directionalfeedback loops as early as possible. By default, PT breakspaths through bi-directional I/O cells. If any or all of these

paths are valid, they must be taken into account with thefollowing PT variables:“timing_disable_internal_inout_cell_paths” and“timing_disable_internal_net_arcs”.

With these set to false (checking turned on), the bi-directional feedback paths that are not valid must then beremoved from the timing with false_path orset_disable_timing constraints. The remainder of thefeedback paths will be checked.

7) Identify and document timing exceptions. Exceptionsinclude: false paths; paths that take more than one clockcycle to propagate (multi-cycle path); paths that arelaunched and captured by the same clock edge (zero-cyclepath); combinational loops and the best location to breakthem; asynchronous clock domains; locations of generatedclocks inside the device; any other exceptions defined bythe designer. The designer should provide a complete setof timing exceptions/constraints at the time of design hand-off. If these are not made available, the alternative is tobuild a top-level PT script and attempt to find the timingexceptions through iterations of STA and discussions withthe designer. This makes for unacceptably long verificationcycles.

8) Output loading and I/O constraints. Correct outputcapacitance loading should be defined at the beginning ofany analysis since it affects output timing. I/O constraintsinclude input and output delays external to the design.These values should be specified for all I/Os except primaryclock ports. I/O timing constraints must be specified for PT

Figure 5.1 Multiple frequency clock domain analyzed by Synopsis PT.

setup setup


AMI Semiconductor26

www.amis.com

with regard to external requirements. Input delay is definedas the delay from the clock pin of the external register tothe input port, including any logic delay between theexternal register and the input port. See Figure 5.2.

set_input_delay 4.2 –clock CLK [get_ports P16]

Output delay represents the external timing path from anoutput port to an external register. The maximum outputdelay should be the longest path delay to the register datapin, plus the setup time of the register. The minimumoutput delay should be the shortest delay path to the

register data pin, minus the hold time of the register. SeeFigure 5.3.

set_output_delay –min 1.75 –clock CLK [get_ports OUT1]set_output_delay –max 3.7 –clock CLK [get_ports OUT1]

Figure 5.2 Input delay.

Figure 5.3 Output delay.

© 2003 AMI Semiconductor, Inc.

AMI Semiconductor makes no warranty for the use of its products, other than those expressly contained in the company's standard warranty contained in AMI Semiconductor's Terms andConditions. The company assumes no responsibility for any errors which may appear in this document, reserves the right to change devices or specifications detailed herein at any timewithout notice, and does not make any commitment to update the information contained herein. No licenses to patents or other intellectual property of AMI Semiconductor are granted bythe company in connection with the sale of AMI Semiconductor products, expressly or by implication.

AMI Semiconductorwww.amis.com


Static Timing Analysis (STA) requires the identification oftiming paths throughout an entire design, followed bycalculation of the delay of each path and final comparison ofthe path delay with the path timing constraints specified inthe design.

Large, gate level synchronous designs depend on automatictools capable of carrying out STA, and successful

completion of STA is essential in order for the design topass final signoff. Designers who are aware of guidelinesand best practice in relation to signal timing issues, as wellas the limitations of automatic STA tools, will be bestequipped to submit designs that will meet the specified STAperformance with minimum effort, and proceed quickly tofinal signoff.

7.0 Revision Control

6.0 Conclusion

Date Page Description ContactFebruary 26, 2003 - Initial Publication Khris KoffordMarch 11, 2003 - Reordered sections

Inserted missing graphicsApril 6, 2003 - Incorporated reviewer

comments.

Customers frequently specify output timing to be clock-to-out timing. This is, in fact, the timing from the internaloutput register to the output port. In this scenario, theoutput timing has to be modified slightly to force PT tocheck the constraint correctly. In the event that the outputdelay is given as a clock-to-out specification, the input delayis as described above. The maximum output delay is thedifference between the clock period and the maximumoutput specification. The minimum output delay is –1 timesthe minimum output specification. For example, if the clock-to-out specification is defined as 4ns max. and 1ns min.,where the clock speed is 6.67ns (150MHz), the output delayswould 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 borrowingwhen timing paths to latches, in order to correctly accountfor the duration for which the latch is transparent. Latches

complicate timing analysis and make the reports difficult tounderstand. Use of latches should be avoided wherepossible.

10) Although the timing for RAM, pulse generators andwrite-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 theasynchronous read cycle of some RAMs can be timed ifeither the RAM is properly constrained to the read modeoperation or if the model allows for read timing analysis. Inmost cases, the RAM must be constrained, since the AMISmodels are not built for different modes of operation inSTA. A common flow is to place and route and thensimulate the RAM and pulse generator, subsequentlymodifying the layout to add or subtract delay from the pulsegenerator to achieve the required delay and pulse width tothe RAM’s WE pin.

Static Timing 1

Documents