Technology
›
Semiconductor & Chip Design
›
Chip Design Tools & Flows
Chip Front-End Design (SoC/ASIC)
Long-cycle design programs where IP, foundry, and ecosystem partnerships execute against tapeout and market windows.
Example organizations in this space:
Cadence
Synopsys
Mentor (Siemens EDA)
Aldec
This interactive experience is the shipped product itself — the same application code customers run in production, mounted read-only in your browser over a real sample journey. Not a video, not a mockup: because the demo and the product are one codebase, it can never drift from the real thing.
Inside this journey
-
Pre-Sales
Qualify technical fit and decision readiness before investing in full discovery.
-
Qualification
Confirm budget window, decision process, and technical authority before investing in a full technical discovery and benchmarking plan.
Qualification Questions
Benchmark readiness and success criteria
- To make the best use of a technical discovery, do you already have one or more 'hardest' design blocks available with RTL and constraints for benchmarking?
- Which measurable outcomes will determine whether a benchmark run is successful for you?
- Please name the primary block you expect us to evaluate and the specific timing or PPA gap you are trying to close.
Compute, access, and environment fit
- Can you provide the compute and license access needed to run benchmarks, or would you prefer the seller to provision cloud resources?
- Roughly how large are the benchmark runs (peak cell count, gate count, or expected runtime per run)?
Migration effort and CAD capacity
- How much CAD engineering time can you realistically allocate to flow migration and benchmarking support over the next three months?
- Do you have scripting and flow artifacts that must be migrated (for example TCL flows, build scripts, CI integrations)?
Budget, decision authority, and timing
- Is there an allocated budget range for a benchmarking and evaluation engagement?
- Who will sign the engagement or purchase and which roles will influence the decision? Please list titles.
- What timeline or milestone is driving this evaluation? If there is a tapeout date or required decision window, please state it.
-
Technical Discovery
Map the buyer's hardest timing blocks, current synthesis flow, constraints, compute resources, and measurable success criteria for benchmarking.
Discovery Questions
Quick orientation: your top synthesis pain
- Tell me about the single synthesis block you most want to fix right now, including its role in the chip and any past attempts to rescue it.
- Describe the immediate business impact when that block misses timing, for example schedule slip, added verification cycles, or missed milestones.
- How soon do you need a measurable improvement to avoid further schedule slip or escalation?
- Who is the decision owner for approving a benchmarking pilot and signing off on pilot outcomes?
- Which specific PPA or runtime improvements would make the pilot worth your team's effort to migrate flows for evaluation?
When the hardest block refuses to behave
- Walk me through the last time that block failed timing despite multiple ECOs, what steps were taken, and why it remained unresolved.
- Give an example of the RTL construct or coding pattern inside that block that you suspect triggers placement congestion or poor QoR.
- How many synthesis plus ECO iterations did that case require before you temporarily met timing, and who repeated them?
- When you ran your incumbent flow on that block, which metric diverged most from target, worst negative slack, power, or area?
- Who on your team spent the majority of time on those manual fixes and what role do they hold?
Where the flow grinds to a stop
- Pinpoint the infrastructure or dependency that most often stalls your synthesis or benchmarking runs, and why it matters.
- Describe your typical synthesis compute pool, node sizes, and memory limits you assign to large jobs.
- Do you have a dedicated bench for long synthesis runs or do you share cluster time across multiple projects?
- Which license model do you run today, node-locked or floating, and can you expand licenses for a pilot?
- On average, how long do stalled or failing runs block downstream RTL-to-layout or P&R timelines?
- Are storage throughput or network caps a recurring cause of job failures when handling large netlists or constraints?
If we ran a benchmark, this is how you'd judge it
- If a benchmark reduces runtime but not timing, would you consider the pilot successful or a failure for adoption?
- List the top three quantitative metrics and exact thresholds you will require to accept pilot outcomes, for example target WNS, power delta, or runtime goal.
- Name the stakeholders who must sign off on these metrics and whether they require separate SME verification.
- Provide the minimum number of distinct 'hard blocks' you need results on for the pilot to be statistically representative, and why.
- If a run misses the gate, what fixed remediation window would you allow before pausing the evaluation, for example 2 weeks?
- Could a pilot that meets your acceptance criteria accelerate procurement to sign within the current quarter?
Who must give up time and what it costs you
- Identify who would be pulled off other projects to handle flow migration, and estimate how long those engineers would need to be reallocated.
- Outline your current flow automation and scripting languages, and flag which parts are fragile or proprietary.
- Do you run nightly CI regressions that include synthesis, and are those regression artifacts (logs, golden checks) available for benchmarking?
- List the parts of your flow that require vendor tool wrappers or proprietary scripts that must be ported for an evaluation.
- Estimate the FTE-months your CAD team would need to complete migration work if handled internally rather than with external support.
Who else is in the running and why they matter
- Name the alternatives you are actively evaluating right now, including incumbent toolchains, other vendors, or an internal build option.
- Provide the incumbent toolchain components you would need parity with to replace your current setup, such as linting, CDC, and synthesis hooks.
- Are there internal proposals to build this capability without an outside vendor, and who proposed them?
- Explain the single condition that would have to be true for leadership to keep the current approach rather than switching to a new tool.
- Rank the top three competitor capabilities or internal strengths that would most influence your decision, highest to lowest.
Integration showstoppers and data readiness
- Identify a single integration dependency, API, or dataset that, if unavailable, would halt the pilot entirely.
- Share the owners and their availability windows for PDKs, golden netlists, and build artifacts required for benchmark runs.
- Confirm whether your security review, NDA, or export control process can clear within four weeks to allow data transfer for benchmarking.
- Specify the formats and transfer methods you require for RTL, constraints, and test vectors.
- What contingency would you accept if a key owner cannot provide data on your ideal timeline?
Decision velocity, approvals, and blockers
- Assuming the pilot demonstrates a measurable 10 percent PPA improvement, who must approve procurement and how quickly can they act?
- Share your procurement windows and blackout periods that might prevent quarter-end signing.
- Tell me who holds the budget for tool qualification and whether those funds are already assigned or need reallocation.
- Give the shortest technical validation timeline you would accept before committing to a purchase, expressed in weeks.
- Confirm any legal or procurement clauses that typically require amendment for EDA tool licenses, such as indemnity or export terms.
- Pinpoint the final internal condition that would still prevent you from signing this quarter even if the pilot meets its gates.
Starting strong: commitments for a useful pilot
- Assuming we can start within your access window, what single internal decision could stop the pilot before it begins?
- Outline the pilot scope that would be sufficient for your team to judge full-tool adoption, including number and type of blocks and run types.
- Capture the deliverables, reports, and CI artifacts you require at pilot close to support procurement and engineering signoff.
- State the named owners for escalation during the pilot and confirm whether they are already committed to the timeline.
- Specify your preferred cadence for status updates and what evidence you expect in each update, for example logs, slack reports, metric deltas.
- Define the fast-fail criteria you will use if early runs expose major regressions and how you will re-scope the pilot in response.
-
-
Solution Alignment
Translate discovery findings into a shared test plan, target PPA/runtime goals, and the acceptance criteria the evaluation will use.
Solution Experience
- Solution Alignment Session
- Confirm the current state and its cost
- You confirm the exact set of hardest blocks, input vectors, and run conditions that will be benchmarked.
- Provide a draft shared test plan with target PPA, runtime goals, acceptance criteria, and proposed run order within 5 business days.
- You confirm numeric PPA and runtime targets and explicit pass/fail acceptance criteria for the evaluation.
- Agree exact benchmark scope
- Provide RTL, input vectors, reference timing reports, and any required simulation stimuli for the agreed hardest blocks within 7 business days.
- You agree to the evaluation timeline, named responsibilities, and compute/access requirements needed to begin runs.
- Provision compute resources and access credentials required for benchmarking, or confirm already-available capacity, within 10 business days.
- Define target metrics and acceptance criteria
- You agree on the evidence package and specific report formats that will be used to decide success.
- Translate discovery into the test plan and responsibilities
- Deliver a sample timing and PPA report template for validation before runs begin within 3 business days.
- Schedule the follow-up checkpoint to start runs once the artifacts and access are provided.
- Map the evidence package
- Agree timeline and decision gates
- Validation checkpoint
- Solution Alignment Session
- Solution Alignment Deck
- Solution Alignment Brief
- meeting
- slides
- document
-
Solution Scope
Define benchmark blocks, deliverables, migration assumptions, responsibilities, and measurable acceptance criteria for the evaluation and rollout.
Scope Configuration
- Install and Configure Front‑End Tool Suite
- Port and Convert Existing Synthesis Scripts
- Import RTL and Timing Constraints into Flow
- Physical‑Congestion‑Aware Logic Synthesis
- Incremental Synthesis and ECO Netlist Generation
- Clock‑Domain Crossing Analysis and Fix Generation
- Deploy Linting Rules and Auto‑Fix Scripts
- Formal Property Checking and Proof Runs
- Integrate Synthesis Outputs into P&R Handoff
- Scale Batch Synthesis on Compute Cluster
- Calibrate ML Physical‑Prediction Models for PDK
- Generate Timing, Area, and Power Reports
Scope Questions
Install and Configure Front‑End Tool Suite
- Which host operating systems and versions will you deploy the front-end tool suite on (for example RHEL 8, CentOS 7)?
- Do you have an existing license server hostname and license pool sizes available for synthesis and formal runs?
- How many concurrent synthesis or formal sessions must be supported on peak days?
- Who on your team will own tool-suite administration, package updates, and license renewals (name and email)?
- Provide the repository path or archive location where your current tool installation scripts and PDK tarballs reside.
- Are there air-gapped or restricted networks that prevent direct download of PDK files or license keys during install?
Port and Convert Existing Synthesis Scripts
- Which repository or artifact store contains your current synthesis scripts (.tcl, .sh, Makefile) and sample run logs?
- Confirm whether your existing scripts reference vendor-specific tool command names or environment variables that will require mapping.
- How many distinct synthesis flows (for example top-level full-chip, hard-ip, incremental ECO) must be converted?
- Identify any custom TCL procedures or in-house APIs called by your scripts and attach examples of those procedure definitions.
- Name the hardest-timing block(s) (module instance names) whose run commands we should use as conversion templates.
- Are there code-signing, audit trail, or internal change-control requirements for modified scripts?
Import RTL and Timing Constraints into Flow
- Which RTL file formats and languages do you use for the target blocks (.v, .sv, mixed Verilog/SystemVerilog)?
- Specify the canonical SDC constraint file pathname we should import for the hardest block and any additional per-subsystem SDCs.
- How many top-level hierarchy files and aggregated RTL modules must be parsed for a single synthesis run?
- Do you have encrypted third-party IP or black-box netlists that require wrapper generation during import?
- Provide a sample static timing analysis (STA) report or failing path extract that demonstrates the timing challenge on the referenced block.
- Are there special PDK corners or library thresholds (for example TT, SS, FF, nominal voltage) tied to the SDC that we must import?
Physical‑Congestion‑Aware Logic Synthesis
- Describe the current floorplan artifacts you can provide (LEF/DEF, placed macro locations, congestion heatmap) for use by the physical-prediction engine.
- Select which physical inputs you can share for congestion prediction.
- Indicate the design rule or PDK constraints that most influence congestion (for example, minimum metal width, keepout regions, or macro abutment rules).
- How do you currently account for placement congestion during synthesis (for example ignore, heuristic penalties, post-route iterations)?
- Estimate the typical runtime budget you allow per synthesis iteration on your hardest block (in hours).
- Are there routing blockages or pre-placed macros that must be treated as hard exclusions during congestion-aware heuristics?
Incremental Synthesis and ECO Netlist Generation
- Which ECO netlist format do you require for downstream flows (for example gate-level Verilog netlist, structural netlist, or delta-ECO TCL)?
- Do you maintain an incremental-change window policy (for example restricted to one module or limited number of nets) that our ECO netlists must respect?
- Who will review and apply generated ECO netlists in your P&R flow and what is their expected turnaround SLA?
- Provide the revision control workflow you use for netlists (for example branch naming, commit message format, tag policy).
- Are golden gate-level regression vectors and baseline STA reports available to validate ECO changes automatically?
- List the maximum acceptable number of ECO iterations we may generate before a manual design review is required.
Clock‑Domain Crossing Analysis and Fix Generation
- Which clock domains and net names are the most timing-critical or known to have asynchronous crossings in the target block (provide names from your RTL/SDC)?
- Identify available CDC artifacts you can share: RTL assertions, existing synchronization templates, and prior CDC reports.
- Specify the maximum allowable unresolved asynchronous crossings in your CDC acceptance policy for the evaluation.
- Which automatic CDC fix strategies do you permit (for example insert synchronizers, add handshake, or route-to-common-clock)?
- What acceptance criteria will confirm CDC fixes are sufficient (for example zero unresolved asynchronous crossings in the CDC report and automated formal check pass for listed blocks)?
- Who is responsible for approving generated CDC changes and what verification sign-off is required before committing modifications to your RTL repository?
Deploy Linting Rules and Auto‑Fix Scripts
- Which lint rule set do you currently use or prefer (for example company-standard checklist, industry guideline, or strict SVA-related checks)?
- Do you allow auto-fix scripts to modify RTL directly or should they generate suggested patches for manual review?
- Provide examples of frequent lint violations from your last lint run (log excerpts or rule IDs).
- How many designer teams and coding-style profiles must be supported by rule scoping (for example core IP team, I/O team, analog-iface team)?
- Are there auto-fix operations that are explicitly prohibited (for example automated renaming, width changes, or handshake insertion)?
- Who will sign off on the final lint rule profile before it is enforced in CI jobs?
Formal Property Checking and Proof Runs
- Which property language and file locations do you use for assertions (for example SystemVerilog Assertions .sva files and associated directories)?
- Do you have a prioritized list of safety or functional properties for the hardest block that we should prove first?
- Provide sample failing properties or known corner-case sequences that must be included in proof runs.
- Select the expected proof depth or bounds you require (for example bounded model checking depth or full proof expectations).
- Who on your verification team will be the primary contact to triage proof failures and supply guidance for additional assumptions or lemmas?
- Are formal runs allowed to use black-boxing strategies for large IPs or must proofs remain compositional with full visibility?
Integrate Synthesis Outputs into P&R Handoff
- Which handoff artifacts do you require from synthesis (for example gate-level netlist, liberty timing, SDF, pin mapping, and LEF)?
- Confirm whether your P&R team expects specific netlist naming conventions or header metadata in the generated netlist.
- List the P&R golden deck or reference scripts we should use to validate a handed-off netlist with your static timing analysis flow.
- What evidence will validate a successful handoff (for example generation of LEF and gate-level netlist, correct pin mapping CSV, SDF insertion, and a 'green' STA run using your golden P&R deck)?
- Who will be the P&R owner confirming pin mapping and block-level integration for synthesis outputs?
- Are there format constraints for exchange (for example compressed archives, signed manifests, or checksum requirements)?
Scale Batch Synthesis on Compute Cluster
- Which cluster scheduler do you use (for example SLURM partition names or internal queuing system)?
- Specify the typical node capacity and core counts available for synthesis jobs (for example 64 cores/node, 128 GB RAM).
- Do you provide container images or do we need to supply Docker/Singularity images for reproducible runs?
- Indicate the maximum walltime per batch job your cluster enforces for long synthesis runs.
- Who manages job submission credentials and what is the preferred method to authenticate submission (for example SSH key, token, or service account)?
- Are there quota limits or priority classes that will affect how many simultaneous synthesis runs we can schedule?
-
Solution Evaluation
Execute the agreed benchmarking runs: synthesis, linting, CDC checks, and PPA/runtime comparisons against incumbent tools using the buyer's hardest blocks.
- gaps
- current_state
- decision_readiness
- desired_state
- stakeholders
- success_criteria
- stakeholders
- gaps
- decision_readiness
- success_criteria
- current_state
- desired_state
- stakeholders
- decision_readiness
- decision_readiness
- decision_readiness
- decision_readiness
- decision_readiness
-
Mutual Commit
Finalize commercial, licensing, and migration terms, confirm acceptance gates, and document mutual obligations based on evaluation outcomes.
Agreement Modules
- Subscription Agreement / Order Form
- Master Services Agreement (MSA)
- Statement of Work (SOW) — Migration & Rollout
- Service Level Agreement (SLA)
- Acceptance Criteria and Test Plan
- Change Order Agreement
- Regulatory & Data Compliance Addendum (conditional)
-
Deployment
Lock readiness facts and configuration values before execution begins.
-
Pre-Deployment Readiness
Confirm environments, access, compute provisioning, and named owners required to begin flow migration and full-chip validation.
Pre-Deployment Questions
Environment and site access
- Which environments will be in-scope for deployment and validation? (select all that apply)
- Are access roles/accounts for those environments already provisioned for the buyer's deployment and CAD engineers? (so we can schedule hands-on work and credentials requests)
- Who is the buyer's named environment access owner (name and role) who approves account creation and environment access? (so we know who to request access from)
Compute and licensing readiness
- Which compute platforms will be used to run benchmark and full-chip flows? (select all that apply)
- Is the compute quota required for initial benchmarking and validation provisioned and reserved for the deployment team? (so we avoid delays when scheduling large runs)
- Are the required tool licenses allocated and reachable by the buyer's deployment accounts / license server? (so runs won't be blocked by license errors)
Data, scripts, and integration endpoints
- Is there a single source-of-truth repository or run‑map for flow scripts and migration artifacts that the deployment will use? (so we avoid divergent flows during migration)
- Who is the repository or script owner on the buyer side (name and role)? (we will request read/write access from this person)
- Have the buyer's network/security teams whitelisted the integration endpoints or agent IP ranges required for remote provisioning and artifact transfer? (so we can validate connectivity ahead of the cutover)
People, schedule, and rollback
- Who is the buyer's named deployment lead (name, role, email) responsible for day-to-day coordination and approvals? (one POC keeps decisions efficient)
- Are there blackout windows, tapeout freeze dates, or compliance gates that restrict when full‑chip validation or large runs can occur? (so we schedule runs without violating constraints)
- If you selected a restricted option above, list the blackout dates or recurring maintenance windows and name the owner who approves exceptions. (provide dates/schedule and approver so we can request windows)
-
Configuration Details
Capture exact configuration values, integration endpoints, script locations, and toolchain parameters the deployment team will use.
Configuration Details
ENVIRONMENTS & ENDPOINTS
- Enter the production instance base URL (format: https://... — Default: https://prod.your-domain.example). This exact value will be written into deployment configuration.
- Enter the pre-production (staging) instance base URL (format: https://... — Default: https://staging.your-domain.example). This exact value will be written into deployment configuration.
COMPUTE & BENCHMARK TARGETS
- Enter the compute cluster endpoint used for synthesis and benchmark runs (format: host[:port] or https://... — provide the reachable hostname or URL the orchestration will call).
- Enter the numeric target PPA improvement to validate during evaluation (percentage, whole number). Default: 15 (means 15%). This single numeric value is used by the orchestration as the pass/fail threshold.
FEATURES & OBJECTIVES (enable exactly what this deployment should run)
- Which feature modules should be enabled for this deployment? (select all that apply)
- Select the synthesis engine variant to use for all benchmark runs (choose one). Default: Balanced QoR.
SCRIPTS, REPO & TOOL VERSIONS
- Enter the Git repository URL that contains automation and orchestration scripts (format: https://... — branch and path below will be read from this repo). Do not include credentials.
- Enter the orchestration script path relative to the repo (example: ./ci/run_benchmark.sh — Default: ./ci/run_benchmark.sh). This exact relative path will be executed by the deployment orchestration.
CREDENTIAL HANDOFF & INTEGRATIONS
- Select the credential handoff method for secrets required by integrations (Default: Buyer secrets manager — the deployment form will not accept secrets). Choose the channel the buyer will use to deliver secrets at kickoff.
-
Deployment
Execute flow migration, integration, training, and initial full-chip synthesis runs with clear owners, timelines, and escalation paths.
-
-
Success
Validate QoR and turnaround improvements against agreed criteria, capture learnings, and maintain a shared track for issues and enhancement requests.
Success Reviews
- Go-live Health Check
- First Measurement Review (weeks 4-10)
- Acceptance Gate Review (around day 90)
- Quarterly Success Review — Operational
- Lessons Learned and Continuous Improvement (6-12 months)
Issues & Enhancements
- Update the enhancement request tracker with priority, acceptance criteria, and target delivery quarter for each top request.
- Record the formal acceptance decision and signatory in the shared workspace with links to the measurement artifacts.
- Execute the incumbent wind-down or retention plan and certify that data archives or read-only access are completed.
- Publish remediation plans for any failed criteria with specific re-test conditions and target completion dates.
- Sustained QoR and turnaround metrics
- Verify whether the percentage of benchmark blocks meeting timing targets and average synthesis turnaround time are on track versus Solution Scope targets.
- Reduce the open-defect backlog by agreeing target resolution dates for the highest-severity items.
- Prioritize enhancement requests and commit target delivery quarters for the top requests.
- Reconfirm acceptance criteria and owners
- Close or re-scope outstanding defects with new target resolution dates published in the shared issue tracker.
- Produce a short training refresh plan to address any adoption gaps identified in this review.
- Validate long-term QoR and turnaround
- Confirm that long-term QoR and synthesis turnaround improvements meet or are trending toward the Solution Scope targets.
- Reduce mean time to resolve issues through agreed systemic fixes and process updates.
- Ensure a high percentage of enhancement requests are assigned owners and delivery dates to improve throughput.
- Publish a lessons-learned summary and update operational runbooks and onboarding materials to reflect agreed process changes.
- Create a prioritized improvement roadmap for flow hardening and toolchain adjustments with target quarters for delivery.
- Begin monthly reporting on MTTR and enhancement assignment rate to track improvement against targets.
- Deployment artifacts and environment checks are confirmed complete and accessible.
- Top 3 operational blockers are documented with mitigation steps and target resolution dates.
- Owners for each acceptance criterion recorded in Solution Scope are confirmed.
- Produce and publish a deployment health snapshot listing environment checks, access issues, and remediation steps with target dates.
- Log the top operational blockers in the shared issue tracker with provisional severity and expected resolution dates.
- Schedule any required follow-up troubleshooting sessions to resolve high-severity go-live issues within the next 7 days.
- Update the shared schedule to reflect the date for the acceptance gate review and required pre-meeting deliverables.
- Present first data against targets
- Determine whether PPA improvement on benchmark blocks and synthesis runtime per run are trending toward the Solution Scope targets.
- Identify root causes for any metric gaps and commit to a set of corrective experiments with timelines.
- Confirm the measurement schedule and deliverables required to reach the acceptance gate.
- Deliver a per-block PPA and runtime comparison report versus the incumbent with configuration and run logs for failing cases.
- Publish a short experiment plan listing specific flow parameter changes to be tested and expected measurement dates.
- Restate acceptance criteria and numeric targets
- Produce a documented pass or fail for each acceptance criterion recorded in Solution Scope with a named buying signatory where required.
- Confirm the incumbent wind-down plan or formal retention state and validate data archive or migration completion.
- Agree remediation and re-test plan for any failed acceptance criteria with target dates.
- Issue burn-down and open defects
- Incident and MTTR trends
- Present outcome data against each criterion
- Diagnose gaps and root causes
- Deployment and migration validation
- Agree corrective actions and test iterations
- Enhancement requests backlog and prioritization
- Enhancement request throughput
- Early adoption signals and usage patterns
- Document pass or fail per criterion and capture signatory
- Training refresh and adoption support
- Capture lessons learned and update runbooks
- Confirm timeline to acceptance gate
- Incumbent tool wind-down confirmation
- Blockers and open issues triage
- Agree immediate remediation actions
- Agree remediation items and resolution timeline