Hierarchical Timing Context: Signing Off a Block with the Top-Level View

Chapter overview

Large chips are built from blocks. Each block team wants to close timing on its own, in a small and fast run. A block run loads only the block netlist, so it finishes in a fraction of the full-chip time. However, a block on its own does not know what drives its inputs or when its clocks arrive. Those facts live at the top level.

Let us consider a block input port. In the block SDC, a designer guessed an input delay of 0.30 ns. At the top level, the real arrival is 0.62 ns. The block run passes with the guess, and the chip fails when it is timed at the top. The block team then reopens work that it believed was finished.

Hierarchical timing context closes this gap. The top-level run writes the real environment at every block port into a file. The block run reads that file and times the block as if it were still inside the chip. Thus, the block team keeps its small, fast run, but with real numbers at the boundary.

This chapter shows how to write and read the context, and how the tool matches top clocks to block clocks. It then covers blocks placed several times, several views and modes, and the checks that prove a context was read correctly. It ends with the limits of the method.

Learning objectives

1. Describe what a timing context carries and when to use single-instance or multi-instance context.
2. Run the two-session flow: write the context at the top and read it at the block.
3. Predict which block constraints the context overrides, and which false paths are honored.
4. Map top clocks to block clocks automatically and by hand, and read the mapping messages.
5. Choose between one-to-one and port-based clock mapping, and explain the pessimism trade-off.
6. Read context for blocks used several times, and for several views and modes.
7. Inspect, report and compare context data, and write block constraints from it.
8. State the limits of context-based block signoff and how to work within them.

Chapter roadmap

The chapter moves in five steps, from what the top hands down to the checks at the block. Figure 1 shows the order. Come back to it whenever you lose your place.

Hierarchical timing context on one page

Five steps from what the top hands down to the checks at the block

Key commands

Table 1 lists the commands and settings covered in this chapter, grouped by section. Do not try to memorize them now. Each one is explained when it is first needed.

1  What a timing context carries

1.1  The concept

Think of a block team as a sub-contractor building one room of a house. The room must fit the doors, pipes and wiring that the main builder runs up to its walls. If the sub-contractor guesses where the pipes enter, the room may not connect. A context is the main builder's measured drawing of every wall opening.

In timing terms, a timing context is a snapshot of the top-level timing environment at the boundary of one block. The top-level run computes it, because only the top knows what drives each port. The block run uses it in place of guessed boundary constraints.

The context is described as top-down. Values are computed at the top and pushed down into the block. The block never changes them; it only reads them.

1.2  What the context contains

Let us consider Figure 2. The block u_blk has a data input A, a data output Z and a clock port CLK. At the top, FF1 launches data through some logic into A. A buffer drives the clock into CLK.

The context at the block ports

The top-level environment is captured where the red wires cross the block boundary

The context holds the following data for the block ports:

• Arrival times at block inputs. This is when data from the top really reaches a port such as A.
• Required times at block outputs. This is when data must leave a port such as Z so the top-level path still meets timing.
• Port clock latency and slew – how late each clock reaches the port, and how sharp its edge is there.
• Exceptions – false paths and similar constraints that cross the boundary.
• Case values – constants set at the top, for example a test-mode pin tied to 0, that reach the block.
• Glitch data, when it is requested (Section 4.4).

Each item replaces something the block designer would otherwise guess. For example, the port clock latency replaces a guessed set_clock_latency on CLK. The arrival at A replaces a guessed input delay.

1.3  Single-instance and multi-instance modules

A module used once in the chip is a single-instance module (SIM). A module placed several times is a multi-instance module (MIM). For example, a CPU core placed four times is a MIM with four instances.

The difference matters because each instance can see a different environment. One core may sit near the clock root, and another far from it. However, all four share one netlist and one block run. Section 4.1 explains how the tool combines several environments into one context.

1.4  Why it matters

Without context, every block team writes its own boundary constraints. These are guesses until the top-level run exists. A guess can fail in two directions:

• Too lenient – the guess is earlier than reality. The block looks clean, and real violations appear only at the top.
• Too tight – the guess is later than reality. The block team fixes paths that were never failing, which wastes area, power and schedule.

Figure 3 puts numbers on the first case. The same 0.45 ns path inside the block passes with the guessed arrival and fails with the real one.

A guessed input delay versus the context arrival

One block path, timed twice with different arrival times at port A

Let us check the numbers by hand. The clock period is 1.00 ns and the setup time is 0.05 ns. Thus, data must reach FF2 by 0.95 ns.

• With the guess: 0.30 + 0.45 = 0.75 ns. The slack is 0.95 − 0.75 = +0.20 ns.
• With the context: 0.62 + 0.45 = 1.07 ns. The slack is 0.95 − 1.07 = −0.12 ns.

Thus, context replaces the guesses with numbers from the real chip. The block team finds the problem in its own run, while the fix is still cheap.

2  The two-session flow

2.1  How it works

The flow uses two separate sessions, as Figure 4 shows. The top run writes the context. The block run reads it. The context file is the only link between them, so the two runs can happen on different days and machines.

Writing and reading a context

One top session writes a file; one block session reads it

The steps are:

1. Top session – load the full chip: libraries, netlist, parasitics and top SDC.
2. Write – run write_timing_context for the module you want, for example blk.
3. Block session – load only the block: libraries, block netlist, block parasitics and block SDC.
4. Read – run read_timing_context after all block data.
5. Time – run update_timing, then report as usual.

tempus> read_lib slow.lib                            ;# libraries
tempus> read_verilog top.v                           ;# full-chip netlist
tempus> set_top_module top                           ;# link the top
tempus> read_spef top.spef.gz                        ;# top parasitics
tempus> read_sdc top.sdc                             ;# top constraints
tempus> write_timing_context context.db -module blk  ;# context of module blk

tempus> read_lib slow.lib              ;# libraries
tempus> read_verilog blk.v             ;# block netlist
tempus> set_top_module blk             ;# link the block
tempus> read_spef blk.spef.gz          ;# block parasitics
tempus> read_sdc blk.sdc               ;# block constraints
tempus> read_timing_context context.db ;# read after ALL block data
tempus> update_timing                  ;# time the block with context

2.2  Command breakdown

write_timing_context runs in the top session.

• The first argument is the output file, here context.db. The block team needs only this file.
• -⁠module names the module whose ports are captured. Use the module name, blk, not the instance name u_blk.
• At the top, write_timing_context replaces update_timing -⁠full. In other words, you do not need a separate full timing update before it.
• Later sections add -⁠include_text_format (Section 5.2) and -⁠with_constraints (Section 5.3).

read_timing_context runs in the block session.

• The argument is the context file written at the top.
• Read it after all block collateral, including the SDC. Then run update_timing.
• Later sections add -⁠clock_mapping_file, -⁠instances, -⁠merge and -⁠view_map_file.

2.3  What the context overrides

Once read, the context overrides the port constraints in the block SDC. For example, the block SDC may set an input delay of 0.30 ns on A. After the context is read, the tool uses the context arrival of 0.62 ns instead.

The one exception is port clocks. The context does not override clocks defined on block ports. Thus, the top SDC and the block SDC must agree. Assume the block SDC defines BCLK with a 1.00 ns period. If the top clock has a 1.20 ns period, the block run times its paths against the wrong period.

If a port constraint is applied after the context is read, the tool ignores it and issues TCLCMD-1541. This protects the context from accidental edits. For example, a script that sources an extra set_input_delay after the read has no effect, and the log shows TCLCMD-1541.

Figure 5 follows one port through a block session, step by step. Read it left to right, as the script runs.

What the block uses at each step

The block SDC, the context and a late constraint, in script order

Clock jitter follows its own rule. For port clocks, the jitter in the context overrides the jitter in the block SDC. Thus, the block sees the jitter the top sees, even when the block SDC carries an older value.

2.4  Which false paths survive

False paths that touch the block boundary need care. Some forms pass through the context, and some are ignored. Two terms help here:

• An interface pin is a pin inside the block that sits on a path to or from a block port.
• An internal pin is any other pin inside the block, on a register-to-register path.

Figure 6 places these pins on a small design, with every rule beside it. Tables 2 and 3 then repeat the rules in text form.

Which boundary false paths survive

The same pins seen from the top SDC and from the block SDC

Table 2 lists the rules for false paths written in the top SDC.

Let us read the table with an example. The top SDC marks a test path as false through the block port u_blk/TEST_IN. That is the first form, so the block run also treats it as false. However, a top false path given only as -⁠through an interface pin, with no other point, is ignored. The block run then times that path.

Table 3 lists the rules for false paths written in the block SDC.

At the block, false paths through pins inside the block work. False paths that name a block port do not. A simple way to remember it: at the block, the context owns the ports.

3  Mapping top clocks to block clocks

3.1  The concept

The top and the block usually name their clocks differently. The top may call a clock TCLK, while the block SDC calls the same clock BCLK. Both names describe one physical clock net entering port CLK.

The context carries values per top clock, such as the latency of TCLK at CLK. The block run times paths per block clock. Before the context can be used, each top clock that reaches the block must be matched to a block clock. This is called clock mapping.

3.2  How automatic mapping works

By default, the tool maps clocks on its own. Figure 7 shows the five outcomes you will meet.

• Mapped – the top clock matches a block clock. The tool reports TA-1022.
• Generated clock – generated clocks are mapped by name only. If the names differ, they do not map. Verify them after update_timing.
• Unmapped top clock – a top clock reaches the block but finds no block clock. The tool reports TA-1023 and aborts with TA-1024.
• Unmapped block port – a block clock port receives no mapped top clock. The tool reports TA-1025.
• Unmapped block virtual clock – a virtual clock in the block SDC has no top clock. The tool reports TA-1041.

The five outcomes of clock mapping

Each clock on either side either finds a partner or does not

The abort on TA-1024 is deliberate. A top clock without a block clock means some paths would have no clock to time against. Stopping is safer than continuing silently.

To continue past an unmapped top clock, set this variable:

tempus> set timing_hierarchical_context_continue_on_top_block_clock_mismatch \
    true   ;# continue instead of aborting

3.3  Mapping clocks by hand

When the automatic match is wrong or missing, map clocks yourself. Put set_timing_context_clock_mapping commands in a file, and read that file with the context:

# Map top clock TCLK to block clock BCLK in view func_ss
set_timing_context_clock_mapping -top_clock TCLK -block_clock BCLK -view func_ss
# Also map TCLK2 to BCLK; -add keeps the first mapping
set_timing_context_clock_mapping -top_clock TCLK2 -block_clock BCLK -view func_ss -add

tempus> read_timing_context context.db -clock_mapping_file clkMap.txt   ;# user mapping wins

Each option has one job:

• -⁠top_clock – the clock name as the top SDC defines it.
• -⁠block_clock – the clock name as the block SDC defines it.
• -⁠view – the analysis view this pairing applies to. A pairing can differ between views, for example functional and test.
• -⁠add – keeps earlier pairings for the same block clock. Without it, a new pairing replaces the old one.
• -⁠clock_mapping_file – the option of read_timing_context that reads the file.

The rules for user mapping are short but important:

• User mapping wins over the automatic match. If the top and block waveforms differ, the block waveform is used.
• Repeated mapping for the same block clock overrides the earlier one. Add -⁠add to keep both.
• Manual excludes automatic – a block clock you map by hand is left out of automatic mapping. Thus, list every mapping that block clock needs.

Let us see why the last rule matters. Assume the tool would map TCLK to BCLK on its own. You then add a manual pairing of TCLK2 to BCLK. Now BCLK is excluded from automatic mapping, so TCLK is no longer paired. You must add the TCLK line yourself. Figure 8 shows the three situations side by side.

Why a manual mapping must list every pairing

The same block clock BCLK under three mapping files

3.4  One-to-one or port-based mapping

The variable timing_context_port_based_clock_mapping decides how many top clocks may share one block clock. Figure 9 compares its two settings.

One-to-one versus port-based mapping

Two top clocks reach the same block clock port

With false (the default), mapping is one top clock to one block clock. When several top clocks could fit, the tool breaks the tie in this order:

1. The clock property.
2. The clock name.
3. The clock that reaches the most common ports.
4. Any one of them.

With one-to-one mapping, the losing top clock is not used for that block clock. That is fine when the top clocks are equivalent. It is risky when they differ, because the paths of the losing clock are not represented.

With true, mapping is port-based. Several top clocks can map to one block clock (N-to-1). One top clock can also map to several block clocks (1-to-N). For N top clocks on one block clock, latency and arrival are worst-cased.

Let us consider two top clocks reaching CLK, with latencies 0.40 ns and 0.55 ns. With port-based mapping, the block clock carries the worst-case value from both. Thus, every path is covered, but some paths are timed more pessimistically than either clock alone.

If several block clocks can match on the same port, the tool cannot decide alone. Map them by hand.

3.5  Mapping reports and messages

The tool writes two reports, timing_context_clock_mapping.rpt and timing_context_clock_mapping_data.rpt. Both follow the auto_file_dir and auto_file_prefix settings from Getting Started with Tempus. You can also print the mapping on demand:

tempus> report_timing_context_clock_mapping              ;# text report
tempus> report_timing_context_clock_mapping -format csv  ;# CSV, port-based mapping only

The CSV form works only with port-based mapping. It is handy for scripts that check every port in a spreadsheet or a parser. Table 4 collects the messages from this section.

The mapping data also marks how each port is used, with the letters C, I, O, R and E. Run help report_timing_context_clock_mapping to confirm what each letter stands for in your installation.

4  Multi-instance modules and multiple views

4.1  Multi-instance modules

Let us consider a module blk placed three times, as A1, A2 and A3. Each instance sees a different clock latency at port CLK. However, the block is closed once, as one netlist. Thus, one context must cover several instances.

The tool solves this with clusters. Instances fall into the same cluster when they have the same:

• port clocks,
• polarity,
• constants, and
• top clock constraints.

Within a cluster, latency, transition and load are worst-cased. Figure 10 shows three instances and the clusters they form.

Clusters for a multi-instance module

Similar instances share one worst-case context

Let us read the figure. A1 has a CLK latency of 0.40 ns and A2 has 0.65 ns. Both use TCLK, so they share a cluster. The context for that cluster uses 0.65 ns, the worse of the two. A3 uses TCLK2, so it forms its own cluster.

The clusters are listed in multi_instance_cluster_info.rpt. To read the context for chosen instances, name them:

tempus> read_timing_context context.db -instances {A1 A2}   ;# one cluster

If you omit -⁠instances, all instances are read, and they must form one cluster. The tool raises an error in two cases:

• The listed instances belong to different clusters. For example, -⁠instances {A1 A3} mixes clusters 1 and 2.
• An instance's module is not the module given to -⁠module when the context was written.

For nested hierarchy, give the full instance path from the top in -⁠instance or -⁠instances. For example, an instance inside a subsystem is named with the subsystem path first. Figure 11 shows a small case.

Naming instances inside a subsystem

The module blk is placed twice inside u_sub

4.2  Multiple views

In a multi-mode multi-corner run, write_timing_context covers all active views. Multi-Mode Multi-Corner Analysis explains views and active views.

The block run needs a context for every one of its active views. If a block view has no context, its boundary is unknown. Read the contexts together with read_timing_context -⁠merge. Top and block views are paired in one of two ways:

• By name – a top view and a block view with the same name are paired automatically.
• By a view map file – given with -⁠view_map_file, when the names differ.

4.3  Merge mode: folding top modes into one block view

Sometimes the top runs functional and test modes as separate views, but the block team runs one view. Merge mode folds both top contexts into that one block view. It needs timing_context_port_based_clock_mapping set to true. Figure 12 shows the setup.

Merging two top modes into one block view

Both context files and the view map file feed one read command

# Functional top view feeds the block view
set_timing_context_view_mapping -top_view func_view -block_view blk_view
# Test top view feeds the same block view; its clocks get the suffix _test
set_timing_context_view_mapping -top_view test_view -block_view blk_view \
    -block_clock_suffix "_test"

tempus> set timing_context_port_based_clock_mapping true   ;# required for merge mode
tempus> read_timing_context -merge {top_testmodeview.context top_funcmodeview.context} \
    -view_map_file view_map.tcl                             ;# fold both modes into blk_view

The options work as follows:

• -⁠merge – takes the list of top context files to fold together.
• -⁠view_map_file – names the file that holds the view pairings.
• -⁠top_view and -⁠block_view – pair one top view with one block view.
• -⁠block_clock_suffix – adds a suffix to the block clock names that come from that top view. Here, test clocks appear as BCLK_test.

Two rules apply here:

• set_timing_context_view_mapping is used only inside the view map file. It is never run on its own.
• In the block SDC, keep the functional and test clocks physically exclusive. Otherwise the tool may time paths between two modes that never run together, which creates false violations.

4.4  Passing glitch data

Glitch results can travel through the context too. Set set_si_mode -⁠update_glitch_mode to none, medium or high. The value none passes no glitch data. Confirm what medium and high include with help set_si_mode.

The order matters:

1. At the top, set the mode before write_timing_context.
2. At the block, set the same mode before read_timing_context.
3. At the top, reset the mode to none before the next update_timing.

Figure 13 puts the three steps on two time lines, one per session.

Passing glitch data through the context

The top and block sessions set the same glitch mode around the write and the read

tempus> set_si_mode -update_glitch_mode medium   ;# top: before write_timing_context
tempus> set_si_mode -update_glitch_mode medium   ;# block: before read_timing_context
tempus> set_si_mode -update_glitch_mode none     ;# top: reset before next update_timing

Glitch, Overshoot and Undershoot explains the glitch analysis itself.

5  Inspecting, comparing and exporting context

A context read can succeed and still be wrong. A clock may be unmapped, or a port constraint may be ignored. Figure 14 shows a short checking routine to run after every read.

Checking a context after every read

Four checks, then a decision

5.1  Querying a port

With port-based mapping, each port carries a context_data property. Query it with get_property:

tempus> get_property [get_ports A] context_data   ;# context of port A

The property has these fields:

• top_instance – the top-level instance the context came from.
• top_view – the top view that produced the data.
• mapped_top_clocks, unmapped_top_clocks, all_top_clocks – the top clocks at the port, split by mapping status.
• mapped_block_clocks, unmapped_block_clocks, all_block_clocks – the same split for block clocks.

The field meanings above follow their names; confirm details with help get_property if needed. The unmapped fields are the quickest way to find a clock hole on one port. An empty unmapped_top_clocks field is what you want to see.

5.2  Reporting and comparing values

To print context values, use report_timing_context_data. The -⁠type option selects one or more of these:

• latency – the clock latency carried to the port.
• incr_delay – the incremental delay values carried to the port.
• uncertainty – the clock uncertainty carried to the port.

The -⁠port option limits the report to one port.

tempus> report_timing_context_data -type {latency incr_delay uncertainty} -port A   ;# port A

To compare two contexts, for example before and after a top-level change, use compare_timing_context. It needs contexts written with write_timing_context -⁠include_text_format. A context written without that option cannot be compared later.

5.3  Writing block constraints from the context

Sometimes a team wants plain SDC files for the block, built from the real top environment. write_timing_context -⁠with_constraints writes them. The output is <dir>/<module>/<module>.<mode>.sdc, one file per mode. It also writes path-adjust, path-group and timing-derate SDC files. Figure 15 sums up what it produces.

What -with_constraints writes

Block SDC files built from the context, and the constraints they omit

The rules are:

• It works for single-instance modules. A multi-instance module needs -⁠instances.
• It cannot be used from distributed STA.
• Use the files only together with the context. In the block run, read_sdc the written file before read_timing_context.
• The files omit input and output delays (SID and SOD – set_input_delay and set_output_delay), input transition, driving cell and load.
• They also omit port latency, dont_touch, dont_use and port DRV limits.
• -⁠skip_interface_paths writes constraints for register-to-register paths only.

The omitted items are mostly boundary values that the context supplies, plus implementation settings such as dont_touch and dont_use. Thus, the written SDC is a companion to the context, never a replacement for it.

6  Limits of context-based signoff

Context is powerful, but it is not a full-chip run. The block run sees the boundary as fixed numbers, while the real chip keeps changing. Keep these three limits in mind.

• IO-path PBA is partial. Path-based analysis (PBA) of interface paths is only partial in a context run. Typically, the part of the path outside the block is not visible to the block run. Path-Based and Robustness Analysis explains PBA.
• Interface ECOs break the context. If a fix changes an interface cell, the top-level numbers no longer match. For example, a larger input cell adds load to the top-level driver, which the context did not see. Mark the interface dont_touch during block fixing.
• MIM timing windows are pessimistic. For multi-instance modules, timing windows are the union across instances. A wider window means more crosstalk overlap is assumed.

Figure 16 shows the second limit in numbers. The block team upsizes the input cell behind port A. The top driver now sees more load, but the context still carries the old arrival.

How an interface ECO makes the context stale

The same port before and after the input cell is upsized

Thus, context-based signoff works best as a loop. Close the block against the context, return to the top run, write a new context, and compare.

7  Worked example: a block with functional and test modes

The task. Module blk is used once, as u_blk. The top runs a functional view and a test view. The block team runs one view, blk_view. Glitch data must pass through. The top clock TCLK must map to block clock BCLK.

Let us plan before typing. One block view and two top views means merge mode. Merge mode needs port-based mapping. Different clock names need a manual mapping file. Glitch data needs the glitch mode set on both sides.

Step 1 – top run, functional view

# Assuming the design data for the functional view is already loaded
tempus> set_si_mode -update_glitch_mode medium   ;# pass glitch data
tempus> write_timing_context top_funcmodeview.context -module blk \
    -include_text_format                         ;# write context, text form too
tempus> set_si_mode -update_glitch_mode none     ;# reset before next update

The text format is written now so that later contexts can be compared with this one. The test view is written the same way, as top_testmodeview.context.

Step 2 – prepare the mapping files

# Functional and test top views both feed blk_view
set_timing_context_view_mapping -top_view func_view -block_view blk_view
set_timing_context_view_mapping -top_view test_view -block_view blk_view \
    -block_clock_suffix "_test"

# Top and block names differ, so map them by hand
set_timing_context_clock_mapping -top_clock TCLK -block_clock BCLK -view blk_view

The suffix keeps the test copy of the clock separate as BCLK_test. Thus, the block SDC typically defines BCLK_test and makes it physically exclusive with BCLK.

Step 3 – block run

tempus> read_lib slow.lib                                   ;# libraries
tempus> read_verilog blk.v                                  ;# block netlist
tempus> set_top_module blk                                  ;# link
tempus> read_spef blk.spef.gz                               ;# parasitics
tempus> read_sdc blk.sdc                                    ;# func and test clocks exclusive
tempus> set timing_context_port_based_clock_mapping true    ;# needed for merge mode
tempus> set_si_mode -update_glitch_mode medium              ;# read glitch data
tempus> read_timing_context -merge {top_testmodeview.context top_funcmodeview.context} \
    -view_map_file view_map.tcl -clock_mapping_file clkMap.txt   ;# both modes
tempus> update_timing                                       ;# time with context
tempus> report_timing_context_clock_mapping                 ;# check every clock

Notice the order. All block data comes first, then the two settings, then the read, then update_timing.

Step 4 – verify before trusting the result

Follow the routine in Figure 14:

1. The log has no TA-1023, TA-1024 or TCLCMD-1541.
2. The mapping report shows TCLK on BCLK.
3. get_property [get_ports A] context_data shows an empty unmapped_top_clocks field.
4. The block SDC defines BCLK and BCLK_test as physically exclusive.

Only then read the timing reports. If any check fails, fix the mapping file or the read order and read the context again.

8  Common mistakes and how to catch them

Table 5 gathers the mistakes from this chapter. Each row gives the symptom you would see first.

9  Interview preparation

Chapter recap

Key takeaways

• A context carries the top-level environment into block ports, so the block run is not built on guesses.
• Write the context at the top, read it last at the block, then run update_timing.
• The context overrides block port constraints, except port clocks. Late port constraints are ignored with TCLCMD-1541.
• Every top clock reaching the block must map to a block clock. Review the mapping report every time.
• MIM context is worst-cased per cluster. Multi-view blocks need every active view, and merge mode needs port-based mapping.
• Interface ECOs, partial IO-path PBA and MIM timing windows are the main limits.

Command recap

Compact glossary

Practical perspective

On a real project, context runs repeat every time the top changes. Thus, the habits matter more than the commands. Read the context last, read the mapping report every time, and compare new contexts with old ones. A block that closes against a stale or half-mapped context is a block that fails at the top.

What comes next

So far, every path has been timed with worst-case graph-based numbers. In the next chapter, Path-Based and Robustness Analysis, we retime chosen paths more exactly. We also measure how robust the design is.