Static Timing Analysis: A Learning Roadmap

AWhere you are

It sits first because everything after it is an answer to a question this stage asks. A student who has not seen the grid has no reason to care that a library is characterised at one voltage, or that the same wire has three different delays.

BWhat you will be able to do

• Say what a mode is, what a corner is, and why they are different kinds of thing rather than two words for the same idea
• Draw the scenario grid for a design with three modes and four corners, and say how many analyses that is
• Explain why a path can pass at one corner and fail at another without anything in the design changing
• Say which check you would expect to fail at the slow corner and which at the fast one, and give the reason rather than the rule

CPrerequisites

None. This is the first stage and it assumes you have seen a flip-flop and know what a clock is.

DThe concept

A chip does more than one thing. The same silicon runs your application, and then it runs a manufacturing test where a scan chain shifts patterns through every register, and then it may drop into a low-power state where half of it is switched off and the rest runs at a lower voltage and a slower clock. Each of these is a mode. What changes between them is which paths are real: a select pin held at one value makes one set of paths live and another set irrelevant, and the clock period itself is often different.

The same chip also comes out of the fab differently every time. Transistors are a little faster or a little slower than the nominal. The supply sags under load or sits high when the board is idle. The die runs at eighty degrees in a phone in your pocket and at minus twenty on a cold morning. The wires come out narrower or wider than they were drawn, which changes both their resistance and how strongly they couple to their neighbours. A corner is one named combination of all of that: a process point, a voltage, a temperature, and an extraction point for the wires.

A mode changes what the logic is doing. A corner changes how fast the silicon does it. Neither one is a version of the other, and a design has to survive every reasonable combination of the two.

One mode paired with one corner is a scenario, and a scenario is the unit of work in timing analysis. It is a complete, self-contained question: given this logic configuration, these libraries, these parasitics and these constraints, does every path meet its requirement? Laying the modes along one axis and the corners along the other gives a grid, and signoff means running the grid.

Here is that argument drawn on a single path. Nothing about the path changes between the two panels. The same registers launch and capture, the same gate sits between them, the same wire connects them. Only the numbers behind those cells change, because the library that supplies them was characterised somewhere else.

The two failures want opposite fixes. Setup wants the path faster, so you make the cells bigger or take a stage out. Hold wants the path slower, so you add delay on purpose. Fixing one can create the other, which is why closing timing is an iteration rather than a list of repairs, and why the grid has to be re-run after each round rather than trusted from the last one.

EIn the tool

Three commands describe the corner side of a scenario, and one groups the whole thing. None of them is worth learning properly yet, because each one makes sense only once you know what it is scaling.

If you want the fuller treatment of this topic now rather than at Stage 11, the MMMC track at pdverse.net/mmmc goes through scenario setup, distributed analysis and the reporting rules in the detail a working flow needs.

FThe traps

GCheck yourself

HWhat this unlocks

Stage 2, which says what static timing analysis actually is and, more usefully, what it is unable to tell you. If you skip it you will spend a long time expecting the tool to answer questions about function that it has no way to answer.

IHow long this takes

Two evenings. Most of that is looking at the grid until it stops looking arbitrary.

AWhere you are

It sits here because the previous stage described a grid of analyses without saying what an analysis is. This stage says what the tool does and, at least as importantly, what it declines to do.

BWhat you will be able to do

• State the difference between static timing analysis and simulation in terms of what each one needs as input
• Name two questions that static analysis cannot answer, and say why the limitation is structural rather than a shortcoming of a particular tool
• Say where in the implementation flow timing analysis runs, and what the clock and the wires look like at each of those points
• Name the four kinds of timing path and give an example of each

CPrerequisites

Stage 1, for the vocabulary of modes, corners and scenarios.

DThe concept

Simulation asks what the design does when you feed it a particular sequence of inputs. It is exact about that sequence and silent about every sequence you did not write. Static timing analysis asks a different question and asks it without any input at all. It walks the structure of the netlist, finds every path from a launching point to a capturing point, adds up the delays along each one, and compares the total against what the clock allows. It does not need vectors because it is not simulating behaviour; it is measuring the structure.

That trade is the whole character of the method. Because it needs no stimulus it is exhaustive: every path gets an answer, including the ones nobody thought to test. Because it needs no stimulus it is also fast enough to run on a full chip many times a day. And because it needs no stimulus it has no idea what the logic means.

Static analysis is exhaustive over structure and blind to function. Both halves of that sentence are consequences of the same design decision, and you cannot have one without the other.

The blindness is worth taking seriously early, because a great deal of wasted effort comes from expecting the tool to know something it cannot know. It will happily report a long path through logic that can never be sensitised, because sensitisation is a question about values and the tool is not tracking values. It will time a path between two clocks that have no relationship and produce a number, because it was given two clocks and a structural connection between them and that is all it needs.

Timing analysis is not a single step near the end of the flow. It runs after synthesis, after placement, after the clock tree is built, after routing, and again at signoff, and each of those runs sees a different picture. Early on the clock is an assertion and the wires are estimates. Later the clock is a real tree with real buffers and the wires have been measured off the layout. The same netlist gives different answers at each point, and the answers are supposed to converge.

Finally, the paths themselves. Every path starts somewhere and ends somewhere, and there are only four combinations of what those ends can be. A register can launch or an input port can; a register can capture or an output port can. All four combinations are checked, and they are worth naming because reports are grouped by them and because two of the four depend on numbers you have to supply by hand.

EIn the tool

Two commands that are worth knowing before anything else, because they are the fastest way out of every question this guide does not answer.

help -verbose <command>    all options and arguments
man <command>             the manual page for a command,
                          a variable, or a message identifier

The second one is the more useful of the two. It takes message identifiers as well as command names, so when a run prints a warning code you have not seen before, that code is itself a searchable question.

FThe traps

GCheck yourself

HWhat this unlocks

Stage 3, which draws the object every one of these paths is an instance of. Skipping it leaves you with the vocabulary of paths but no picture to attach it to, and every later stage refers back to that picture.

IHow long this takes

One evening. It is a short stage and its value is mostly in the third section.

AWhere you are

It sits here because the first two stages have used the word “path” without drawing one. This stage draws it, names every part, and defines the three quantities that the rest of the guide computes.

BWhat you will be able to do

• Draw a register-to-register timing path from memory, with the clock reaching both registers, and name the startpoint and the endpoint correctly
• Say what arrival time and required time each mean and which direction each one is computed in
• Define slack in one sentence and say what its sign means
• Explain why the check is anchored at the endpoint rather than at the startpoint

CPrerequisites

Stage 2, for what analysis is doing and why it works on structure.

DThe concept

Here is the object. A register launches a value when its clock edge arrives. The value travels through some amount of combinational logic. Another register captures it when its own clock edge arrives. That is a timing path, and the overwhelming majority of the paths in any design look exactly like this.

The startpoint is the clock pin of the launching register. The endpoint is the data pin of the capturing register. Notice that these are not symmetric: one is a clock pin and the other is a data pin. That asymmetry is not an accident of naming. The path begins when a clock edge causes something to happen, and it ends where a requirement has to be satisfied, and requirements live at data pins.

Two clock edges matter to this path. The launch edge is the one that causes the launching register to put a new value on its output. The capture edge is the one that causes the capturing register to take a sample. By default the tool assumes these are consecutive edges, one period apart, and that default assumption is behind more confusion than any other single thing in the subject.

Arrival time is when the data actually reaches the endpoint. It is computed forwards: start at the launch edge, add the launching register's own delay from clock to output, then add every cell delay and every net delay along the way. Required time is the latest the data may arrive and still be captured correctly. It is computed backwards from the capture edge, subtracting whatever the capturing register needs.

Positive slack means the check passes with room to spare, and the size of the number tells you how much. Zero means it passes exactly. Negative means it fails, and the magnitude is how much time you have to find. That is the entire scoring system, and every report you will read for the rest of your career ends in those three lines.

EIn the tool

One command produces everything described in this stage, and you will run it more often than all the others put together.

report_timing -path_type full -delay_type max -max_paths 1

Those are its defaults, so running it bare gives the same result: the single worst setup path, shown in full. Stage 10 walks a real report from this command line by line. For now the point is that arrival, required and slack are not abstractions. They are three labelled lines at the bottom of the output, in that order.

FThe traps

GCheck yourself

HWhat this unlocks

Part Two, which opens up the one thing this stage treated as a single number: the delay along the path. Skipping ahead to the checks without knowing where delay comes from leaves you able to read a report and unable to change one.

IHow long this takes

Two evenings, and it is worth drawing the main figure yourself from memory at the end of each.

AWhere you are

It sits here because Stage 3 treated the delay along a path as a single number. This stage opens the first half of that number and shows that a cell's delay is not a property the cell carries around with it.

BWhat you will be able to do

• Name the two axes of the cell delay table and say what each one physically is
• Given a table and a pair of operating conditions, say whether the tool will interpolate or extrapolate, and why the difference matters
• Explain why the same gate has different delays at two places in the same design
• Classify a timing arc as positive unate, negative unate or non-unate, and give a gate for each
• Say what problem current-source models were introduced to solve

CPrerequisites

Stage 3, for the path and for what arrival time is accumulating.

DThe concept

Ask where a cell's delay number comes from and the honest answer is that somebody measured it. Before a library is released, every cell in it is simulated at transistor level, many times, under a range of conditions, and the results are written into a table. The tool does not compute delay from physics during a timing run. It looks the answer up.

The table has two axes, and understanding why it has exactly two is most of this stage. The first is the input transition time: how quickly the signal arriving at the cell's input is moving. The second is the output load capacitance: how much the cell's output has to drive, counting the wire and every input pin hanging off it.

Delay is not a property of a gate. It is a function of the gate's situation, and the two things that describe that situation are how the input arrived and what the output has to push.

Both axes have an intuition worth holding. A larger load takes longer to charge, which is the obvious half. A slower input edge is less obvious: while the input is drifting through the middle of its range, both the pull-up and the pull-down transistors are partly conducting, and the cell spends that whole interval fighting itself rather than driving its output. The slower the edge, the longer that interval lasts.

There is one more thing the library had to decide before it could measure anything: where the delay is measured from and to. A signal does not change instantly, so “when the input changed” has to mean the moment it crossed some particular voltage. Libraries usually pick the halfway point for delay, and a different pair of points for transition time, and they state which.

Two libraries that chose different points will disagree about identical silicon, by an amount that is small on a fast edge and not small on a slow one. This is a real source of mismatch between a signoff tool and an implementation tool, and it is worth reading your library's own statement of it once, early, so that a discrepancy later has a candidate explanation.

The actual conditions in a design almost never land exactly on a table entry, so the tool interpolates between the four surrounding points. Inside the table that is a reasonable thing to do and the answer is trustworthy. Outside it the tool extrapolates instead, extending a surface past the last point anyone measured, and the answer becomes a guess with the same number of decimal places as a measurement.

A table is a table of one thing, so a cell has many of them. There is one per timing arc, which is one input pin to one output pin, and usually one for the rising output and one for the falling. A two-input gate with one output therefore carries at least four delay tables, plus tables for the output transition, plus more for every corner the library was characterised at.

An arc also has a sense. If a rising input causes a rising output the arc is positive unate. If a rising input causes a falling output it is negative unate. If the direction of the output depends on the other inputs, the arc is non-unate and the tool cannot decide which transition to propagate without more information.

Unateness rarely bothers you in a data path, where both possibilities are analysed anyway. It matters in clock networks, where a clock passing through a gate with a non-unate arc leaves the tool unable to say whether a rising edge at the source is still a rising edge at the register.

One more thing, mentioned rather than taught. The table model treats a cell's output as a voltage source driving a single lumped capacitance. That is accurate while the wire's own resistance is small beside the driver's. Once the wire is resistive enough to hide part of its own capacitance from the driver — which is called resistive shielding — a single lumped number stops describing the situation.

There is a way to keep the table model and account for the shielding, and it is worth knowing because the term comes up constantly.

The driver is charging an effective capacitance somewhere between the near capacitance alone and the total. How far between is what k says, and because k depends on the driver as well as the wire the tool solves for it rather than looking it up. When that is still not good enough, signoff libraries carry current-source models instead.

EIn the tool

You will not often interrogate the delay calculator directly, but it is worth knowing that you can.

When a delay number looks wrong, the delay calculation report is where the argument ends, because it shows the inputs the lookup was given rather than only the answer it produced.

FThe traps

GCheck yourself

HWhat this unlocks

Stage 5, which opens the other half of the delay number. If you skip it you will believe the load in this stage's table is a property of the fanout, when most of it is usually wire.

IHow long this takes

Three or four evenings. This stage takes longer than students expect and the study plan budgets for that.

AWhere you are

It sits here because the previous stage kept saying “output load” without saying where that load comes from. Most of it is wire, and the wire has a delay of its own.

BWhat you will be able to do

• Say why a wire has a delay at all, rather than connecting two points instantly
• Distinguish a lumped model from a distributed one and say which question each is the right answer to
• State the Elmore approximation and explain in words why the far end of a wire is slow
• Say where net delay numbers come from before layout and after it, and why the two disagree most on the nets that matter
• Explain what an extraction corner is and why it is separate from a PVT corner

CPrerequisites

Stage 4, for the load axis of the delay table.

DThe concept

In a schematic a wire is a line, and a line has no properties. In silicon a wire is a strip of metal with resistance along its length and capacitance to everything around it: the substrate below, the wires beside it, the wires crossing above. Pushing a voltage change from one end to the other means charging all of that capacitance through all of that resistance, and that takes time.

How much of this you model is a choice, and there are three common answers. You can count only the capacitance, which is fast and adequate for power. You can add a single lumped resistance, which is cheap and pessimistic on anything long. Or you can break the wire into a ladder of small resistance and capacitance segments, which costs the most to extract and is what timing needs.

The ladder has a consequence worth sitting with. The capacitance nearest the driver is charged through almost no resistance. The capacitance at the far end is charged through all of it. So the delay to a node is not proportional to how far away it is; it is a sum in which each capacitance is weighted by everything upstream of it.

That is an argument about charge, and it is easier to believe when it is drawn as edges. Put a probe on the near node and another on the far node of the same wire and watch one edge arrive at both. They start moving at the same instant, because the driver starts driving once. They do not cross the threshold at the same instant, and the gap between the two crossings is the delay the far node costs.

A long wire is slow out of proportion to its length. Doubling the length roughly doubles both the resistance and the capacitance, and the delay involves their product, so it goes up by about four. That square is why long nets behave like a different kind of object from short ones.

Now the practical question: where do these numbers come from? Before there is a layout there is no wire to measure, so the delay is estimated. The crudest estimate is zero, which is what a pre-layout synthesis run often uses. A better one is a wire-load model, a table indexed by how many pins a net connects, built from statistics over previous designs in the same technology. After routing the wires exist, and they are measured: extraction walks the layout and writes out a resistance and capacitance description of every net.

The estimate and the measurement agree well on short nets and part company on long ones. That is the worst possible arrangement, because long nets are exactly the ones that were going to fail. A design that closes comfortably after synthesis and opens up after routing has not gone wrong; it has met the real wires for the first time.

One more thing the wires bring with them. The metal that comes out of the fab is not exactly the metal that was drawn. Etching leaves it narrower or wider than intended, which changes its resistance one way and its capacitance to its neighbours the other way. Extraction is therefore done several times at several assumed outcomes, and those are extraction corners, separate from the process, voltage and temperature corners that scale the cells.

These have names, and the names are worth recognising on a corner list even though they vary between foundries. You will see cworst and cbest, which bracket the capacitance, and rcworst and rcbest, which bracket the resistance and capacitance together; some flows add a typical and separate the coupling-dominated cases out again. Which of them pairs with which PVT point is a decision the project makes, and it is written down.

EIn the tool

One command brings the measured wires into the analysis.

read_parasitics design.spef

The file it reads is a description of every net's resistance and capacitance, written out by extraction. A second form of the same command keeps the coupling capacitance between neighbouring nets rather than folding it into ground, and that form is what Stage 13 needs.

FThe traps

GCheck yourself

HWhat this unlocks

Stage 6, which joins the two halves together and explains why a slow edge in one place makes a slow edge in the next. Skipping it leaves you knowing that both transition and load matter without knowing that they feed each other.

IHow long this takes

Two or three evenings.

AWhere you are

It sits here because the last two stages established that a cell's delay depends on its input edge and that a wire contributes load. This stage joins them: the output edge of one cell is the input edge of the next, so the two effects compound along a path.

BWhat you will be able to do

• Explain why a slow edge at one pin makes the next cell slower, and the one after that slower still
• Name the three design rule constraints and say what each one limits
• Say why those three are checked separately from setup and hold, and where their violations appear
• Explain why inserting a buffer into a long net can reduce the net's delay

CPrerequisites

Stages 4 and 5, both of them, because this stage is about their interaction.

DThe concept

The delay table has input transition on one axis, and the tool also keeps a second table giving the cell's output transition for the same two inputs. That output transition becomes the input transition of whatever the cell drives. Degradation therefore does not stay where it started.

Each cell in that chain is behaving exactly as its library says it does. Nothing is broken. The edge arriving at the last one is slow because of an accumulation that began several stages back, and the last cell's delay is correspondingly large. Left alone, this is how a design ends up with paths that are slow for no locally visible reason.

Transition time is contagious. A cell driving too much load produces a slow edge, which makes the next cell slow, which makes its output edge slower still. The damage is not confined to the pin where the mistake was made.

Three limits exist to stop this, and they are set per pin rather than per path. A maximum transition time says no edge anywhere may be slower than this. A maximum capacitance says no cell may be asked to drive more load than this. A maximum fanout says no output may feed more inputs than this. The third is a rough proxy for the second and exists mostly because it can be checked before anything physical is known.

These are not timing checks and they do not appear in a timing report. They are properties every pin must have whatever path it happens to lie on, and a design can have perfect slack everywhere and still violate all three. Their violations appear in the constraint report instead.

The other lever is drive strength. A library carries the same logic function at several sizes, and a larger one delivers more current, so it charges a given load faster. It also presents a larger input capacitance to whatever drives it, so the improvement is partly paid for by the stage before.

That leaves the case where no amount of sizing helps, because the load is not fanout but wire. Here the fix is to stop the wire being long, by cutting it into pieces with a buffer at each cut. The arithmetic works because wire delay grows with the square of length while buffer delay is added linearly.

EIn the tool

The three limits, and the report that shows their violations.

set_max_transition 2.0 [get_ports "OUT*"]
set_max_transition 5.0 [current_design]
set_max_fanout 2.0 [get_ports "IN*"]

A limit set on the design applies everywhere; one set on a specific object applies there and overrides the broader setting. Maximum capacitance is set the same way, and it is worth saying plainly that the tool documentation names that command without ever showing it being invoked, so the exact form is worth confirming from its own manual page rather than from any guide, including this one.

report_constraint -max_transition -all_violators -significant_digits 4

That is the command that shows them. Note that it is a different command from the one that reports timing, which is the entire point of the trap above.

FThe traps

GCheck yourself

HWhat this unlocks

Part Three, which turns to the clock. Skipping this stage leaves you with a picture in which delay is something cells have, rather than something a design accumulates, and the buffer arithmetic in Stage 14 will look arbitrary.

IHow long this takes

Two evenings.

AWhere you are

It sits here because Stage 3 drew the clock as a single line reaching two registers at the same instant, and that was a convenient lie. This stage replaces it.

BWhat you will be able to do

• Distinguish source latency from network latency and say where the boundary between them is
• Say what ideal and propagated mean, and at which point in the flow each one is the correct setting
• Explain why skew improves one check and worsens the other
• Say what uncertainty stands in for and why one number covers three separate ideas
• Say what makes a clock generated rather than created, and why the distinction matters

CPrerequisites

Stage 3 for the path, and Stages 4 to 6 for why a tree of buffers driving long wires has delays of its own.

DThe concept

A clock declared at a port has a perfect waveform: a period, and edge times inside it, and no delay anywhere. That description is complete and it is also nothing like what reaches the registers.

The real clock has to travel. It comes from somewhere off the die or from a generator on it, enters the design at a port, and then fans out through a tree of buffers and wires to every register that needs it. The time it takes to do that is latency, and it is split into two parts at the point where the clock is declared.

Latency by itself is harmless. If every register saw the edge 2.0 later than nominal, every launch and every capture would shift together and no check would change. What matters is the spread: the difference between the earliest and the latest arrival. That is skew, and skew is what pulls the two ends of a path apart.

Latency moves every register together and changes nothing. Skew moves them relative to each other and changes everything. When somebody worries about a clock, skew is nearly always what they mean.

Before the clock tree is built there is nothing to propagate through, so the latency is asserted as an estimate and every register is told the same number. That setting is called ideal, and it is the correct thing to do at that point. After the tree exists, the tool can compute each register's latency by walking the real buffers and wires, and that setting is propagated.

Now the part that repays slow reading. Suppose the capture register's clock arrives later than the launch register's. The deadline for the data has moved later, so the setup check has more room. But the edge that the data must not overrun has also moved later, so the hold check has less room. One value, two checks, opposite signs.

Alongside skew there is jitter: the clock source's own edges do not land at exactly even intervals, because a phase-locked loop is an analogue circuit with noise in it. And alongside both there is the margin a team decides to carry for things not yet modelled. All three are usually folded into one number.

That last sentence is worth reading twice, because it is the whole behaviour of the knob. Setup uncertainty is subtracted from the required time, making the deadline earlier and the check harder. Hold uncertainty is added, making the earliest allowed arrival later and that check harder too. Uncertainty always costs margin, in both directions, which is why it is set deliberately rather than generously.

Finally, clocks that are made inside the design. A divider, a multiplexer between two sources, a gating cell: each produces a signal that behaves like a clock, and each has a fixed relationship with the clock it came from. Declaring it as generated preserves that relationship, so the tool knows the two are phase-related and can time paths between them against real edges.

Where two clocks have no fixed relationship, or where only one of them can be live at a time, the tool has to be told. It cannot work this out, and if it is not told it will produce a number for a check that has no meaning.

EIn the tool

The clock commands, in the order you will use them.

create_clock -period 10 [get_ports CLK]
create_clock -period 10 -waveform {2 4} {C1 CK2}
create_clock -period 8 -name vclk -waveform {2 5}

The third form makes a clock with no source object at all. It exists purely as a timing reference, for constraining ports whose real clock is outside the block.

create_generated_clock -name DIVIDE \
     -source [get_ports SYSCLK] -divide_by 2 [get_pins FF1/Q]

set_clock_latency 1.5 -source -early [get_clocks CLK]
set_clock_latency 2.5 -source -late [get_clocks CLK]
set_clock_latency -rise 1.2 [get_clocks CLK]

With -source the value is the journey to the clock definition point; without it the value stands in for the network beyond that point. Two values can be given, early and late, and the tool picks the pessimistic one for each end of each check.

set_clock_uncertainty 5 [get_clocks CLKA]
set_clock_uncertainty -setup 0.21 [get_clocks CLK1]
set_clock_uncertainty -hold 0.33 [get_clocks CLK1]
set_clock_transition 0.64 -fall [get_clocks CLK1]

set_propagated_clock [get_clocks CLK]
set_propagated_clock [all_clocks]

set_clock_groups -logically_exclusive \
     -group {CK1} -group {CK2}

The third of those has a consequence the constraint does not supply. Telling the tool two clocks are asynchronous stops it timing paths between them; it does not make those paths safe. Data crossing between unrelated clocks can be sampled while it is changing, and a register caught that way can sit between levels for a while before settling, which is called metastability. The design fixes that, with a synchroniser — usually two registers in series on the receiving clock, so that the first one's indecision has a whole cycle to resolve before anything downstream sees it. The constraint tells the analysis to look away; the synchroniser is what makes looking away safe.

set_clock_transition is only meaningful while the clock is ideal, because an ideal network has no computed edge rate of its own. Once the clock is propagated the tool works the transition out, and the assertion stops applying.

FThe traps

GCheck yourself

HWhat this unlocks

Stage 8, which uses everything here. The setup and hold equations both contain a clock arrival term at each end, and those terms are what this stage has been describing. Skipping it makes Stage 8 look like algebra with unexplained symbols.

IHow long this takes

Three evenings. It is the second of the two stages that reliably take longer than planned.

AWhere you are

It sits here because everything it needs is now in place: the path from Stage 3, the delays from Part Two, and the clock arrivals from Stage 7. This stage assembles them into the two inequalities that every timing check is an instance of.

BWhat you will be able to do

• Write both inequalities from memory, with every term named
• Derive each one from a waveform rather than reciting it
• Explain why the default hold inequality contains no period term, the three cases that put one back, and what follows from that
• Say why hold is usually fixed with delay and setup with speed
• Explain how one path can fail setup at one corner and hold at another

CPrerequisites

Stages 3, 4, 5, 6 and 7. All of them. This is the one stage with no shortcuts into it.

DThe concept

Both checks are about the same physical requirement: a flip-flop needs its data input to be stable for a short window around the clock edge that samples it. Before the edge, that window is the setup requirement. After the edge, it is the hold requirement. Everything else follows from working out when the data actually arrives and comparing it against those two boundaries.

Here is the whole thing on one timeline. The launch clock and the capture clock are drawn separately, because Stage 7 established they are not the same signal at the same instant. The data is drawn below both. The two shaded bands are the windows.

Read the setup check off the drawing. The data leaves the launching register when the launch edge arrives, which is at T_launch. The register takes T_ck→q to put the value on its output, and the logic and wires take T_data after that. The capturing register's deadline is its own clock edge one period later, at T_capture + T_period, brought forward by its setup requirement and by whatever uncertainty was budgeted.

Now read the hold check off the same drawing. The concern is no longer that the data is late; it is that the data is early. The capturing register is supposed to be holding the previous value across its clock edge, and if the new value arrives too soon it overwrites that previous value before it has been sampled. So the new data must not arrive until T_hold after the capture edge that belongs to the same cycle as the launch edge.

Look at what is missing from the second inequality. There is no T_period in it anywhere. The default hold check compares two things that happen at the same clock edge, so the period never enters the arithmetic.

That absence has a consequence which surprises everybody exactly once. Slowing the clock down relaxes the setup check, because it makes T_period larger and there is a T_period in the setup inequality. It does nothing at all to the default hold check. A hold failure is a race between two paths — the data path against the clock path — rather than a race against a deadline, and slowing both runners down does not change which one wins.

The half-cycle case is worth a paragraph because it is the one a first interview reaches for. If the launching register samples on the rising edge and the capturing register on the falling edge, the capture edge sits half a period after the launch, and the hold check lands on the falling edge half a period before it. The period is now in the hold requirement, and a longer period makes that check easier rather than leaving it alone. The setup check, meanwhile, has only half a period to work in, which is why opposite-edge paths are tight for setup and relaxed for hold — the exact reverse of the intuition you have just built.

Duty cycle matters here too. The guide has treated the clock as symmetric throughout, and a half-cycle path on a clock that is high for 40 per cent of its period has 40 per cent of a period for setup, not 50. That is a real source of surprise on a design with a deliberately asymmetric clock.

The fixes follow from the inequalities. Setup fails when the left side is too large, so the fixes reduce T_data or increase what is on the right: bigger cells, fewer stages, a longer period, or a clock arrangement that pushes the deadline later. Hold fails when the left side is too small, so the fix is to make it larger, which means adding delay into the data path deliberately.

The two fixes point in opposite directions on the same path, and each one can create the other's violation. That is why closure is a loop rather than a checklist, and why an implementation tool fixes setup first and hold afterwards: hold is the easier one to fix at the end, and a setup fix applied afterwards would put the hold problem back.

Setup and hold are the two you will spend your time on, and they are not the only checks a register needs. It is worth knowing the others exist now, because they appear by name in the coverage report in Stage 11 and an interviewer will expect at least the first pair.

Recovery and removal are the pair worth being able to talk about. They are exactly setup and hold, applied to the release of an asynchronous signal rather than to data, and they are checked against the same clock edge in the same way. A design with an asynchronous reset has as many of them as it has registers.

There is also a fourth family, which the guide treats at awareness depth only: latch-based timing. A latch is transparent while its enable is active rather than sampling on an edge, so data arriving slightly late can flow straight through and borrow time from the next stage. The name for that is time borrowing, and the time available to borrow is the width of the transparent window. It makes the arithmetic above considerably harder, and it is why most designs use edge-triggered registers unless they have a reason not to.

One more consequence, and it closes the circle back to Stage 1. Setup is worst when everything is slow, which is the slow corner. Hold is worst when everything is fast, which is the fast corner. The same path can therefore be failing both checks, at two different corners, requiring two fixes that undo each other.

One caveat on “fast means cold”, because it is stated as physics far too often. On older processes at nominal voltage, lower temperature does mean faster cells: carrier mobility rises as the die cools. On advanced nodes at low voltage the threshold voltage's temperature dependence wins instead and the cells get slower as they cool. That reversal is called temperature inversion, and its practical consequence is that the hold corner on such a process can be the hot one. Never reason from “cold is fast”; read the corner list the project gives you, which is where the answer actually lives.

EIn the tool

The two checks are two options on one command.

report_timing -delay_type max     the setup check
report_timing -delay_type min     the hold check

Maximum delay analysis is the setup check, because setup is the one that fails when delays are large. Minimum delay analysis is the hold check. Running the first and forgetting the second is a mistake that the report itself gives no hint about, because a maximum-delay report is complete and correct about maximum delay.

set_clock_uncertainty -setup 0.21 [get_clocks CLK1]
set_clock_uncertainty -hold 0.33 [get_clocks CLK1]

Separate values for the two checks are normal, because what they are standing in for is different. Setup uncertainty usually carries jitter and a margin against future degradation. Hold uncertainty usually carries skew that has not been built yet.

FThe traps

GCheck yourself

HWhat this unlocks

Stage 9, which is how you tell the tool everything the two inequalities need. Without this stage the constraint commands are arbitrary; with it, every one of them is filling in a term.

IHow long this takes

Four evenings, and do not rush them. This is the stage the rest of the guide is arranged around.

AWhere you are

It sits here because Stage 8 produced two inequalities full of terms, and most of those terms are things the tool cannot work out for itself. This stage is how they get supplied.

BWhat you will be able to do

• Group the constraint commands by the question each one answers, rather than reciting them alphabetically
• Say what input and output delay describe and why they cannot be derived
• Name the four kinds of exception and say what each one removes from the analysis
• Explain why a wrong exception is invisible in every report that follows it
• Say where a multicycle setup exception moves the hold check, and write the companion exception that moves it back

CPrerequisites

Stage 8 for the inequalities, Stage 7 for the clock, Stage 6 for the electrical limits.

DThe concept

A netlist says what the design is. It does not say what the design is supposed to do, and timing analysis needs both. The constraint file is where the second half is written down, and it is worth approaching it by the questions it answers rather than as a list of commands to memorise.

The first group is the clock, which Stage 7 covered. The second is the boundary. You are almost never timing a whole chip; you are timing one block, and the registers that launch data into it and capture data out of it belong to somebody else. The tool cannot see them, so their timing has to be asserted.

set_input_delay 4.5 -clock PHI1 {IN1}
set_input_delay 2.3 -clock PHI2 -add_delay {IN1}
set_output_delay 4.3 -clock PHI1 {OUT1}

An input delay of 4.5 relative to a ten-unit clock says that by the time the signal reaches your port, 4.5 of the period has already been spent elsewhere, leaving you 5.5. An output delay says the same thing about the other end. Getting either number wrong makes every boundary path wrong, and it makes them wrong quietly, because nothing about a wrong assertion looks different from a right one.

These lines live in a file, and the file has a name: SDC, the constraint format the industry settled on. It is Tcl, so it is a program rather than a table, and a constraint file that loops over a list of ports is entirely ordinary. That is worth knowing before you open your first one and find it is three hundred lines of script.

The boundary group also carries two commands about electrical conditions rather than time. A port has no driving cell inside your block, so the edge rate arriving there has to be described; and a port has no load inside your block, so what it is driving outside has to be described.

set_driving_cell -lib_cell IBUF2 [get_ports in1]
set_load -pin_load 3.5 {IN1 OUT1 OUT2}

The third group is the electrical limits from Stage 6. The fourth group is the one to be careful with, and the rest of this stage is about it.

The first three groups tell the tool about the design. The fourth tells the tool to stop looking at parts of it. That is a different kind of statement and it deserves a different level of care.

There are four things you can say in that fourth group. You can say a path is never taken, so do not time it at all. You can say a path is allowed more than one cycle. You can say a pin is held at a constant value, which prunes everything that constant makes unreachable. And you can say a specific timing arc should be ignored.

set_false_path -from CK1 -to CK2
set_multicycle_path -setup 2 -from FF4 -to FF5
set_max_delay 12.0 -from [get_cells REGA] -to [get_cells REGB]
set_case_analysis 0 [get_ports SEL]
set_disable_timing [get_ports {CKP2 CKP4}]

Now the warning, stated plainly because it is the single most consequential thing in this stage. An exception removes paths from the analysis, and once they are gone no report mentions them. A timing report is a report about what was analysed. It has no section headed “things you asked me not to look at”.

One specific case is worth drawing because it catches everyone once, and because the mechanism is the opposite of what most people assume. Relaxing a path to two cycles for setup moves the capture edge one period later. The hold check does not stay where it was: it follows.

Read that carefully, because it is the whole of the trap. The hold check is always anchored to the capture edge before the one setup uses. Move the setup capture edge out to two periods and the hold check moves with it, to the edge one period after the launch. The path is now required to take more than a whole clock period — which is a far stricter lower bound than the design ever needed, and it is why a path given a multicycle setup exception on its own so often develops enormous hold violations that were not there before.

The fix is a second exception that moves the hold capture edge back.

set_multicycle_path -setup 2 \
          -from [get_cells FF4] -to [get_cells FF5]

set_multicycle_path -hold 1 \
          -from [get_cells FF4] -to [get_cells FF5]

With both in place the setup check has two cycles and the hold check is back beside the launch edge, where the design expects it. The rule of thumb is that a setup multiplier of N wants a hold multiplier of N − 1, and that a multicycle setup exception written without its companion is an incomplete instruction rather than a compact one.

EIn the tool

Constraints are written, and then they are checked. The checking is the half people skip.

check_timing -include { no_driving_cell ideal_clocks \
  partial_input_delay unexpandable_clocks }

That command reports what the constraint set failed to say: ports with no arrival time asserted, clocks still ideal, registers with no clock reaching them at all. It answers a question the timing report structurally cannot, and it costs one line.

report_constraint -all_violators -path_type slack_only

And that one shows every constraint that is violated, including the electrical limits from Stage 6, in a compact form.

FThe traps

GCheck yourself

HWhat this unlocks

Part Four, which runs an analysis end to end for the first time. Skipping this stage means running that analysis on a design that has not been told what it is supposed to do, and the numbers will be confident and meaningless.

IHow long this takes

Four evenings, and one of them spent reading somebody else's constraint file is worth two spent reading about constraint files. This is the second-heaviest stage in the guide, and it is heavy because constraints are what you will be handed on your first day.

AWhere you are

It sits here because the previous nine stages built every idea an analysis needs. This stage runs one, in the order the tool documentation itself lays out, and then reads the output line by line.

BWhat you will be able to do

• Recite the shape of the analysis flow without looking it up, and say which steps a first run needs
• Run a minimal session from netlist to timing report
• Read a timing report line by line and say what each section is
• Find out what any command does without asking anybody

CPrerequisites

Stages 3, 8 and 9 are the ones you will feel the absence of. The others help.

DThe concept

The tool documentation opens with a table of the typical flow, and it is worth reproducing because it is the tool's own account of its own order. It has fifteen steps. Several of them are optional or advanced, and a first analysis uses fewer than half.

Strip that to what a first run actually needs and five commands remain, in an order that is not negotiable. You cannot link before you read, constrain before you link, or report before the design has been constrained.

read_verilog TOP.v
link_design TOP
create_clock -period 10 [get_ports CLK]
update_timing -full
report_timing

Linking is the step that is easy to skip past and worth understanding. The netlist names cells; linking binds each name to an actual cell in an actual library. If a cell cannot be found, everything downstream of it is unknown, and the resulting report will be confidently wrong about a design with holes in it.

Two commands make the rest of this learnable without help. One shows every option a command takes. The other opens the manual page for a command, a variable, or a message identifier — which means a warning code you have never seen is itself a searchable question.

help -verbose command_name
man command_variable_or_message_name

Before reporting anything, there is a step worth taking that most people discover late. The analysis will happily report on a design that is largely unconstrained, and the report will look perfectly healthy, because a report describes the paths it analysed and says nothing about the ones it did not.

Now the report itself. Here is a complete one, reproduced unedited from the tool documentation, for a path from one register to another.

  Startpoint: LD1 (rising edge-triggered flip-flop clocked by CLK)
  Endpoint: LD2 (rising edge-triggered flip-flop clocked by CLK)
  Path Group: CLK
  Path Type: max

  Point                                    Incr       Path
  --------------------------------------------------------
  clock CLK (rise edge)                    0.00       0.00
  clock network delay (propagated)         1.40       1.40
  LD1/CP (FD2)                             0.00       1.40 r
  LD1/Q (FD2)                              0.60       2.00 f
  U1/z (AN2)                               3.20       5.20 f
  data arrival time                                   5.20

  clock CLK (rise edge)                    6.00       6.00
  clock network delay (propagated)         1.16       7.16
  clock reconvergence pessimism            0.16       7.32
  clock uncertainty                        0.00       7.32
  LD2/CP (FD2)                                        7.32 r
  library setup time                      -0.20       7.12
  data required time                                  7.12
  --------------------------------------------------------
  data required time                                  7.12
  data arrival time                                  -5.20
  --------------------------------------------------------
  slack (MET)                                         1.92

It has two blocks and a conclusion. The first block is the data's journey: when the launch edge arrived, how long the clock took to reach the launching register, that register's own delay, and then each cell along the path. It ends with the arrival time. The second block is the deadline being worked out: the capture edge, the clock's journey to the capturing register, the adjustments, and then the required time. The last three lines subtract one from the other.

Read the two blocks against each other and the arithmetic of Stage 8 is all visible. Notice in particular that the clock network delay differs between the two blocks, 1.40 on the launch side and 1.16 on the capture side. That is not an inconsistency; it is the tool taking the longest clock path to the launching register and the shortest to the capturing one, which is the pessimistic combination for a setup check.

EIn the tool

The reporting commands you will use most, and what each one is for.

Two numbers summarise a whole run, and you will hear both in every status meeting.

Worst negative slack, which everybody says as WNS, is the single worst number in the design, and it tells you how far you are from closing. Total negative slack — TNS — is the sum of every endpoint's negative slack, and it tells you how much work that will be. A design with a worst of −0.4 and a total of −0.8 has two problems; one with the same worst and a total of −300 has a systemic one. The count of failing endpoints is the third number people quote, for the same reason. Stage 14 leans on exactly this distinction.

Reporting commands run the timing update for you if it is out of date, so the explicit update is usually unnecessary. Running it yourself is worth doing when you want the warnings separated from the numbers, and when you want to know how long the update actually takes.

FThe traps

GCheck yourself

HWhat this unlocks

Stage 11, which takes the single analysis you just ran and multiplies it by the grid from Stage 1.

IHow long this takes

Two evenings if you have a tool in front of you, three if you are working from the reports alone.

AWhere you are

It sits here because this is the return promised at the end of Stage 1. Everything that stage described without explaining can now be explained: what a corner needs, why it needs its own libraries, and what running many of them at once involves.

BWhat you will be able to do

• List the six things that make up a scenario and say which a mode changes and which a corner changes
• Explain why a corner needs its own libraries rather than a scaled version of somebody else's
• Say what distributed multi-scenario analysis is for and what the manager and workers each hold
• State the rule about when a check counts as untested, and say why merged reporting cannot answer that question alone

CPrerequisites

Stage 1 for the grid, Stage 4 for why a library belongs to one PVT point, Stage 5 for extraction corners, Stage 9 for the constraint set.

DThe concept

That is the definition, and it is accurate but thin. In practice a scenario is six things held together, and the useful thing about laying them out is seeing which ones a mode changes and which ones a corner changes.

The libraries deserve a paragraph of their own, because Stage 4 explains why. Every delay in a library is a table of measurements taken at one process, voltage and temperature point. Change the voltage and every number in every table is wrong, not by a scale factor that applies uniformly, but by an amount that varies with the cell, with the arc, and with where on the table you are reading.

A scaling relation like that exists and it is used, mostly for filling in conditions between characterised points. It is an approximation. A corner that a project actually signs off against gets its own characterised library rather than a scaled one, and that is why a library release is a large delivery rather than a single file.

A corner is not a setting you turn. It is a set of files: libraries characterised there, and an extraction of the wires done under the assumptions that belong with it. Adding a corner means obtaining those files, which is why the corner list is negotiated and not merely chosen.

Running the grid one cell at a time works and is how most people start. It stops working when the grid has sixty cells and each takes an hour. The answer is to run them in parallel, which the tool supports with an arrangement worth understanding because its vocabulary appears in every log file.

The last of those is where the efficiency comes from. The netlist is the same in every scenario, so it is read once and shared, and each scenario adds only what is specific to it. This is also why the constraint scripts are split into a common part and a specific part when scenarios are defined.

start_hosts

create_scenario \
   -name s1 \
   -common_data common_data_scenarios_s1_s3.tcl \
   -specific_data specific_data_scenario_s1.tcl
create_scenario \
   -name s2 \
   -common_data common_data_scenarios_s2_s4.tcl \
   -specific_data specific_data_scenario_s2.tcl

current_session {s1 s2}

Reporting across a grid raises a question that does not arise with one run. When four scenarios disagree about a path, what does the report say? A merged report gives you one line, the worst across the grid, which is the right answer for tracking progress. It is the wrong answer when you are fixing something, because it does not tell you which corner broke it.

There is a command whose whole job is that question, and it produces the single most useful page in a signoff review.

report_analysis_coverage

Type of Check             Total           Tested            Untested
--------------------------------------------------------------------
clock_gating_hold           294       294 (100%)            0 ( 0%)
clock_gating_setup          294       294 (100%)            0 ( 0%)
hold                      75481     45553 ( 60%)        29928 ( 40%)
min_period                  376       196 ( 52%)          180 ( 48%)
min_pulse_width           55778     39171 ( 70%)        16607 ( 30%)
out_hold                    359       333 ( 93%)           26 ( 7%)
out_setup                   359       333 ( 93%)           26 ( 7%)
recovery                  16801     16385 ( 98%)          416 ( 2%)
removal                   16801     16385 ( 98%)          416 ( 2%)
setup                     75479     45532 ( 60%)        29947 ( 40%)
--------------------------------------------------------------------
All Checks               242022    164476 ( 68%)        77546 ( 32%)

Read it as a census rather than a report. Every kind of check the tool makes has a row, and each row says how many of that kind exist and how many were actually tested. The setup and hold rows in that example are at sixty per cent, which would stop a review on the spot: forty per cent of the checks in the design were never made, and nothing in a timing report would have said so.

The rows also answer a question Stage 8 raised. The checks are not just setup and hold: recovery and removal for asynchronous releases, minimum pulse width and minimum period for the clock itself, the clock-gating pair, and the two boundary checks at output ports. Ten kinds, all counted, all capable of being silently absent.

Which brings the practical question: how does a team decide which scenarios are worth running? The honest answer is by argument, informed by a few rules of thumb. Every mode that ships needs at least one corner. Setup needs the slow corners and hold needs the fast ones, so neither end can be dropped. Corners that have never produced a unique violation across several projects are candidates for removal, and removing one is a decision that gets written down rather than made quietly.

EIn the tool

Scenarios are created by name, from scripts, and then selected.

create_scenario \
   -name s1 \
   -common_data common_data_scenarios_s1_s3.tcl \
   -specific_data specific_data_scenario_s1.tcl

current_session {s1 s2}

current_scenario {s3}
current_scenario -all

Narrowing the focus to one scenario makes every subsequent command apply to that one alone, which is how you interrogate a single corner without rebuilding anything. Widening it again restores the whole session.

If you want this topic at the depth a production flow needs, rather than the depth a roadmap can give it, the question set on the MMMC track at pdverse.net/mmmc is where to go next.

FThe traps

GCheck yourself

HWhat this unlocks

Stage 12, which is about the pessimism sitting inside every one of these runs and how much of it is real.

IHow long this takes

Three evenings. You are returning to familiar ground with better tools, so it moves faster than Stage 1 did.

AWhere you are

It sits here because Stage 11 established that a corner is a set of characterised files. This stage asks what happens to two cells on the same die, at the same corner, that still do not behave identically.

BWhat you will be able to do

• Say why one delay number per cell per corner is not enough
• Explain what derating does and why the launch and capture sides get different factors
• Say what advanced on-chip variation adds, and why depth earns a gentler factor
• Explain what clock reconvergence pessimism is and why removing it is not optimism

CPrerequisites

Stage 8 for why the tool takes the worst of each, and Stage 7 for the clock paths that most of this applies to.

DThe concept

A corner says the whole die came out slow, or the whole die came out fast. Neither is quite true. Within one die, process gradients, temperature differences across the chip and voltage drop along the supply network mean two cells a short distance apart can behave measurably differently. A single number per cell per corner does not capture that.

The crudest response is to derate: multiply delays by a factor, and choose the factor so that the arrangement is pessimistic for whichever check is being made. For a setup check the launch clock and the data are made slower and the capture clock is made faster, which is the worst combination available.

set_timing_derate -cell_delay -early 0.90
set_timing_derate -cell_delay -late 1.05
set_timing_derate -net_delay -early 0.96
set_timing_derate -net_delay -late 1.02
set_timing_derate -cell_check -early 0.80
set_timing_derate -cell_check -late 1.10

That is one example from the documentation, printed whole. Notice that the three kinds of delay get different factors: cells, nets, and the library's own setup and hold requirements, which are the -cell_check pair. A flow that derates cells and forgets the checks is giving back margin it thinks it has kept.

A flat factor is blunt, because it applies the same fraction whether a path has one stage or twenty. Variation across many stages partly cancels, in the way that many small independent errors do, so a deep path deserves a gentler factor than a shallow one.

Advanced on-chip variation — AOCV — makes the factor a function of how many stages the path has and, in some flows, how far apart they are physically. The numbers come from characterised tables rather than from a formula.

Parametric on-chip variation, which everyone calls POCV, goes further. Instead of a multiplier it gives each timing arc its own spread and combines them statistically, which is what lets the cancellation in the figure above be counted properly rather than approximated. The spread is usually expressed as a ratio to the delay rather than as a bare standard deviation, and on modern libraries it is not a single number per cell but a table indexed by slew and load, in the same way the delay itself is. That table format has a name you will hear constantly: LVF, the Liberty Variation Format.

Read the list in that sentence against the check types in Stage 11's coverage report and you will see they are the same list. Variation applies to every kind of check, not only to delay.

Then there is a specific and satisfying piece of pessimism which is definitely not real. When the launch and capture clock paths share a segment near the source, the analysis can give that shared segment two different delays at the same instant.

Three separate things cause it, and it is worth being able to name all three. Analysing with minimum and maximum operating conditions does it on its own: the documentation's own worked example generates the pessimism that way, with no variation analysis switched on at all. On-chip-variation derating does it, which is the case drawn below and the one people usually think of. And reconvergent clock logic — a clock that fans out and comes back together — does it even when neither of the first two is in play. Saying only "derating" is the common half-answer.

The amount by which the shared segment was double-counted is given back: added to the required time on a setup check, subtracted from it on a hold check, so that in both cases the slack improves. This is not the analysis becoming optimistic; it is the removal of an assumption that was never physically possible. One buffer cannot be both fast and slow at the same moment.

EIn the tool

set_operating_conditions \
  -analysis_type on_chip_variation \
  -min MIN -max MAX

report_timing -delay_type min
report_timing -delay_type max

That analysis type is what allows the two sides of a check to use different delays at all. Without it there is one delay per arc and the whole subject of this stage does not arise.

read_ocvm pocv_side_file_name
read_ocvm pocv_single_parameter_file_name
set_aocvm_coefficient 2.0 [get_lib_cells lib1/BUF2]

The first reads a variation file, the second reads the single-parameter form of one, and the third sets a coefficient on one library cell by hand. One more command, set_ocvm_table_group, decides which table group applies where; the documentation names it without ever showing it in use, so this guide names it and prints no invocation either.

FThe traps

GCheck yourself

HWhat this unlocks

Stage 13, which is a different kind of uncertainty: not how fast a cell is, but what its neighbours are doing to it.

IHow long this takes

Three evenings. Working depth on derating and reconvergence pessimism, awareness depth on the rest.

AWhere you are

It sits here because it needs extracted parasitics from Stage 5 and the idea of delay as a function of context from Stage 4. It is also the last source of delay the guide introduces.

BWhat you will be able to do

• Say what coupling capacitance is and why it does not exist in the netlist
• Explain why a neighbour can make a net faster or slower depending on which way it switches
• Distinguish a delay effect from a noise effect and say why they are reported separately
• Say why this analysis is enabled separately and what it costs

CPrerequisites

Stage 5 for extraction, Stage 4 for what load does to delay.

DThe concept

Two wires running beside each other have capacitance between them. That capacitance is not in the netlist, because the netlist describes connections and these two wires are not connected. It appears only after routing, in the extracted parasitics, and only if the extraction was asked to keep it separate rather than folding it into each net's capacitance to ground.

When the aggressor switches, it pushes charge through that coupling onto the victim. If the victim is switching the same way at the same time, the push helps and the victim arrives sooner. If it is switching the other way, the push opposes and the victim arrives later. Both outcomes are real and both appear in reports, as a delta delay with a sign.

Crosstalk can improve a path as easily as it can damage one, which makes it awkward in a way that most delay effects are not. The setup check wants to assume the slowing case and the hold check wants to assume the speeding one, and both assumptions are about the same pair of wires.

There is a second effect, unrelated to timing, on a victim that is not switching at all. The push from the aggressor produces a bump on a net that was supposed to be holding a steady value. If the bump is large enough and lasts long enough, the gate downstream reads it as a real transition and passes it on.

That is a functional failure rather than a slow path, and no amount of timing margin prevents it. It is checked against a characterised tolerance: the library states, for a bump of a given width, how tall it may be before the receiver is at risk. Wider bumps are tolerated at lower amplitude and narrow ones at higher.

What sets the height is a ratio, and it is worth having in your head because it explains every mitigation anyone will offer you.

The bump is set by how much of the victim's total capacitance is coupling rather than by the coupling on its own. So increasing the spacing helps because it reduces the numerator; and a stronger driver on the victim helps for a reason this simplified form hides, which is that it holds the net down against the injected charge. Both of the usual fixes fall straight out of the ratio.

All of this costs runtime, because the tool has to work out which nets can switch at the same moment as which others, and that is an iterative question: changing one net's delay changes when it switches, which changes who it overlaps with. So the analysis is enabled deliberately, and it is enabled late, once the routing exists.

EIn the tool

Enabling it is two steps: a variable, and an extraction that kept the coupling.

set_operating_conditions -analysis_type on_chip_variation
set_app_var si_enable_analysis true
read_verilog ./test1.v
current_design test1
link_design
read_parasitics -keep_capacitive_coupling SPEF.spf
create_clock -period 5.0 clock
check_timing -include { no_driving_cell ideal_clocks \
  partial_input_delay unexpandable_clocks }
report_timing

Without the second of those the coupling capacitance has already been folded into each net's total, and there is nothing left for the analysis to work with. Reading the parasitics again with the right option is the fix, and it is a common thing to have to do twice.

report_si_bottleneck -cost_type delta_delay \
  -slack_lesser_than 2.0

That one lists the victim nets contributing most delta delay, ordered, which is where you start rather than with individual paths.

FThe traps

GCheck yourself

HWhat this unlocks

Stage 14, the last one, which is about what you do once a report tells you something is wrong.

IHow long this takes

Two evenings, awareness depth again.

AWhere you are

It sits last because it uses everything. A violation is triaged with Stage 8, fixed with Stage 6, re-checked with Stage 11, and believed or not believed on the strength of Stage 9.

BWhat you will be able to do

• Triage a violation: which check, how many, how large, and what that implies
• Name the usual fixes for each check and say which one you would try first
• Explain why a fix is not finished until the parasitics have been extracted again
• Say what signoff means beyond a clean report, and name the questions a clean report cannot answer about itself

CPrerequisites

Stages 8, 9 and 11 particularly. This stage assumes the whole guide.

DThe concept

A report with a negative number in it is the start of a decision, not the end of one. The first three questions are always the same: which check is it, how many paths are failing, and by how much.

The count matters more than beginners expect. One failing path is usually a local problem with a local fix. Several hundred failing paths, all ending in the same region or all in the same clock domain, is not a cell-sizing problem. It is a constraint that is wrong, or a floorplan that put two things too far apart, or a clock that has not been built the way the constraints assumed.

For setup, the fixes come from Part Two: make the cells bigger so they drive their loads faster, buffer the long nets so the square term stops hurting, take stages out of the logic where the structure allows, swap to a faster transistor flavour where the library has one, or arrange for the capture clock to arrive slightly later and borrow margin from the neighbouring path.

For hold, there is essentially one fix: add delay to the data path. Small violations can be handled by adding load rather than a whole buffer, which is less likely to overshoot. Large hold violations are usually a symptom of something else, most often a clock tree whose skew is larger than the constraints assumed, and fixing the symptom rather than the cause tends to produce a great many delay cells.

The changes themselves do not stay in the timing tool. They are written out as a list of edits, applied by the implementation tool to the real layout, and the result is extracted again. Only then does a timing run on the new parasitics say whether the fix worked.

Which leaves the last question of the guide. What does it mean for timing to be signed off? A clean report is necessary and it is not sufficient, because a report describes what was analysed and cannot comment on what was not.

Those five questions are the bridge between a number and a decision. Each of them has an owner, an answer and usually a report of its own, and a review that asks them is the difference between a project that tapes out and one that tapes out and works. The discipline of asking them systematically is a subject in its own right, and it is where this roadmap ends and practice begins.

EIn the tool

The change-order commands. Each one takes a type or a strategy rather than running on its own, which is the first thing to know about them.

fix_eco_drc -type max_transition -methods {size_cell}
fix_eco_timing -type setup
fix_eco_timing -type hold -pba_mode exhaustive \
fix_eco_power -pattern_priority {HVT MVT LVT}
write_changes -format icctcl -output wc_eco.tcl
save_session my_session

Notice that the timing fixer insists on being told which check to fix. There is no combined mode, and the reason is the ordering below: setup and hold want opposite changes, so a single pass could only ever make one of them worse.

The order those are usually run in is worth knowing, because it is not arbitrary and because getting it wrong means doing the same work twice.

FThe traps

GCheck yourself

HWhat this unlocks

Nothing in this guide. What comes next is a real design, a real constraint file somebody else wrote, and the first report you have to explain to another person.

IHow long this takes

Two evenings, and this stage keeps paying back long after you have read it.