Cadence Innovus PnR Qualification Handbook

How to use this handbook

0.1 Scope of this edition

This edition covers all sixteen chapters, from tool and session qualification to final handoff. Every chapter ends with two cheat sheets: a sanity check cheat sheet, which lists each check with what healthy, review and hard-stop results look like, and a command cheat sheet, which lists the chapter's commands and what each one produces. The Legacy UI and Common UI Tcl script packages follow in a later edition. Options and defaults can change between Innovus releases, so a script written from this book should be checked against the help of the release that will run it.

The handbook is written for engineers who already know what placement, clock tree synthesis and routing are. It does not teach the algorithms. It teaches how to decide whether the output of each step can be trusted.

0.2 Legacy UI and Common UI

Innovus has two command interfaces. The Legacy UI uses camelCase commands such as checkDesign and timeDesign. The Stylus Common UI, started with innovus -stylus, uses snake_case commands and a database attribute model built around set_db and get_db. It is tempting to translate one into the other by changing the case of the name. That does not work. Two commands with similar names can differ in default behaviour, object scope, the analysis context they use, and what they write.

The material provided for this edition documents the Legacy UI in full. For the Common UI, only the commands that appear in the Innovus+ Rapid Adoption Kit lab could be confirmed. Thus, every command card prints the Legacy syntax, and prints a Common UI form only when it was confirmed. Where it was not, the card says so, and the item stays open until it is confirmed against the Stylus Common UI Text Reference and Migration Guide.

0.3 Labels used in this book

Each command also carries its effect on the session, because qualification commands are supposed to observe the design, not change it. The effect is one or more of: reads or reports only, adds GUI violation markers, changes analysis configuration, updates the design database, writes files, or runs an expensive analysis. A script that is meant to check a stage should contain only the first three kinds unless a step deliberately prepares the next stage.

0.4 Stages and gates

The chapters follow the order of a typical block implementation, shown in Figure 1. The order is an organisation of the material, not a claim that every team runs the same sequence. Floorplan and power planning often iterate, pre-placement checks are sometimes merged into placement, and any ECO sends the flow back to the stage it disturbs. Each arrow carries a gate: the point where the evidence for the stage is reviewed and a decision is written down.

0.5 The five qualification statuses

A check ends in exactly one of five statuses. The important part is the order in which we decide, shown in Figure 2. Before asking whether a result is good, we ask whether the check applies to this flow, and then whether it actually ran in the right context. A check that never ran cannot pass, and a report that does not say what it covered is not evidence of anything.

Thresholds come from three places: the libraries (for example maximum transition and capacitance), the foundry (rules and decks), and the project methodology (utilisation targets, margins, waiver policy). This book does not invent universal numbers for any of them. Where a number appears in an example, it is marked illustrative.

0.6 How a command card reads

Each check is written as a card with the same rows, so a reader can jump straight to the part they need. The first rows say what the check is for: the question it answers and the state the design must be in. The middle rows give the Legacy syntax, the Common UI status, the options and the effect on the session. The last rows tell the reader how to judge the result: the fields worth reading, what healthy, warning and hard-stop results look like, the usual misuse, the fix, and what to rerun after it. The verification row states what the syntax was checked against. After every chapter, a two-column cheat sheet lists the commands of that chapter and what each one produces.

Master stage, check and report matrix

The first table below maps report families to stages. A filled circle means the family is primary evidence at that stage, an open circle means it is supporting evidence, and a dash means it is not normally read at that stage. The columns follow the sixteen chapters, so you can see where a check moves to as the design matures.

Three rules apply to every cell of this table. First, record the context with the report: release, UI, checkpoint, stage and analysis view. A report without its context cannot be compared with the next run. Second, say whether the report is preliminary, implementation-level or signoff evidence. A congestion map before placement is preliminary, and treating it as proof of routability is a common mistake. Third, pair reports that can mislead on their own. Timing slack needs view coverage and unconstrained-path counts beside it, and a clean connectivity report needs the list of nets that were excluded from it.