Explain why "only internal nets are annotated in SDF" and how that shapes your verification.

Short Answer

The SDF (standard delay format) standard defines INTERCONNECT delays only for nets internal to the design. A net connected directly to a primary input or output port describes the environment outside the design, and that is modeled instead with set_input_delay and set_output_delay - so non-annotation there is correct behavior, not a coverage gap.

Technical Explanation

• Where the rule comes from. SDF, the standard delay format used to back-annotate real extracted delays, defines INTERCONNECT statements for nets internal to the design. It was never meant to describe anything outside the design's own boundary.
• Why primary-port nets are excluded by design. A net wired directly to a primary input or output port describes something outside the chip - the external driver, the board trace, the environment's own wiring - and stating that is not the SDF's job.
• What models the boundary instead. set_input_delay and set_output_delay (SDC) are the constraints that describe the environment at the boundary; they do the job SDF deliberately leaves alone.
• PrimeTime follows the standard. It annotates delays on internal nets from the SDF, and does not annotate primary-input or primary-output nets - this is expected, correct behavior, not a parsing failure.
• The direct consequence for coverage checking. When report_annotated_delay (PT) lists net arcs from primary inputs, and net arcs to primary outputs, as "not annotated," that is exactly correct and expected. Chasing those entries as missing coverage wastes time, and worse, it trains you to stop trusting the columns that actually matter.
• Where to actually look. Focus verification on the internal net arcs and cell arcs columns. A nonzero "Not Annotated" count there is the real signal of a problem - typically a name mismatch between the SDF and the design netlist, or genuinely missing SDF coverage.
• The useful discipline. Know in advance which categories of the coverage report should be empty and which should not, and only treat a departure from that expectation as a finding worth chasing.

Follow-up Question & Model Response

If report_annotated_delay shows a nonzero not-annotated count in the internal net arcs column, what are the two most likely causes, and how would you tell them apart?

Candidate Model Response: The two most likely causes are a name mismatch between the SDF's net names and the design's current netlist names - often from a post-layout ECO or a renaming pass that ran after the SDF was generated - or genuinely missing SDF coverage, where the extraction or SDF-writing step simply never produced entries for that region of the design. To tell them apart, I'd check whether the missing nets exist in the design at all under a similar or renamed identity; a clear one-to-one name mismatch points to the renaming explanation, while nets that have no plausible counterpart in the SDF at all point to a genuine extraction gap that needs the SDF regenerated.