Tcl · Module 20

Multicycle Paths

Some paths really do have more than a cycle. Saying so keeps them under analysis instead of removing them — provided you say it about both the setup check and the hold check.

Advanced17 min readtcledapart-iisdcmulticycleexceptionstiming

Part II · Module 20 · Chapter 20.6 · Multicycle Paths

Not every path has to complete in one cycle. A result that is only sampled every fourth cycle, a block whose enable is asserted once per burst, a wide arithmetic unit allowed two cycles by design — these paths are real and slow on purpose.

A multicycle path tells analysis so. Unlike a false path, it keeps the path under analysis with a relaxed requirement, which is why it is almost always the better instrument.

1. The declaration

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

set_multicycle_path 2 -from [get_cells u_cfg] -to [get_cells u_core] -setup

Paths from u_cfg to u_core have two cycles to meet setup, not one.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

=== setup only — the classic mistake ===
    2 cycles  u_cfg    -> u_core   -setup

The number is a multiplier on the period, -from and -to scope it the way Chapter 20.5 §6 described, and -setup says which check is being relaxed.

That last part is where this chapter's whole content lives.

2. Two checks, not one

Timing analysis performs two different checks on every path:

Setup — did the data arrive early enough to be captured? Violated when the path is too slow.
Hold — did the data stay stable long enough after the edge? Violated when the path is too fast.

They pull in opposite directions, and a multicycle declaration affects them separately. The declaration above relaxed setup and said nothing about hold — which means the hold check kept whatever default the tool applies.

3. Stating both sides

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

set_multicycle_path 2 -from [get_cells u_cfg] -to [get_cells u_core] -setup
set_multicycle_path 1 -from [get_cells u_cfg] -to [get_cells u_core] -hold

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

=== with the hold side stated too ===
    2 cycles  u_cfg    -> u_core   -setup
    1 cycles  u_cfg    -> u_core   -hold

Two declarations, same scope, both sides stated. Now neither check is relying on a default you did not choose.

The right hold number depends on your tool's convention, and you must check it rather than copy it.

The common pairing is a hold value of N−1 for a setup value of N — here, setup 2 and hold 1. The reasoning is that moving the setup capture edge later by N−1 cycles means the hold check should move by the same amount, so it still refers to the intended edge.

But the exact number depends on how the tool counts reference edges, and conventions differ between vendors and between -start/-end variants. Confirm it in your tool's reference (Chapter 17.6) rather than copying a number out of somebody's script — which is precisely the habit that chapter exists to break.

What is universal: both sides must be stated deliberately. A multicycle with only one side declared is incomplete regardless of vendor.

4. Why the pairing is checkable

Unlike a false path, this mistake is detectable by a script, because the absence is structural: a -setup with no matching -hold is visible in the constraint set.

Chapter 20.8's review does exactly that:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

  ERROR   a multicycle -setup was declared with no matching -hold

That is one of the few places where a mechanical check can catch a genuine timing-intent error, and it costs about six lines. Worth having.

5. When a multicycle is justified

The claim is narrower than a false path's, and more verifiable:

The destination is enabled less often than every cycle. The classic case — an enable asserted every Nth cycle, so the data has N cycles to settle.
The design was specified that way. A multi-cycle arithmetic unit whose latency is part of its definition.
The source changes rarely and the destination samples it late. A configuration value written once per burst.

Each is a statement about when the destination actually captures, which is checkable against the RTL in a way that "these states are mutually exclusive" often is not.

6. Prefer it to a false path

Chapter 20.5 §7 stated this and it is worth the repetition because it is the judgement that matters most:

A multicycle keeps the path under analysis. A false path removes it.

So if a path degrades badly — somebody adds logic, a cell is swapped, the floorplan moves — a multicycle path will still report a violation once it exceeds its relaxed budget. A false path will never report anything again, however bad it gets.

The questions, in order:

Can this path happen at all? If genuinely not, a false path is correct.
Does it have more than one cycle? Then a multicycle, with the real number.
Is it just hard to meet? Then neither. That is a design problem, and an exception written to make a report look clean is how a chip fails at speed.

Point 3 is the one to be honest about. The pressure to "fix" a stubborn violation with an exception is real, and an exception written for that reason is a lie recorded in a file the whole project trusts.

7. Scope and review

Everything from Chapter 20.5 applies:

Scope narrowly with both -from and -to.
Record why, with the same wrapper approach — and here the reason should name the enable or the specification that justifies the cycle count.
Review the set at every milestone. A multicycle justified by an enable is wrong the moment that enable changes.

A reason worth writing: "u_cfg is written once per burst and u_core samples it on the burst-start enable; two cycles are available by construction." That is checkable. "multicycle to fix timing" is not.

8. Exercises

Exercise 1. What does a multicycle path change, and what does it leave alone?

Exercise 2. Name the two checks timing analysis performs and what each is violated by.

Exercise 3. Why is declaring -setup alone dangerous?

Exercise 4. What is the common hold pairing for a setup value of N, and why should you not simply copy it?

Exercise 5. Why can a script catch an unpaired multicycle but not a wrong false path?

Exercise 6. What is the evidence that a four-cycle multicycle is justified?

Exercise 7. A path is simply hard to meet. Multicycle, false path, or neither?

Answers.

1. It relaxes the number of cycles a path has to meet a check, while keeping the path under analysis. It does not remove it.

2. Setup — did the data arrive early enough; violated when the path is too slow. Hold — did it stay stable long enough; violated when the path is too fast.

3. Because the two checks move in opposite directions. Relaxing setup while hold keeps a default you did not choose gives either spurious hold violations that get "fixed" with unnecessary delay, or a genuinely unsafe relaxation.

4. Commonly N−1, so the hold check moves with the setup edge. Do not copy it because the exact convention differs between vendors and between variants; confirm it in your tool's reference.

5. Because an unpaired -setup is structurally visible in the constraint set, whereas a wrong false path produces exactly what a correct one does — a path absent from the report.

6. An enable in the design asserted at most every fourth cycle, which you can point at. Without it, the claim is that the data happens to be sampled late.

7. Neither. That is a design problem, and an exception written to clean up the report is a false statement the whole project will trust.

Remember.

A multicycle relaxes a path; a false path removes it. Prefer relaxing.
Analysis runs two checks: setup (too slow) and hold (too fast). They move in opposite directions.
Declaring -setup alone is the classic mistake — hold keeps a default you did not choose.
State both sides deliberately. The common pairing is hold N−1 for setup N, but confirm the convention in your tool rather than copying it.
An unpaired multicycle IS script-detectable, unlike a wrong false path — so check for it.
The justification is the enable: a four-cycle claim needs an enable asserted at most every fourth cycle, and you should be able to point at it.
Scope with -from and -to, record the reason, review at every milestone.
A path that is merely hard to meet needs neither exception. That is a design problem, and an exception written to clean the report is a lie the project trusts.

Where this fits

Part of the Tcl curriculum.