What is a quick timing model (QTM), and how does it differ from an ETM?

Short Answer

A quick timing model (QTM) is a boundary timing model a designer builds by hand, from a spec or an early floorplan estimate, before a block's real netlist even exists. An extracted timing model (ETM) is instead generated automatically from a block's actual, already-implemented netlist. Teams use a QTM early in the flow, often just to hold a placeholder for top-level planning, and replace it with a real ETM once the block is designed and its true timing is known.

Technical Explanation

Early in a hierarchical flow, a top-level integration team may need to run timing before every block has RTL, let alone a netlist -- a QTM lets them place a stand-in with estimated or spec-derived delays so top-level budgeting can start.

• Building a QTM means writing PrimeTime commands that declare the block's boundary pins, their timing arcs, and the delay or constraint numbers assumed for each -- essentially hand-authoring what an ETM would otherwise compute automatically.
• An ETM's numbers come from a real timing solve on a real netlist at a real corner; a QTM's numbers come from an engineer's estimate, so a QTM is only ever as accurate as the assumption behind it.
• Because a QTM is not extracted from silicon-representative data, it is meant to be temporary -- the standard flow swaps it for the block's ETM as soon as the block has enough implementation to generate one, rather than keeping it through signoff.
• A hierarchical timing flow can mix representations across the chip at once -- one block modeled with an ETM because it is finished, another still modeled with a QTM because it is still in early floorplan -- as long as the top-level team tracks which blocks still carry an estimate rather than a measured model.
• Carrying a QTM into final signoff instead of the block's real ETM means the top-level clean timing report is only as trustworthy as the QTM's original guess, which is why a signoff checklist should explicitly confirm every block instance is on its final ETM.

Follow-up Question & Model Response

How would a top-level timing report even reveal that a block instance is still using a QTM instead of its final ETM?

Candidate Model Response: PrimeTime does not flag a QTM as suspect on its own -- a QTM is a legitimate model type and the report treats it like any other boundary model, so nothing in a slack number alone distinguishes it from an ETM. The designer has to check the model source directly, typically by confirming which command built each block's currently linked model and cross-referencing that against the block team's implementation status. A signoff checklist item that lists every hierarchical instance and its model type -- QTM, ETM, or full netlist -- closes this gap by making the swap an explicit, tracked step rather than something the top-level team has to remember to ask about. Without that checklist, the only other signal is a stale-looking timestamp on the model file itself, which is easy to miss in a large integration.