ExpertQuestion 62 of 69Source: Synopsys PrimeTime User Guide: HyperScale Block Context and Modeling

What HyperScale block context must you refresh before top-level signoff, and what happens if you don't?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

HyperScale, a hierarchical timing method that analyzes a block using a compact model instead of its full netlist, relies on a block context: boundary loads, arrival times, and derating assumptions taken from the top-level environment when the block model was built. If the top level changes after that snapshot, for example the floorplan shifts or a neighboring block's clock tree changes, the block context goes stale, and signoff run against it can pass on paper while the real chip does not.

Technical Reference DiagramWhat HyperScale block context must you refresh before top-level signoff, and what happens if you don't?
A memory controller block's clock input showing a modeled 45ps skew assumption versus the real 95ps top-level skew after a floorplan change, with the un-refreshed model hiding a 20ps hold violation.

Technical Explanation

  • Block context means the boundary conditions the block model assumes: what drives each input pin, what each output pin drives, expected clock latency and skew arriving at the boundary, and the loading each output sees.
  • The tool builds a block's HyperScale model, including its context, from one snapshot of the top-level environment, so the model is only as accurate as the top-level state at that moment.
  • Because floorplanning, clock tree synthesis, and routing often keep changing after a block's model is generated, the top level's real boundary behavior can drift away from what the block model assumed.
  • If context refresh is skipped, top-level signoff analysis effectively times the block using outdated assumptions, so a boundary path could show a false pass or, less often, a false fail.
  • Refreshing context means updating the block's boundary environment to match the current top-level state and either regenerating the model or re-validating that the difference is small enough to ignore.
  • Because a full context refresh can be nearly as expensive as re-analyzing the block, teams typically set a tolerance and refresh only when the top-level change to a block's boundary skew, load, or latency crosses it.
  • Loading is one of the easiest context changes to miss: a neighboring block added late in the floorplan can add fanout or wire length on a shared net without anyone flagging it as a reason to refresh the block that drives it.
  • Because context refresh sits between the block team and the top-level owner, most flows assign a single point of responsibility for tracking staleness, since neither side alone always has visibility into both the block model's snapshot date and the top level's latest state.

Common Mistake

The Trap: treating a HyperScale block model as a one-time deliverable that never needs to be touched again once it passes review, even as the top-level floorplan and clock tree keep changing around it.

  • Signing off top-level timing against a stale block context can hide a real violation that only shows up once the block is re-analyzed with current boundary conditions.
  • Assuming "the block passed standalone" is proof enough skips the actual question, which is whether the boundary assumptions the block was built against still match reality.

Follow-up Question & Model Response

How do you know how much top-level drift is small enough to skip a full context refresh?

Candidate Model Response: Most flows set a tolerance on the boundary quantities that matter most, typically clock skew and arrival time at each interface pin, and compare the current top-level state against the snapshot the block model used. If the difference stays under that tolerance, usually a small fraction of the clock period, the existing model is considered valid; if it exceeds the tolerance, the block context needs refreshing before signoff can be trusted. This threshold is a judgment call balanced against turnaround time, so teams tend to set it conservatively early in the flow and can loosen it once the design has stabilized.

Practical Example

A HyperScale model for a memory controller block is generated when the top-level clock tree gives its clock input a projected 45ps of skew relative to a neighboring block. Three weeks later, a floorplan change moves that neighboring block, and the actual top-level clock tree now delivers 95ps of skew to the same pin, more than double the modeled value. Top-level signoff run against the un-refreshed model shows the boundary path passing with 60ps of margin; after refreshing the block's context with the current 95ps skew and re-running, the same path shows a 20ps hold violation that was hidden the entire time. The team adds a standing check that flags any boundary skew drift past 20ps as a mandatory context refresh before the next signoff milestone.

Complete STA Handbook

Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.

Explore Complete STA Guide →
Static Timing Analysis (STA) Handbook — ten chaptersSTA HandbookTen chapters on setup, hold, OCV, and PrimeTime signoff. →

Continue practising

Related STA questions

IntermediateWhat is HyperScale, and why use it instead of one flat run for a large chip?IntermediateWhat does an ETM actually hide, and what timing information does it keep at the block boundary?BeginnerWhat is hierarchical timing analysis, and why analyze a block on its own?ExpertAn engineer says 'silicon always beats signoff, so our margins must be too conservative.' How do you respond, and what's the danger in that reasoning?