Slack Calculation[1]

8/16/2019 Slack Calculation[1]

1/14

Application Note

Understanding Slack Calculation inMagma Timing Analysis Mar 2003 version 1.2

Introduction In static timing analysis, slack is the ultimate metric for determining whether atiming path meets the timing constraints placed on the design. Slack is the resultof adding several other pieces of timing information such as required time, arrivaltime, data-path delay, setup or hold time, timing margins, multicycle pathadjustment, and cycle adjustment. While some of these elements are self-explanatory, others are frequently a source of confusion among those trying tounderstand static timing analysis.

This application note explains the elements that contribute to slack in the Magmacentral timing engine. In particular, this document focuses on the less intuitiveideas, like multicycle path adjustment and cycle adjustment. This application notealso addresses time borrowing issues in latch-based designs.

Static Timing Analysis Basics You must understand some basics of static timing analysis beforecomprehending slack calculation. You need a familiarity with topics such as

timing nodes and paths, multicycle paths, and setup and hold time relationshipsbetween multiple clock domains.

Timing PathsThe Magma timer abstracts a gate-level netlist into a series of timing nodes.These timing nodes are connected by timing arcs that describe how the nodesrelate. The timing nodes and the arcs that connect them are the building blocksthat compose a larger construction called a timing path. Clock nodes make upclock paths, and data nodes make up data paths. This document deals primarilywith data paths, because these are the paths where slack is calculated.

Every timing path is defined by a startpoint, an endpoint, and the timing nodesbetween them. A startpoint is normally either a primary input for the design or theoutput of a register cell. An endpoint is normally either a primary output for thedesign or the input to a register cell. Combinational logic makes up the rest of thetiming path between the data startpoint and endpoint.

Mar 2003 1of 14


2/14

Application Note

Multicycle Paths A dynamic timing analyzer feeds a design a vector test set of many possible

input combinations. These vectors propagate through the design over severalclock cycles. The output that result from these input vectors is tested forcorrectness.

Unlike a dynamic timing analyzer, a static timing analyzer does not require aninput set of test vectors. Even the clock is abstracted down to a single cycle. As aresult, the default behavior of the Magma timer, like any other static timinganalyzer, is to assume that data takes one clock cycle to propagate through atiming path.

Sometimes in a design, a chain of combinational logic between two registers istoo long for the data to go from the launching register to the capturing register in

one clock cycle. If you know this is the case, specify a timing constraintdesignating that the timing path is multicycle, using the force timing multicycle command. When you specify an x-cycle path, the Magma timer allots x – 1additional clock cycles for the data to propagate along that path.

Relationships Between Multiple Clock DomainsWhen a design contains multiple clocks and particularly when timing paths travelbetween two clock domains, slack calculation becomes more complicated. TheMagma timer handles setup and hold time relationships between multiple clockdomains differently than within a single clock domain, because the clocks canhave different frequencies.

Harmonic Clocks

Figure 1 introduces an example in which two clocks exist in a design—one with aperiod of 6 nanoseconds and the other with a period of 8 nanoseconds. Becausethese clocks have different frequencies, their timing relationship with each otherchanges. So, for example, the relationship from the rising edge of the 6-nanosecond clock to the rising edge of the 8-nanosecond clock changes as theclocks go in and out of sync with each other.

The Magma timer calculates the worst-case possibility resulting from thisphenomenon using the least common multiple (LCM) of the periods of the two

clock cycles. The LCM represents the point when the cyclic relationship betweenthe two clocks repeats. In this example, the LCM is 24 nanoseconds, becausethe clocks have matching rising edges at 0 nanoseconds, and again at 24nanoseconds.

Mar 2003 2of 14


3/14

Application Note

Figure 1: Harmonic Clock Relationship

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

If two clocks do not have a harmonic integral relationship with each other, thecalculated LCM can grow very large, because it takes the clocks many cycles toharmonize again. The LCM of two clocks is calculated within a certain tolerance.If you are unable to harmonize your clocks, one solution is to use the configtiming clock tolerance command to change the tolerance, whichdefaults to 10 picoseconds.

Note: Increasing the LCM threshold also introduces inaccuracies into thecalculation, so exercise caution.

Interclock Setup Relationships

Setup timing checks are complicated by the existence of multiple clocks,particular clocks with different periods. Because the relationship between the twoclocks changes, depending on their relative point in the cycle, the Magma timermust examine all relationships between the launching and receiving clock edges.Figure 2 contains the same clocks as Figure 1, but now a setup check isperformed from the falling edge of the first clock to the rising edge of the secondclock.

The setup relationship is the shortest time, greater than zero, from the launchingclock edge to the next receiving clock edge. In Figure 2, four checks must bemade to determine the setup relationship. The results of these checks, which youcan verify by examining Figure 2, are 8 – 3 = 5 nanoseconds, 16 – 9 = 7

nanoseconds, 16 – 15 = 1 nanosecond, and 24 – 21 = 3 nanosecond. Theshortest check is 1 nanosecond, so this is the setup relationship between thesetwo clocks—from the falling edge of the first to the rising edge of the second.

The setup relationship shows you how much budgeted time the data has to travelfrom the launching to the receiving register. Factors, such as data-path delay andsetup time for the receiving register, must be subtracted from this value todetermine whether timing is met on that path. These topics are discussed later in

Mar 2003 3of 14


4/14

Application Note

this document. Also note that the setup relationship is the shortest time from thelaunching clock edge to the next receiving clock edge, because this is the worst-case possibility.

Figure 2: Setup Relationship

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Interclock Hold Relationships

Like setup relationships, the Magma timer must also determine hold relationshipsbetween multiple clock domains. The process is almost identical, with one keydifference: The hold relationship is the shortest time between the launching clockedge and the previous receiving clock edge. Figure 3 illustrates a holdrelationship between the first clock’s rising edge and the second clock’s rising

edge. In this case, the hold checks are 18 – 16 = 2 nanoseconds, 12 – 8 = 4nanoseconds, 6 – 0 = 6 nanoseconds, and 0 – 0 = 0 nanoseconds. Unlike setuprelationships, which must be greater than zero, a hold relationship can be zero.

Figure 3: Hold Relationship

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Mar 2003 4of 14


5/14

Application Note

Understanding SlackYou use the report timing path command to view timing paths. By default, thisreport returns the path with the worst slack in the design. The report gives

information about the timing paths for the launching clock, receiving clock, andthe data path. It also gives a breakdown of how slack is calculated for thatparticular data path. Various options allow you to look at multiple paths with avariety of starting, ending, and intermediate timing nodes in late mode, earlymode, or both.

Example 1 shows a typical output of the report timing path command.Specifically, examine the part of the report pertaining to slack calculation for thereported timing path. The example is an excerpt of the 26 th worst path for aparticular design. The registers in this path that launch and receive the signal(the startpoint and endpoint) belong to different clock domains. This adds somestrange details to the slack calculation that this application note addresses in

more detail later.

Example 1: Output of the report timing path Command#### Path 26

###################################################

Start reg2/L2

End scan3/D

Reference scan3/E

Path slack 1445p

Reference arrival time 500

+ Cycle adjust (clk2:F#1 vs. clk1:R#2) 2000+ Multicycle path adjust 2000

- Margin -150

- Setup time -307

-------------------------------------- ----

End-of-path required time (ps) 4043

Starting arrival time 1800

+ Clock path delay 200

+ Data path delay 598

-------------------------------------- ----

End-of-path arrival time (ps) 2598

The output gives details about the clocks that launch and receive the data signal,referred to as the starting clock and the reference clock, respectively. Thisassumes that the path is register bound, meaning that it begins and ends at aregister. If the path is not register bound, either the startpoint or the endpoint ofthe path is a primary I/O In such a case, the path report does not containinformation for the starting clock and reference clock, because the informationdoes not exist.

Mar 2003 5of 14


6/14

Application Note

Dissect the slack calculation portion of the report, given the following timingconstraints:

force timing clock $m/clk1 2n

force timing clock $m/clk2 3nforce timing multicycle –from $m/clk1 –to $m/clk2 –cycles 2

force timing multicycle –from $m/clk1 –to $m/clk2 –cycles 2

force timing margin setup 150p –from $m/clk2 –jitter

force timing latency $m/clk1 200p –type network

force timing latency $m/clk2 200p –type network

force timing latency $m/clk1 300p –type source

force timing latency $m/clk2 300p –type source

You have a two-clock design—one with a period of 2 nanoseconds and the otherwith a period of 3 nanoseconds. A multicycle relationship exists between thesetwo clock domains, so any data launched by one clock and captured by the other

has two cycles to traverse the data path. 150 picoseconds are specified for thePLL generating clk2. Also, 200 picoseconds of network latency and 300picoseconds of source latency are specified for both clocks. I/O timingconstraints are omitted from this list, because you are dealing only with registerbound paths.

Note: This discussion assumes that you are dealing with late mode timinganalysis. Find a brief discussion of early mode timing analysis later inthis application note.

SlackIn static timing analysis, slack indicates whether timing is met along a timingpath. A positive slack means that the signal can get from the startpoint to theendpoint of the timing path fast enough for the circuit to operate correctly. Anegative slack means that the data signal is unable to traverse the combinationallogic between the startpoint and the endpoint of the timing path fast enough toensure correct circuit operation.

In late mode analysis, slack is the difference between the required time and thearrival time for the timing path. The time that a signal needs to arrive at theendpoint of the path to ensure that timing is met is called the required time. Thetime that the signal actually arrives at the endpoint is called the arrival time. I

In the path report, required time is called end-of-path required time and arrivaltime is called end-of-path arrival time. This is to differentiate them from thestarting arrival time and reference arrival time, which are discussed in the nextsection.

Mar 2003 6of 14


7/14

Application Note

Because slack is the required time minus the arrival time, a negative slackindicates that the signal arrives at the endpoint later than the time it needs to bethere, and vice-versa for positive slack. Next, consider the timing componentsthat contribute to the required time and the arrival time.

Starting and Reference Arrival TimesUnfortunately, the starting and reference arrival times do not truly parallel eachother, because they are reported inconsistently by report timing path. Thefollowing sections discuss each one separately, and you can see how the netresult is the same.

Reference Arrival Time

Reference arrival time, as reported by the report timing path command,

indicates when the reference clock signal arrives at the endpoint register. Thereference clock carries the receiving clock edge for the timing path. There arethree components that contribute to reference arrival time:

• Clock source latency

• Clock network latency

• Clock phase

Clock source latency indicates the clock signal delay before arriving on the chip.Clock network latency indicates the delay in the clock path between the boundaryof the chip and the clock pin on the register. Added together, these two

components give an indication of the delay in the clock tree from the PLL to thecapturing register’s clock pin, assuming no clock jitter.

Clock source and network latency, when you specify them as timing constraints,are your best guess at what the actual source and network latency will be in thecircuit. Use these values only in ideal clock mode. When the Magma softwareestablishes some information about the physical layout of the clock tree, thesevalues are ignored as the Magma timer switches to computed clock mode. Incomputed clock mode, the analyzer uses placement and routing information toestimate the delays in the clock trees.

Clock phase is the third contributor to reference arrival time. In static timing

analysis, all clock information is abstracted down to a single cycle. A clockconstraint is declared in relation to an absolute time zero, and the clock phase isrelative to this time origin. For example:

force timing clock $m/clk 6n –

This clock constraint defines a clock named clk with a 6-nanosecond period. Bydefault, clocks are noninverted, so this clock has its rising edge event at zero andits falling edge event at 3 nanoseconds. Because the static timing analyzer

Mar 2003 7of 14


8/14

Application Note

considers only a single cycle of the clock, the event associated with the secondrising edge is not at 6 nanoseconds, but rather at zero, like the first one.Likewise, the second falling edge event is at 3 nanoseconds. This is the case forall rising and falling edge events. This can seem confusing at first, but it is an

efficient method of handling the clocks without much overhead. This methodrequires some compensation in the form of a cycle adjustment, which isdiscussed later in this document.

Here is another example of a clock constraint:

force timing clock $m/clksh 6n –waveform {-rise 1n –fall 4n}

This clock constraint defines a clock names clksh that is identical to clk in theprevious example, but shifted forward in time by one nanosecond. For this clock,all rising edge events occur at 1 nanosecond and all falling edge events occur at4 nanoseconds.

As a third example, consider the line directly below the reference arrival time inFigure 1:

+ Cycle adjust (clk2:F#1 vs. clk1:R#2) 2000

The cycle adjustment is discussed later. For now, consider the information in theparentheses. clk2:F#1 means that the launching clock is clk2 and that the edgeof the clock that triggers the flow of data down the timing path is the first fallingedge. Likewise, clk1:R#2 means that the reference clock is clk1 and that thesecond rising edge of that clock captures the data at the end of the timing path.

So, clk1 is the reference clock for this timing path. Because clk1 is noninvertedand not shifted in time, the rising edge events occur at time zero. There is nomodifier added to the reference arrival time resulting from the clock phase, butthe reference arrival time in the report timing path is listed as 500 picoseconds.This is because 200 picoseconds of network latency and 300 picoseconds ofsource latency are specified for clk1, giving a total of 500 picoseconds for thereference arrival time.

Starting Arrival Time

Reference arrival time takes into account clock source latency, network latency,and phase. With all of this information, the reference arrival time calculates how

much time it takes the receiving clock edge to go from the PLL off-chip to theclock pin of the capturing register. Because of an inconsistency in the wayreference and starting arrival times appear in report timing path, starting arrivaltime has a slightly different meaning.

Mar 2003 8of 14


9/14

Application Note

The starting arrival time, like the reference arrival time, contains informationabout the source delay and phase for the launching clock of the timing path.Unlike reference arrival time, clock network latency is not included in the figure.Instead, clock network latency for the launching clock is specified separately on

the next line in the path report:

+ Clock path delay 200

This has the same overall result as reference arrival time, because the value forclock path delay (network latency) is added to the starting arrival time during theprocess of computed end-of-path arrival time. The starting arrival time, because itdoes not include network latency, can be considered the time it takes for thelaunching clock edge to travel from the PLL to the edge of the chip or block. Thedelay from the edge of the chip or block to the clock pin of the starting register isthen added to that value as clock path delay.

Using Example 1, you can see that the total starting arrival time is 1800picoseconds. Here is how this number is generated. First, find out which clocklaunches the data. Looking in the parenthesis after the cycle delay, you see thatthe falling edge of clk2 launches the data. There is a source latency of 300picoseconds specified for both clocks, which accounts for some of the startingarrival time. The other 1500 picoseconds is a clock phase modifier. The clk2 isnoninverted and not shifted in time, so its rising edge occurs at zero. In this case,though, the falling edge of the clock triggers the register. Because clk2 has a 50percent duty cycle and a period of 3 nanoseconds, its falling edge must occur at1.5 nanoseconds or 1500 picoseconds. This accounts for the remainder of thestarting arrival time.

Modifiers to Reference and Starting Arrival TimesSlack is the difference between the end-of-path required time and the end-of-path arrival time. The end-of-path required time is the time that data needs toarrive at the end of the timing path. The initial piece of information used tocalculate required time is the reference arrival time, or the time the clock arrivesat the receiving register. You must modify this value to determine the requiredtime because of factors such as setup time for that capturing register, any jitter orskew specified on the capturing clock, and multicycle paths in the design.

Likewise, you must modify the end-of-path arrival time to calculate the startingarrival time, because the end-of-path arrival time is when the data actually gets tothe end of the timing path. You are concerned with what time it gets launcheddown the path (the starting arrival time) and how long it takes to get there. Youmodify the starting arrival time using information, such as data-path delay, todetermine the actual end-of-path arrival time.

Mar 2003 9of 14


10/14

Application Note

Calculating End-of-Path Arrival Time

There are four factors that contribute to when data arrives at the end of a timingpath:



• Clock phase information

• Combinational logic delay in the timing path

Clock source latency and the phase information have already been taken intoaccount as starting arrival time. To calculate end-of-path arrival time, add theclock network latency and the delay along the timing path to the starting arrivaltime.

The clock network latency is added to the starting arrival time as clock pathdelay. Any delay that is incurred by traversing combinational logic between thelaunching and capturing registers is combined and added to the starting arrivaltime as data path delay.

Example 1 shows that the end-of-path arrival time is determined by adding thestarting arrival time, the clock path delay, and the data path delay. This gives theMagma timer an estimate for when the data actually arrives at the endpoint of thetiming path. The last step is to subtract this number from the required time todetermine whether slack is positive or negative and, thus, whether the pathmeets timing.

A complete report generated by report timing path contains information aboutthe logic that the launching clock, reference clock, and data travel through. Lookat this portion of the report to see the delay through the data path furtherexplained. Here you can determine the main sources of data path delay. Anything from a slow logic cell to a high fan-out net, to a large capacitive load ona long piece of interconnect can cause large delay along the data path.

Calculating End-of-Path Required Time

These are the factors that contribute to end-of-path required time:



• Clock phase information

• Clock jitter

• Clock skew

• Setup time of the capturing register

• Multicycle path adjustment

• Cycle adjustment

Mar 2003 10of 14


11/14

Application Note

As discussed earlier, the clock latency and phase information is combined andcalled reference arrival time. Jitter, skew, and setup time are subtracted from thisvalue, making the final required time more stringent than the time the clockarrives at the capturing register’s clock pin (reference arrival time). The required

time is also made longer by adding a multicycle path adjustment to it, becausemulticycle path constraints allow the data extra time to arrive at the pathendpoint. The cycle adjustment is a bookkeeping factor added to referencearrival time to account for the way clock phase information is handled.

Jitter, Skew, and Setup Time

Clock jitter is the amount of cycle-to-cycle variation that can occur in a clock’speriod. Because clocks are generated by real physical devices such as phase-locked loops, there is some uncertainty, and a perfect waveform with an exactperiod of x nanoseconds cannot be achieved.

You specify jitter using the force timing margin setup -from - jitter command. Always specify clock jitter as a setup check, because setupchecks are performed from one clock cycle to the next. Hold checks areperformed on the same clock edge, so jitter has no effect. When a jitter constraintis defined as a hold check, this further constrains the hold check requirements,which might be desirable if you want to ensure that all hold checks are met with anonzero time as a safety margin.

Clock skew comes in two forms:

• Single clock skewSingle clock skew is the largest difference in time that the same clock

might arrive at two different registers. This effect is a result of imbalancein the clock tree delays to registers. Specify single clock skew for a setupcheck using the force timing margin setup -from command.

• Interclock skewInterclock skew is the largest difference in time for two different clocksarriving at their respective registers. Specify interclock skew using twocommands: force timing margin setup -from -to and force timing margin setup -from -to . You can also apply both of these forces for hold checks.

You specify clock source latency, network latency, and skew as an estimatewhen the timer is in ideal mode. After the initial routing of the clock treeperformed by run route clock in fix clock, the timer has enough physical dataabout the clock tree to switch into computed mode. At this point, the user-specified forces for the clocks are discarded and replaced with more accurateestimates. The two exceptions to this are the actual clock definition with forcetiming clock and the clock jitter defined with force timing margin setup –jitter.Both exceptions are because the timer has no information about the PLL externalto the chip or block that generates the clock.

Mar 2003 11of 14


12/14

Application Note

The third value subtracted from the reference arrival time is the setup time for thecapturing register. This value is obtained from the library definitions of theregister cells, so it is technology dependent.

Multicycle Path Adjustment

Multicycle path adjustment is added to the reference arrival time as part of thecalculation of the end-of-path required time. Multicycle path adjustment is theextra time you allot to a timing path because of multicycle path timing constraints.You create these multicycle path constraints using the force timing multicyclecommand.

In Example 1, the timing constraints indicate a two-cycle path for all datatraveling between the two clock domains. The multicycle path adjustment for thisreport is 2000 picoseconds, which is the period of the receiving clock, clk1.Because this timing path is allotted two cycles (or one extra cycle), one full cycle

of time is added to the reference arrival time in the form of a multicycleadjustment.

The Magma timer uses clk1 instead of clk2 to determine the period added in themulticycle adjustment because, by default, the period used for multicycleadjustment is taken from the reference clock. You control this issue. If you knowthat the multicycle adjustment for a path should be based on the launching clock,you can use the force timing multicycle -reference command. The default valuefor the -reference option is end.

Cycle AdjustmentProbably the most confusing aspect of slack calculation is the cycle adjustment

added to reference arrival time in order to calculate end-of-path required time.Cycle adjustment does not have any physical or logical counterpart in terms ofdesign. Instead, it is a bookkeeping measure that results from the way in whichstatic timing is done. Static timing analysis considers only one cycle of a clock.This being the case, each successive rising edge for a single clock has the sametime associated with it, even though each edge occurs one full clock period afterthe previous one. Complete dynamic timing information is lost as a result of thisabstraction, but easily regained using cycle adjustment. Again, consider thesame path report in Example 1 to see where the cycle adjustment figure comesfrom.

The cycle adjustment line in the path report also contains information about the

launching and receiving clock edges for the currently reported timing path. Forexample:

+ Cycle adjust (clk2:F#1 vs. clk1:R#2) 2000

This line means that the timing path is launched by the first falling edge of clk2and captured by the second rising edge of clk1. Why are edge numbers reportedif the static timer only really considers a single cycle of the clock? These edgenumbers are the results of the setup or hold relationships between the two

Mar 2003 12of 14


13/14

Application Note

clocks. In this case, the timer must examine enough cycles of both clocks todetermine the worst-case time for setup and hold relationships. Otherwise, thetimer is not concerned with multiple clock periods.

The edge numbers are determined by calculating the LCM for these two clockperiods and then finding the setup relationship from clk2 falling to clk1 rising. Asillustrated in Figure 3, the LCM for these two clocks is 2 x 3 = 6 nanoseconds.The setup relationship from clk2 falling to clk1 rising is 500 picoseconds,between the first falling edge of clk2 and the second rising edge of clk1. Theseedge numbers correspond to the ones reported in the cycle adjustment line of thereport in Example 1.

Figure 3 shows that in the worst case, data has 500 picoseconds to get from thestartpoint to the endpoint of the timing path. But, consider the phase of eachclock. The clk2 launches the data with its falling edge, which occurs at 1500picoseconds. The clk1 receives the data with its rising edge, which occurs at 0

picoseconds. This means that ideally (with no clock delay, data delay, setup time,multicycle adjustment, and so on), data has 0 – 1500 = -1500 picoseconds totraverse the timing path. This does not make sense and is a result of abstractingaway the dynamic clock information.

Figure 3: Setup Relationship From clk2:F to clk1:R

0 1 2 3 4 5 6

By examining the setup relationship in Figure 3, you know that the data shouldideally have 500 picoseconds to traverse the timing path. This is where cycleadjustment occurs. If you add 2000 picoseconds to the reference arrival time,that number minus 1500 picoseconds becomes 500 picoseconds. Therefore,

cycle adjustment is assigned the value of 2000 picoseconds.

Mar 2003 13of 14


14/14

Application Note

Examples of Cycle Adjustments:

Here are a variety of cycle adjustments:

• from clk1:R to clk1:FIn this case, the setup relationship is 1000 picoseconds, because thereare always 1000 picoseconds from the rising edge to the falling edge ofclk1. The clk1:R occurs at 0 picoseconds and clk1:F occurs at 1000picoseconds, so data has 1000– 0 = 1000 picoseconds to travel fromstartpoint to endpoint. This matches the setup relationship value, so nocycle adjustment is needed.

• from clk1:F to clk1:RThe setup relationship is again 1000 picoseconds. But, clk1:F occurs at1000 picoseconds and clk1:R occurs at 0 picoseconds, so data has 0 –1000 = -1000 picoseconds to travel from startpoint to endpoint. Add a

cycle adjustment of 2000 picoseconds to the reference arrival time tomatch with the setup relationship.

• from clk2:F to clk2:RThe setup relationship is 1500 picoseconds, because the period of clk2 is3 nanoseconds and there is always 1500 picoseconds from clk2:F toclk2:R. The clk2:F occurs at 1500 picoseconds and clk2:R occurs at 0picoseconds, so data has 0– 1500 = -1500 picoseconds to travel fromstartpoint to endpoint. Add a cycle adjustment of 3000 picoseconds to thereference arrival time to match with the setup relationship.

• from clk2:F to clk1:R

First, find the setup relationship between clk2:F and clk1:R bydetermining the LCM of the two clocks (6 nanoseconds), drawing thewaveforms, and finding the shortest time between a falling edge of clk2and the next rising edge of clk1. This value is 500 picoseconds. Theclk2:F occurs at 1500 picoseconds and clk1:R occurs at 0 picoseconds,so data has 0 – 1500 = -1500 picoseconds to travel from startpoint toendpoint. Add a cycle adjustment of 2000 picoseconds to the referencearrival time to match the setup relationship

A basic formula for calculating cycle adjustment (in late mode) is:

cycle adjustment = setup relationship – (capturing clock phase – launching clock

phase)

Copyright © 1999-2001 Magma Design Automation Incorporated

Mar 2003 14of 14

Slack Calculation[1]

Documents

Transcript of Slack Calculation[1]