Constraint Reuse & IP Integration

Timing constraints — clocks, generated clocks, I/O delays, exceptions, OCV and MCMM setup

Constraint Reuse & IP Integration

A block that works well gets used again. A team builds a piece of logic once. Then many chips reuse it. We call such a reusable piece an IP block. IP just means a packaged design you drop into a larger chip. To save effort, the constraints travel with the block. SDC is the format those constraints are written in. SDC is the timing constraint format that compliant tools read. We never expand the letters; we just say SDC. A block's tested, trusted SDC is often called its golden SDC. Golden means it is the known-good reference. This chapter is about reusing that golden SDC at the top level. We cover how object names change through hierarchy. We cover constraint sets for IP. And we cover how to avoid conflicts when the block joins the rest of the chip.

What Golden SDC Contains and Why Reuse It

The golden SDC of a block holds everything needed to time it. It creates the block's clocks. It sets input and output delays at the block's ports. It marks false paths and multicycle paths. A false path is a path the tool should ignore. A multicycle path is one allowed more than one clock period. The golden SDC also sets any special clock relationships inside the block. Reuse matters because constraints are hard to get right. A block owner spends weeks tuning them. They test corner cases. They check every clock and every exception. Throwing that away at the top level is wasteful and risky. If the top-level engineer rewrites the block's constraints from scratch, they may miss something the block owner already solved. So we keep the golden SDC and apply it again. But there is a catch. The golden SDC was written for the block when it stood alone. At the top level the block is buried inside a hierarchy. Its ports become internal pins. Its clock sources may now come from outside. The names no longer match. We must bridge that gap.

Name Remapping Through Hierarchy

Hierarchy is the nesting of blocks inside blocks. When a block sits inside a top design, its objects gain a prefix. The prefix is the path to the block. If the block is instanced as u_codec , then a pin called data_out inside it becomes u_codec/data_out at the top. The slash separates levels. This breaks the golden SDC. The golden file says get_pins data_out . At the top level there is no bare data_out . There is only u_codec/data_out . So every object reference must be remapped. Remapping means adding the instance prefix to each name. There are a few ways to do this. One way is to wrap the golden SDC and prepend the prefix to each object query. You read the golden file with the instance path supplied. The tool then resolves names relative to that instance. Another way is to keep the golden SDC written with a variable for the prefix. At the top you set the variable to the real instance path. A third way is to apply the golden SDC while scoped into the instance, so names resolve locally.

A worked example helps. The block's golden SDC has a false path from mode_reg to out_lat . Standalone, both names resolve directly. The block is instanced twice at the top, as u_codec0 and u_codec1 . Now the single golden line must become two top-level lines. One reads u_codec0/ mode_reg to u_codec0/out_lat . The other reads u_codec1/mode_reg to u_codec1/out_lat . If you forget the second instance, that copy of the block is left unconstrained on that exception. Scoping into each instance and sourcing the golden file once per instance avoids the mistake.

Boundary Constraints Versus Internal Constraints

It helps to split the golden SDC into two parts. One part is internal. One part is at the boundary. They behave very differently when reused. Internal constraints describe paths fully inside the block. False paths between two block registers are internal. Multicycle paths inside the block are internal. Generated clocks made from a block clock are internal. These travel well. Once you remap the names with the instance prefix, they still mean the same thing. The relationship between two internal objects does not depend on the outside. Boundary constraints describe the block's ports. Input delays, output delays, and clocks made at block ports are boundary constraints. These do not travel cleanly. At the top level the block's input port is now driven by real top logic. The estimated input delay from the golden file is just a guess about the

outside. Once the real driver exists, that guess is wrong. So boundary constraints should be dropped or replaced at the top. The real top-level path now times the boundary directly. This is the key rule. Reuse internal constraints. Replace boundary constraints. The internal ones save real work. The boundary ones were placeholders for a world that no longer exists.

A clean IP block ships its constraints as an organized set, not one tangled file. A constraint set is just a folder of SDC files split by purpose. The split makes reuse easy and safe. A typical set has a clocks file. It also has an internal-exceptions file. It has a boundary file. And it may have a notes file in plain language. The clocks file makes the block's clocks. The internal file holds false paths and multicycle paths fully inside the block. The boundary file holds the input and output delays. The notes file explains assumptions, like the expected clock period and which ports talk to which clock. Why split this way? Because the top-level engineer reuses some files and skips others. They source the internal-exceptions file directly, after scoping into the instance. They skip the boundary file, since the top times the boundary itself. They read the notes file to learn the block's needs. They may reuse the clocks file only if the block makes its own clocks from a port that still exists.

# illustrative — names vary by tool
# top-level reuse of a packaged IP constraint set
set blk u_dsp
current_instance $blk
source dsp_clocks.sdc        ;# only if block defines its own clocks
source dsp_internal.sdc      ;# false paths, multicycle, internal generated clocks
# dsp_boundary.sdc intentionally skipped — top constrains the boundary
current_instance

A second worked example shows the saving. A block has 47 internal false paths, all tested. The toplevel engineer instances the block. By scoping in and sourcing the internal file, all 47 come across with correct names in one step. Writing them by hand would take hours and invite typos. The boundary file,

holding 6 input delays and 4 output delays, is skipped, because the top now has real drivers and loads for those ports.

Avoiding Conflicts at Integration

Integration is when the block joins the rest of the chip. Conflicts happen when the top-level constraints and the reused block constraints disagree. A conflict can make the tool ignore real paths or report false failures. Avoiding them takes care. The most common conflict is duplicate clocks. The block's clocks file makes a clock named core . The top also makes a clock named core . The tool sees two clocks with one name. The second may override the first, or the tool may error. Fix this by naming block clocks uniquely, or by making the clock only once, at whichever level owns it. Another conflict is an exception that crosses the boundary wrongly. The block's false path was meant for two internal points. After a sloppy remap, the path now reaches a top-level object. It silently disables a real top path. The fix is to confirm both endpoints of every reused exception still resolve to objects inside the block. A third conflict is double-counted boundary delay. The block boundary file is sourced and the top also sets a delay on the same port. Now the port has two delays. The tool may add them or pick one. Either way the timing is wrong. The fix is the rule from before: skip the boundary file at the top.

A final habit is to check constraints after integration. Ask the tool to report unconstrained endpoints and conflicting exceptions. If a reused exception was dropped or doubled, the report shows it. Catching this right after joining is far cheaper than chasing a strange timing result later.

Interview Q&A

file. It creates the block's clocks, sets boundary delays, and marks internal exceptions. We reuse it because those constraints took real effort to get right, and rewriting them at the top level wastes time and risks missing cases the block owner already solved.

nested inside a hierarchy. Its ports and pins gain an instance prefix, like u_codec/data_out . The

golden file used bare names. So every object reference must be remapped with the instance prefix, or the tool cannot find the objects.

paths, multicycle paths, and generated clocks fully inside the block. After remapping names they still mean the same thing. Boundary constraints, like input and output delays, do not travel; they were guesses about the outside that the real top-level logic now replaces.

current location to that block. Object names in the sourced SDC then resolve relative to that instance. This lets you source the same golden internal file once per instance, getting correct prefixed names automatically instead of editing each line by hand.

by purpose: a clocks file, an internal-exceptions file, a boundary file, and plain-language notes. The split lets the top-level engineer reuse the internal file, skip the boundary file, and read the notes, all cleanly.

top both create a clock with the same name; fix it with unique names or a single owner. Double boundary delay happens when the boundary file and the top both set a port delay; fix it by skipping the boundary file at the top.

Key Takeaways

• Golden SDC is a block's trusted constraint file and reusing it saves the real effort that went into getting those constraints right.
• Hierarchy adds an instance prefix to every object, so reused constraints must be remapped, often by scoping into the instance and sourcing the file there.
• Reuse internal constraints but replace boundary constraints, because boundary delays were placeholders the real top-level logic now supersedes.
• A packaged constraint set splits files by purpose so the top engineer can source the internal file, skip the boundary file, and read the notes.
• Check for conflicts after integration, especially duplicate clocks, cross-boundary exceptions, and double-counted boundary delays.