STA Engineer Guide

You are a senior STA engineer. Analyze this failing setup timing path report.

For the report below, tell me:
1. What is the slack value and is it setup or hold violation?
2. What is the critical path (startpoint → endpoint)?
3. Which cell in the path has the highest delay contribution?
4. What is the clock skew between launch and capture?
5. How much CPPR credit is applied (if any)?
6. What are the top 3 ECO options to fix this violation?
   - Option A: logic restructuring (if applicable)
   - Option B: buffer/inverter upsizing
   - Option C: path splitting / pipelining
7. Which option has the least physical impact?

[PASTE TIMING PATH REPORT HERE]

Analyze this hold timing violation.

Questions:
1. What is the hold slack and which path is failing?
2. Is this a real hold issue or a false hold from missing multicycle path exception?
3. What is the data path arrival time vs. hold requirement?
4. How many delay cells (BUF_X1 or DLY cells) are needed to fix this hold?
   Assume each BUF_X1 adds ~0.05ns in this library.
5. Where exactly should the delay cells be inserted (startpoint side vs endpoint side)?
6. Is there a risk that this hold fix will break setup timing?

[PASTE HOLD PATH REPORT HERE]

Compare these two PrimeTime timing reports for the same path from two different runs.

Run A: [before ECO / before PnR change]
[PASTE REPORT A]

Run B: [after ECO / after PnR change]
[PASTE REPORT B]

Tell me:
1. What changed in terms of slack (better or worse, by how much)?
2. Which cells changed delay (upsized, replaced, rerouted)?
3. Did clock skew change? By how much?
4. Did CPPR credit change?
5. Is the ECO effective? Is there a risk of regression on other paths?
6. Summary: what was the root cause of the improvement/degradation?

Write a complete SDC clock constraints file for this design.

Clock architecture:
- Primary clock: CLK_IN at pin clk_in, 500 MHz (2ns period)
- PLL output: CLK_CORE at 1 GHz (1ns period), divided from CLK_IN
- Generated clock: CLK_DIV2 at 500 MHz, divided by 2 from CLK_CORE
- Generated clock: CLK_APB at 100 MHz, from CLK_CORE via clock divider reg

Jitter and uncertainty:
- Input jitter (CLK_IN): 50ps
- PLL output jitter (CLK_CORE): 20ps
- Clock tree uncertainty (setup): 100ps, (hold): 50ps

Clock latency:
- CLK_CORE source latency: 0.3ns
- CLK_APB source latency: 0.5ns

Generate: create_clock, create_generated_clock, set_clock_uncertainty,
set_clock_latency, set_clock_transition commands.
Add comments explaining each constraint choice.

Generate SDC I/O timing constraints for this interface.

Design: AXI4-Lite slave with 100 MHz clock (CLK_CORE)
Board model:
- PCB trace delay: 1.5ns
- External device setup time: 2ns
- External device hold time: 0.5ns
- Clock-to-output requirement: 3ns max

Generate:
1. set_input_delay for all AXI input signals (min and max)
2. set_output_delay for all AXI output signals (min and max)
3. set_driving_cell for inputs
4. set_load for outputs
5. Explain the formula used: input_delay = board_delay + ext_setup - clk_uncertainty

Port groups to constrain:
- AXI write channel: AWVALID AWADDR AWPROT WVALID WDATA WSTRB BREADY
- AXI read channel: ARVALID ARADDR ARPROT RREADY

Based on this design description, generate all timing exceptions in SDC.

Design context:
- Configuration registers written by APB at 100 MHz, read by datapath at 1 GHz
- Test mode mux controlled by scan_en signal (static during mission mode)
- Reset synchronizer flops for wr_rst_n and rd_rst_n (async assert, sync deassert)
- Status register captured by software (no timing req from HW side)
- Power-down domain signals: pd_ctrl[7:0] (only valid when domain is active)
- Bidirectional clock domain crossings use FIFO gray pointers

For each case, write the exact SDC command with:
- set_false_path or set_multicycle_path
- -from / -to / -through as appropriate
- A comment explaining why this exception is valid
- Any risk: could this exception mask a real timing issue?

Walk me through the OCV and CPPR calculation for this timing path.

Path details:
- Launch clock path delay: 2.1ns (before OCV)
- Capture clock path delay: 2.4ns (before OCV)
- Data path delay: 0.85ns (before OCV)
- OCV derating factor: 5% (early paths), 5% (late paths)
- Clock period: 2ns
- Setup margin: 0.05ns

Steps I want to see:
1. Apply late derating to launch clock and data path
2. Apply early derating to capture clock path
3. Calculate pessimism on common clock path (CPPR credit)
   - Common path = first 1.5ns of both clock paths
4. Compute final slack: Required time - Arrival time
5. Show how much slack improvement CPPR gives vs no CPPR

Also explain: Why is applying derating to both clocks in the same
direction (both late) overly pessimistic for paths sharing a clock root?

My project is a 5nm ASIC at 1.1GHz targeting automotive grade (AEC-Q100 Grade 1).

Compare AOCVM (Advanced OCV with multipliers) vs POCVM (Parametric OCV with
location-based variation) for my signoff methodology.

Tell me:
1. What is the key difference in how each models on-chip variation?
2. Which is more pessimistic and by how much (typical 5nm numbers)?
3. What tool commands set up each methodology in PrimeTime?
4. Which methodology does automotive signoff typically require?
5. How does POCVM correlate to silicon measurement vs AOCVM?
6. My TNS is -500ps with AOCVM — rough estimate of TNS with POCVM?

Provide the PT Tcl commands to switch between the two.

I have these top 5 failing setup paths after final PnR. Develop an ECO plan.

Path 1: slack = -0.42ns, endpoint FF_A/D, logic depth = 18
Path 2: slack = -0.38ns, endpoint FF_B/D, logic depth = 22 (shares 8 cells with Path 1)
Path 3: slack = -0.21ns, endpoint FF_C/D, logic depth = 14, inside power domain PD1
Path 4: slack = -0.18ns, endpoint FF_D/D, logic depth = 11, clock domain crossing
Path 5: slack = -0.12ns, endpoint FF_E/D, logic depth = 9, output pad

For each path:
1. Recommend ECO type: resize, reroute, buffer insertion, logic restructure, or pipeline
2. Estimate effort: (Low/Med/High) based on logic depth and shared cells
3. Flag any paths that might be false violations (CDC, output pad, power domain)
4. Propose fix order to get maximum TNS improvement per ECO iteration
5. For paths 1 and 2 sharing cells — will fixing path 1 help or hurt path 2?

Write a PrimeTime ECO Tcl script to fix this timing violation.

Failing path:
- Startpoint: u_mac/data_reg[7]/Q (FF, clocked by CLK_CORE)
- Endpoint:   u_acc/sum_reg[7]/D  (FF, clocked by CLK_CORE)
- Slack: -0.31ns
- Worst cell: u_mac/U_MUL/U47 (AND4_X4) — delay 0.28ns, fanout 12

Fix strategy: upsize u_mac/U_MUL/U47 from AND4_X4 to AND4_X8

Generate PT ECO commands to:
1. size_cell the instance to AND4_X8
2. Re-run timing on that path
3. Report new slack
4. Check if hold margin is still OK after upsizing
5. Write the ECO netlist to eco_fix_01.v

Also show how to use fix_eco_timing -setup for automated ECO suggestion
on this path as an alternative.

Analyze this clock tree summary report from CTS.

For each clock domain in the report:
1. What is the global skew and local skew?
2. Are there any skew groups with >200ps local skew? (flag as WARNING)
3. What is the clock tree depth (number of buffer levels)?
4. Is the insertion delay within expected range for this technology node?
5. Are there any clock topology issues (high fanout nodes, unbalanced branches)?
6. Which clock tree groups should be re-balanced before signoff?

Also explain: what is the difference between global skew and local skew,
and which matters more for setup vs hold timing?

[PASTE CLOCK TREE SUMMARY REPORT HERE]

Write CTS constraints for Cadence Innovus for my design.

Clock domains:
- CLK_CORE: 1 GHz, target skew 100ps, max insertion delay 500ps
- CLK_APB:  100 MHz, target skew 200ps, max insertion delay 800ps
- CLK_DIV2: 500 MHz, derived from CLK_CORE, share root with CLK_CORE

Non-default rules (NDR) for clock nets:
- Use 2x spacing, 1.5x width on all clock routes above M3
- No via doubling below M3

Clock cells to use: CLKBUF_X4, CLKBUF_X8, CLKINV_X4 (no data buffers on clock)
Clock gating cells: ICGX_X4 (integrated clock gating cell)

Generate the Innovus Tcl commands:
- create_ccopt_clock_tree_spec
- set_ccopt_property for skew, latency targets
- NDR rule setup
- exclude_cells for data buffers on clock nets

Write a formal timing waiver justification for this failing path.

Failing path details:
- Path: scan_en → u_scan_mux/Y → u_ff/D
- Violation: -0.8ns setup slack
- Frequency: 1 GHz (mission mode)
- Reason for waiver: scan_en is a static signal during mission mode
  (only toggles during DFT scan shift, never during functional operation)

Write a waiver document including:
1. Path identification (from/to/through)
2. Technical justification (why this path cannot cause functional failure)
3. Operating condition under which the path is exercised
4. Verification evidence (simulation, formal proof, or functional guarantee)
5. Risk assessment: LOW / MEDIUM / HIGH
6. The PT SDC command to apply the exception: set_false_path -from [get_ports scan_en]
7. Sign-off owner field (placeholder)

Format as a professional engineering waiver document.

Act as a signoff STA lead. Review this project's timing closure status
and tell me if it is ready for tapeout.

Design summary:
- Technology: 7nm FinFET
- Frequency target: 1.2 GHz (CLK_CORE), 200 MHz (CLK_APB)
- Corners run: SS/0.72V/125C (setup), FF/0.88V/-40C (hold)
- WNS (setup): -0.005ns (1 path, waiver pending)
- TNS (setup): -0.005ns
- WNS (hold): +0.020ns
- Number of waivers: 3 (scan_en, test_mode, por_rst)
- DRC clean: yes
- LVS clean: yes
- IR drop: max 42mV (spec 50mV)
- EM: all clean

Checklist:
□ All setup paths positive slack (excluding waivers)?
□ All hold paths positive slack?
□ Waivers technically justified?
□ All process corners covered?
□ IR drop within spec?
□ Clock tree balanced?
□ Output delays constrained?

Flag any concerns. Should I proceed to GDS submission?

My setup WNS degraded from -0.05ns to -0.38ns between PnR iterations.
Help me find the root cause.

Change log between iterations:
- Added 3 new scan chains (DFT ECO)
- Updated SDC: changed set_clock_uncertainty from 0.1ns to 0.15ns
- Rerouted the power mesh in block B (increased routing congestion)
- Updated timing libraries to latest characterization (v2.1 → v2.2)

Investigation approach:
1. Which of these changes most likely caused the -0.33ns regression?
2. How do I isolate the root cause? (suggest specific PT comparison commands)
3. What is the typical timing impact of adding scan chains?
4. Can a library update alone cause 0.33ns degradation?
5. How does routing congestion affect setup timing?
6. Generate the PT Tcl commands to compare two run databases
   and extract the top changed paths.