Why clock gating timing is difficult to meet?

oUsually, data path logic is high

  • If gater is not cloned or not cloned efficiently, can create balancing issues and result in timing vios.
  • If latency is not in control or net and high drive strength cells are don’t use can create difficulty in ckg timing closure.
  • Usually, CKG path having negative skew resulting in difficulty in setup fixes. Negative skew because CTS try to balance skews between CKG fanout and FF before it.

Share:

Why set different layers for trunk, leaf, and top clock nets? Why not shield all clock layers?

oWhy Different Layers:

  • Top Nets: These are the initial long branches of the clock tree. That distributes clock all over the block. They are placed on higher metal layers because these layers have thicker wires with lower resistance, which is critical for minimizing the overall tree latency.
  • Trunk and Leaf Nets: As the tree branches out closer to the flops, it moves to intermediate and lower metal layers. These layers are better for shorter, high-density routing.
  • Why Not Shield All Layers:
  • Routing Resource Congestion: Shielding consumes routing resources. Adding a VSS/VDD shield next to every clock wire would make it impossible to route the rest of the design’s signals.
  • Not all the clock net’s need shielding, Shielding is most effective on the long nets that are most susceptible to coupling. Leaf-level nets are shorter and may not show critical level of coupling.

Share:

Why timing may degrade after CTS?

oClock groups might be updated after CTS based on new tree topologies causing new violation.

  • Physical Detours and Congestion: The newly inserted clock buffers and routing can create congestion, forcing data path signals to take longer routes (detours) around the clock tree structures, thereby increasing their delay.
  • CTS might trigger ECO fixes or buffer legalization that shifts data path buffers or cells.
  • Actual skew values achieved is more than expected and considered in uncertainty, causing mismatch.
  • CTS fixes DRC. And move around cells can cause timing violation.
  • Very tight CTS constraint can cause CTS to add more buf/inv creating congestion and shifting nonCTS cells.

Share:

Have you seen setup fails in ATPG TEST mode?

oScan shift runs at lower frequency but scan capture runs at function or near functional frequency. In capture mode we can see setup violations.

  • ATPG patterns activate paths that might not be the most critical during normal functional operation but become critical under specific test stimuli. These paths might not have received sufficient optimization focus during PnR if only functional mode was prioritized.
  • False Paths in Functional Mode: Paths that were correctly defined as false paths during functional mode might become active during certain ATPG patterns (especially if set_case_analysis for test mode enables them).

Share:

Hold timing is checked in which mode (Max or Min)? Why?

oHold timing is checked using Minimum (Min) path delays. This is often referred to as Min Timing Analysis or Best-Case Analysis.

  • Hold Violation Condition: A hold violation occurs if the new data launched by the launch flop arrives at the capture flop before the capture flop has had enough time to reliably capture the previous data from the same clock edge. In other words, the data path is too fast relative to the clock path.
  • Worst-Case for Hold: The worst-case scenario for a hold violation happens when:
  • The data path is at its fastest possible speed (minimum delay).
  • The launch clock path is at its fastest possible speed (minimum latency).
  • The capture clock path is at its slowest possible speed (maximum latency).
  • Therefore, hold checks use minimum path delays (Min timing mode) to find the scenario where data arrives earliest, posing the greatest risk of violating the hold requirement.

Share:

How are TEST mode & FUNC mode defined and constrained?

oDefining Modes: Different operating modes are : Functional mode - FUNC and test Modes: Scan Shift, Scan Capture, BIST

  • Defined in MCMM setup with create_constraint_mode command and given separate SDC of each mode.
  • Separate SDC Files: Each SDC file contains the appropriate set_case_analysis settings, relevant clock definitions (test clocks might differ from functional clocks), and potentially different timing exceptions or I/O delays specific to that mode.
  • Mode-Specific Constraints within one SDC: Less commonly, complex logic within a single SDC file might be used to apply constraints conditionally, but separate SDCs or set_case_analysis are standard.

Checking Simultaneously (MMMC):

Share: