Quick orientation: your most recent tapeout that raised a flag

• To get us started, briefly describe the tapeout that triggered concern and why it matters for your next node
• How many tapeout-ready designs do you expect to include in the initial pilot Options: One block, One full-chip design, Multiple blocks across a single chip, Multiple chips
• Which signoff disciplines are highest priority for that pilot, select all that apply Options: Static timing, Power analysis, IR drop/PDN, Electromigration, Physical verification, Reliability checks
• Walk me through your timeline from ECO-complete to tapeout for the identified design, including key milestone dates
• Who on your team will be the day to day contact for test runs, correlation questions, and artifact access Options: Director of Physical Design, Block owner or lead engineer, Tool integration engineer, Head of signoff, Other

Where numbers stop being academic

• If your current signoff flow diverges from silicon by the margins you are seeing, what is the one result that would make you insist on a tool change immediately
• How often have timing or power results from your legacy flow exceeded your tolerance against foundry or silicon reference in the last two tapeouts Options: Every tapeout, Most tapeouts, Occasionally, Rarely, Never
• Provide a concrete example of a block or corner where correlation drifted most and what temporary fixes you applied
• Estimate the probability that a false pass at final signoff would lead to a full respin for this design, expressed as a percent Options: 0-5%, 6-15%, 16-30%, 31-60%, 61-100%
• Which downstream teams get pulled into remediation when a signoff miss occurs, select all that apply Options: Physical design, Timing closure team, Package engineering, Validation and bring up, Program management, Foundry contacts

The real cost when signoff misses happen

• How much would a single mask respin plus schedule slip typically cost this program in dollars and weeks Options: <$1M and <4 weeks, $1M-3M and 4-8 weeks, $3M-6M and 8-16 weeks, >$6M and >16 weeks
• How many weeks of schedule and what approximate budget does a mid-size respin consume for your organization
• Name the stakeholders who would need to approve a program-level repayment for a respin and the order their approvals happen
• Rank the financial or schedule metrics your CFO would require to justify a signoff tool change, in order of importance Options: Probability reduction of respin, Projected cost savings over 2 years, Impact on first silicon timing closure, Runtime and infrastructure cost
• Describe the last time your team approved a tool change, what evidence sealed the decision and how long the procurement took

Alternatives you are actively weighing

• If staying with your incumbent or internal scripts were the default option, what evidence would force you to switch vendors or approaches
• Select the alternatives you are currently evaluating or have evaluated recently Options: Incumbent full-suite vendor, Mix of point tools from different vendors, Internal scripts and in-house correlation, Foundry guidance only, New vendor unified signoff suite, Other
• Name any internal champions arguing to keep the current approach and summarize their main argument
• What would have to be demonstrably true about your current flow for you to stay with it instead of changing
• Has anyone on your team proposed solving the correlation and drift issues without an outside vendor, and if so who would own that path and estimated timeline Options: Yes, R&amp;D team, Yes, tools team, No internal proposal yet, Other
• If your incumbent can match correlation within your tolerance and runtime on your largest design, what would still make you consider a vendor switch

Ready to run: access, artifacts, and compute

• Assuming a three week delay in PDK or signoff-rule access, would that force you to delay or cancel the evaluation or can you absorb that delay Options: Cancel evaluation, Delay evaluation, Absorb delay and proceed, Unsure
• List the extraction, parasitic, layout netlist and testbench artifacts you can share for a closed-loop pilot
• Name the compute cluster or cloud account intended for the largest signoff runs and indicate whether your team controls scheduling and quotas Options: On-prem HPC, fully controlled, On-prem HPC, shared control, Cloud account under our control, Cloud account managed by third party, Unsure
• Estimate the dedicated headcount in FTEs your team can assign to correlation, tool integration, and debugging during the pilot Options: <0.5 FTE, 0.5-1 FTE, 1-2 FTEs, 2-4 FTEs, >4 FTEs
• Identify the owner or team responsible for data access approvals, export control review, and legal NDAs required to share silicon measurements and PDKs
• Are there export control, foundry confidentiality, or IP constraints that could limit the artifacts you can share for the pilot Options: Yes, export control limits, Yes, foundry NDA restrictions, Yes, internal IP policy limits, No known constraints, Unsure
• Would inability to share core artifacts prevent a meaningful closed-loop correlation pilot in your environment, or can you run an alternative setup that still validates the engine Options: Prevents a meaningful pilot, Alternative setup possible, Unsure

The measurable gate: how you define pilot success

• Name the one metric that, if the pilot does not meet it, would make you halt the program immediately Options: Timing correlation to silicon, Power correlation to silicon, Runtime on largest design, Capacity for multi-corner analysis, Foundry certification path
• Provide numeric targets for timing correlation to silicon, power correlation, and maximum acceptable runtime on your largest design
• Select the source you consider ground truth for correlation Options: Latest silicon measurements from previous tapeouts, Foundry golden characterization, Internal lab measurements, Foundry-provided reference deck, Other
• How quickly do you require remediation when the pilot reveals a correlation gap, expressed in business days Options: 1-3 days, 4-7 days, 8-15 days, >15 days
• Should the pilot meet correlation targets but show a 20 percent runtime increase, would you accept a phased rollout or require runtime parity before signing Options: Accept phased rollout, Require runtime parity before signing, Need further discussion
• Identify who will sign pilot acceptance and which budget holder will approve deployment spend if acceptance is met
• Assuming the pilot meets the stated targets, what would be the fastest path to a signed purchase order and which approvals could still block a week one close

From pilot to full-chip signoff: owners and rollout mechanics

• Point to the one operational gap between pilot and full-chip signoff that worries you most and could delay production rollout
• Describe the phased rollout you prefer, whether block-by-block or discipline-by-discipline, and the typical length you expect for each phase
• List the internal teams that must be retrained and estimate total person-days required for that training Options: 0-10 person-days, 11-50 person-days, 51-200 person-days, >200 person-days
• How will defect backlogs, correlation tickets, and bug triage be tracked and escalated between your teams and the seller during rollout
• Assign an owner role for integration endpoints, run script maintenance, and license management after deployment Options: Signoff tools team, Platform operations, Block owners, Third party integrator, Other
• Define your stoplight decision rule if the first-block pilot does not meet acceptance, will you continue to next block or halt rollout Options: Halt rollout and investigate, Proceed with remediation plan, Continue to next block with contingency, Decision dependent on root cause

• success_criteria
• decision_readiness
• gaps
• stakeholders
• current_state
• desired_state
• current_state
• desired_state
• gaps
• stakeholders
• decision_readiness
• success_criteria
• stakeholders
• gaps
• decision_readiness
• current_state
• decision_readiness
• decision_readiness
• decision_readiness
• decision_readiness

• Extract unified signoff netlist
• Execute multi-corner multi-mode static timing signoff
• Run power integrity and IR-drop analysis
• Perform electromigration and reliability analysis
• Perform physical verification and DRC/LVS checks
• Integrate foundry rule decks and certification packaging
• Port constraints and SDC scripts to the new engine
• Setup compute scaling and parallel runtime
• Generate violation debug traces and fix guidance
• Implement on-chip variation and aging models in flow
• Validate cross-discipline netlist consistency
• Train engineers on reports and violation-debug workflows

Extract unified signoff netlist

• Which physical database format contains your tapeout-ready layout (for example, GDSII or OASIS) and where is the master copy stored? Options: GDSII, OASIS, Other / mixed formats, Not yet finalized
• How many LEF (Library Exchange Format) macro views and corresponding Liberty (.lib) timing corners must be included in the extracted netlist? Options: Fewer than 50 macros, 50-200 macros, 201-500 macros, More than 500 macros
• Provide the list of file artifacts we must ingest to produce a single extracted netlist (for example: DEF, routed SPEF/CPF, extracted RC, .lib, SDC).
• Identify any custom parasitic or RC back-annotation formats you use (for example, vendor-specific SDF variants or custom SPEF tags). Options: Standard SPEF/CPF, SDF variants, Vendor-custom parasitic format, No custom formats
• Specify ownership: who on your team is the primary owner for layout-to-netlist extraction and who is the escalation contact for netlist mismatches?
• List any extraction rules or exclusions that differ from the foundry PDK (for example, custom antenna-rule exceptions or specific net exclusions).
• Are golden netlist references from previous tapeouts available for byte-for-byte comparison? Options: Yes, full golden netlist available, Partial golden netlists available, No golden netlist available

Execute multi-corner multi-mode static timing signoff

• Which signoff corners and modes must be exercised for comparison (for example: tt, ss, ff, mm, on-chip-variation (OCV) modes, and power-aware modes)? Options: Typical (tt), Slow/slow (ss), Fast/fast (ff), Multi-mode multi-corner (MCMM), On-chip variation (OCV) enabled, Power-aware modes
• How many primary timing paths or endpoint nets should be prioritized for correlation debugging during the POC? Options: Top 100 paths, Top 500 paths, Top 1,000 paths, Custom list (upload)
• Provide the SDC (Synopsys Design Constraints) script(s) you expect to port for mode and clock definitions and indicate any nonstandard constraints (for example, custom false paths or multi-cycle path exceptions).
• Which silicon measurement data from prior tapeouts will you supply for timing correlation (for example, frequency vs measured clock skew, path delay measurements, silicon-in-the-loop reports)? Options: Full silicon delay dataset, Representative subset, Only summary metrics, No silicon data available
• What correlation threshold versus your silicon measurement data defines acceptable timing accuracy (for example, within 1%)? Options: Within 0.5%, Within 1%, Within 2%, Other / define threshold
• Identify the block(s) you want included in the MCMM run for the initial phase (for example: I/O ring, top-level digital block X, analog macro Y).
• Specify the maximum allowed runtime for a full MCMM timing run on your largest block for the POC phase (state hours and compute boundary). Options: Less than 4 hours, 4-12 hours, 12-24 hours, More than 24 hours

Run power integrity and IR-drop analysis

• Which power network deliverables will you provide: full routed PDN, interim PDN, or only power grid cursors? Options: Full routed PDN, Interim PDN (pre-route), Power grid cursors only, Other / mixed
• List the target voltage rails, max transient currents, and decap models that must be represented during IR-drop analysis.
• Identify the power integrity corners to run (for example: worst-case dynamic switching, retention modes, local-vs-global switching). Options: Static worst-case, Dynamic switching worst-case, Retention / low-power modes, Custom set (upload)
• Provide the format and sampling of your current density or activity maps for use in IR-drop sims (for example: switching factor per cell, annotated SDF-based activity).
• Estimate the acceptable voltage drop threshold for nets that would trigger a violation (for example, >5% of nominal rail). Options: >2% of nominal, >5% of nominal, >10% of nominal, Custom threshold
• Specify whether electromigration (EM) cross-checks should be run inside the IR-run or as a downstream flow for the pilot block. Options: Inline with IR-run, Separate downstream EM pass, Both

Perform electromigration and reliability analysis

• Which reliability models do you require (for example: MTTF targets, current density limits per metal layer, and temperature profiles)? Options: Standard current-density limits, MTTF-based models, Temperature-assisted models, Custom reliability models
• Identify the metal layers and via stacks that are most critical for EM checking in this engagement.
• Provide the expected operating temperature range and duty cycles that the analysis should assume. Options: Ambient to 70 C, Ambient to 90 C, Custom range (specify)
• List any mission-profile scenarios to consider (for example: continuous high-duty server workload, intermittent mobile usage).
• Specify the reporting granularity you need for EM violations (per net, per segment, per via). Options: Per net, Per segment, Per via, Summary + drilldown
• Who on your reliability or physical-design team will validate proposed mitigations and accept the EM closure plan?

Perform physical verification and DRC/LVS checks

• Which foundry PDK version and rule deck set must be used for DRC (design rule checking) and LVS (layout versus schematic)?
• Provide the expected DRC/LVS pass criteria you will accept for pilot approval (for example: zero critical DRCs, permitted density exceptions limited to X).
• Identify any waived checks or custom DRC rules applied by your foundry or internal signoff board. Options: No waivers, Foundry-approved waivers, Internal custom rules
• List the netlists and canonical reference schematics we should compare during LVS (for example: top-level netlist, block-level subcircuits).
• Specify whether physical verification should include fill-rule verification, density checks, and OPC (optical proximity correction) compatibility checks. Options: Include all, Exclude OPC compatibility, Custom selection
• How should DRC/LVS reporting be packaged for review (for example: per-block HTML report, aggregated PDF, or per-violation CSV)? Options: Per-block HTML, Aggregated PDF, Per-violation CSV, Other

Integrate foundry rule decks and certification packaging

• Which exact foundry certification package and PDK baseline must be produced for your signoff acceptance (include PDK version identifiers)?
• Name the artifacts you require in the final certification bundle (for example: signed signoff reports, LVS/DRC deck versions, golden netlist, MCMM timing summary).
• Which party provides the foundry rule decks (for example: you supply the validated rule deck or foundry-supplied deck must be pulled during integration)? Options: You will provide validated decks, Foundry must supply decks on our access, Decks not yet available
• What evidence will you accept as proof of certification readiness (for example: passing foundry checklist, signed verification report, or wafer-level test correlation)? Options: Foundry checklist pass, Signed verification report, Correlation against silicon samples, Other evidence
• List any packaging or document formats the foundry requires for submission (for example: specific PDF templates, tarball layout with manifest, or web portal upload).
• Specify any timeline constraints for certification packaging delivery (for example: must be submitted 2 weeks before the tapeout cutoff). Options: Submit 2+ weeks before cutoff, Submit 1 week before cutoff, Flexible / as agreed

Port constraints and SDC scripts to the new engine

• Provide the canonical SDC files that define clocks, false paths, multicycle paths, and IO constraints for the pilot block.
• Identify any custom constraint constructs you use that may not be native to the new engine (for example: vendor-specific clock gating exceptions). Options: No custom constructs, Vendor-specific constructs present, Custom scripts used
• For each clock domain, list target frequencies and jitter budgets that the ported constraints must preserve.
• Estimate the effort to translate your current constraint automation scripts (for example: TCL wrappers) into the new engine's scripting environment. Options: Low (hours), Medium (days), High (weeks)
• Who on your timing team will own validation of the translated SDC and sign off on equivalence?
• Attach or indicate any constraint verification reports you expect after translation (for example: constraint equivalence diff, clock-tree sanity checks).

Setup compute scaling and parallel runtime

• Specify the compute environment you will provide for pilot runs (for example: on-prem cluster specs, cloud instance types, or hybrid). Options: On-prem cluster, Cloud instances, Hybrid on-prem + cloud, Unsure / need recommendation
• Estimate the largest design size in terms of cells, nets, or hierarchical instances that will be processed in the pilot. Options: <1M cells, 1M-5M cells, 5M-20M cells, >20M cells
• What runtime target for your largest block defines acceptable performance (for example, full MCMM timing run within X hours)? Options: Complete within 4 hours, Complete within 12 hours, Complete within 24 hours, No strict target
• Indicate the parallelization model you prefer for runs (for example: per-corner parallelization, hierarchical block parallelization, or per-mode batching). Options: Per-corner, Per-block hierarchical, Per-mode batching, Mixed model
• Provide any licensing caps or concurrency limits that will constrain parallel runs.
• Identify monitoring and alerting expectations for long-running jobs (for example: job heartbeat, auto-retry thresholds, and owner notifications).

Generate violation debug traces and fix guidance

• Which format do you prefer for violation debug artifacts (for example: per-path STA trace, per-net waveform snapshots, or aggregated root-cause CSV)? Options: Per-path STA trace, Aggregated root-cause CSV, Per-net waveform snapshots, Combined package
• List the top debugging deliverables you need for each violation (for example: full STA timing path, extracted parasitic snippet, cell-level netlist slice).
• Who on your engineering team will be the triage owner for debug traces and who is authorized to approve fixes?
• Specify whether you require automated fix suggestions (for example: buffer insertion points, net rebuffering) and in what format. Options: Automated fix suggestions, Only annotated traces, Both
• Provide acceptance criteria for a debug closure ticket (for example: re-run shows no timing violations and path delay within X% of golden).
• Indicate how granular the trace retention should be for audit (for example: keep full traces for 90 days, or summarized data only). Options: Keep full traces 90 days, Keep summarized data only, Custom retention policy

Implement on-chip variation and aging models in flow

• Which on-chip variation (OCV) and aging/BTI model versions must be used (include model identifiers or PDK references)?
• Identify the aging horizons to evaluate (for example: fresh silicon, 3-year BTI, 5-year BTI profiles). Options: Fresh (0 years), 3-year aging, 5-year aging, Other
• Provide the expected effect thresholds that define a violation under aging (for example: timing margin erosion >5% or setup fail at 3-year BTI).
• Specify whether variability-aware signoff should include statistical timing analysis (SSTA) or deterministic corner pessimism adjustments. Options: Statistical timing (SSTA), Deterministic corner + margins, Both

• Non-Disclosure Agreement (NDA)
• Master Services Agreement (MSA)
• Statement of Work (SOW)
• Subscription Agreement / Order Form
• Service Level Agreement (SLA)
• Data Access and Processing Agreement (DPA)
• Pilot Acceptance Criteria
• Certification and Validation Responsibility Agreement
• Change Order Agreement

• Go-live Health Check (weeks 1-4)
• First Measurement Review (weeks 4-10)
• Acceptance Gate Meeting (around day 90)
• Quarterly Operational Review
• Annual Success Review and Lessons Learned

• Update the shared backlog with priority, severity, and target resolution dates
• Record and archive the formal acceptance decision and associated evidence
• Archive or migrate legacy tool data to the agreed storage location and verify integrity
• Publish the remediation plan for any failed criteria with verification tasks and target re-test dates
• Metrics trend review
• Confirm the solution remains within or is trending toward the Solution Scope targets for timing correlation and runtime.
• Maintain a prioritized shared backlog with clear resolution windows for high-severity tickets.
• Ensure closed remediation items are verified and did not cause regressions.
• Reconfirm success criteria and owners
• Escalate persistent correlation gaps with a defined investigation plan and target completion date
• Schedule compute scaling actions if runtime regressions persist and document expected impact
• Year-to-date metrics summary
• Confirm annual realization of correlation and runtime targets and surface any systemic issues that require program-level change.
• Document a concise lessons-learned register and assign next steps for process improvements.
• Establish a recurring backlog grooming cadence and a prioritized list of enhancements for the coming year.
• Publish the annual lessons-learned document and circulate to the program stakeholders
• Update runbooks and configuration baselines to reflect agreed process improvements
• Schedule quarterly backlog grooming sessions and close stale low-priority items
• Deployment validated against the checklist recorded in Solution Scope and any gaps documented.
• Early adoption signals captured and any onboarding gaps scheduled for remediation.
• Immediate blockers are triaged and a short-term remediation plan with target dates is agreed.
• Publish deployment validation checklist and gap list for asynchronous confirmation
• Provide missing PDK access credentials and testbench artifact locations
• Schedule follow-up technical session to remediate any integration failures
• Present measured outcomes versus targets
• Determine whether timing correlation delta and STA runtime are trending toward the Solution Scope targets or require remediation.
• Agree a concrete list of corrective actions with resolution dates and verification steps before the acceptance gate.
• Confirm the date and prerequisites for the acceptance gate meeting.
• Run an expanded correlation job including the identified additional corners and report results
• Adjust extraction and corner definitions as agreed and document configuration changes
• Provision additional compute capacity if runtime regression is confirmed and record expected runway improvement
• Restate acceptance criteria and numeric targets
• Produce a documented acceptance decision for each numeric criterion recorded in Solution Scope, with a named buyer signatory where required.
• Confirm the incumbent tool wind-down approach is documented and scheduled, or confirm retention as read-only with archived data.
• If any criteria failed, agree remediation plan and verify dates for re-evaluation.
• Shared backlog review
• Lessons learned and process improvements
• Present final outcome data per criterion
• Root-cause diagnosis for any shortfalls
• Deployment and configuration validation
• Validation of closed remediation items
• Document pass/fail per criterion and capture signatory
• Shared backlog health and roadmap
• Agree corrective actions and timeline
• User onboarding and early usage signals
• Agree operational cadence and next-year checkpoints
• Blockers and open issues triage
• Confirm readiness timeline to Acceptance Gate
• Prioritize next quarter actions
• Incumbent tool wind-down validation
• Agree immediate remediation actions
• Agree remediation items and resolution timeline for any failed criteria