Silicon Test Engineering
Long-cycle design programs where IP, foundry, and ecosystem partnerships execute against tapeout and market windows.
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 and prove technical fit before scoping and contracting.
-
Outcome Discovery
Align on device priorities, production timeline, stakeholders, and success signals (fault coverage, test time, and correlation targets).
Discovery Questions
Quick Context, Your Current Program Snapshot
- Tell me about your current first-silicon timeline and the date you must be in production.
- On arrival of your first silicon, which of these is missing today?
- Who is the primary decision owner on your side for test program acceptance and sign off?
- Estimate your target production start window in weeks from first silicon.
- What is your target maximum test time per device in milliseconds for production cost planning?
- Which teams on your side will need direct access to characterization benches and ATE during a pilot?
Where Your Timeline Actually Breaks
- Which single schedule failure on your path to production would make you stop the project immediately?
- List the last three timeline delays your team experienced during prior test bring ups, and the downstream cost to your program.
- Who on your team escalates when probe card or interface performance misses targets, and what authority do they have to change scope or budget?
- If a respin is required for your interface, what is the budgeted tolerance in dollars and weeks your program can absorb?
- Describe the single biggest unknown about your device electrical behavior that worries your engineering leadership most.
Device Priorities That Drive Your Decisions
- Tell me about the top three device specifications for your product that will determine whether tests are acceptable.
- Rank those specs by business impact for your program, with 1 being the worst outcome if missed.
- When cost and quality conflict for your product, which measurement does your team prioritize, fault coverage, test time, or bench-to-ATE correlation?
- Identify the owner roles on your team for fault coverage and for test time targets.
- What tradeoffs would your team accept between increased test time and higher fault coverage in the first production runs?
Pilot That Proves This Works for Your Product
- Walk me through the minimum pilot setup your team would need to see to be convinced the test solution is viable.
- List the specific silicon samples and device variants your team needs included in a representative pilot.
- If your pilot hit coverage and correlation targets, what internal approvals would remain before your team could commit to purchase?
- Estimate the acceptance thresholds your team will use for bench to ATE correlation, expressed as a percent or magnitude.
- Describe the ATE platforms and socketing constraints your team must have accommodated during the pilot, including whether portability across families is required.
What Other Paths Your Team Is Considering
- Name the options your team is actively weighing right now, including internal build, incumbent vendors, and external providers.
- For each option your team is considering, what would have to be true about its performance or cost for you to stay with it instead of changing?
- Has anyone on your team proposed solving this internally to avoid an outside partner, and if so, what timeline and headcount did they estimate?
- Explain the factors that make your incumbent acceptable today, for example existing IP ownership, familiarity, or lower perceived integration risk.
- Identify the specific condition under which your team would definitively keep the current approach rather than switch.
Readiness, Can Your Team Actually Execute?
- Point to the single missing practical requirement on your side that would block execution before ATE qualification.
- Detail the integration dependencies your team already has, such as DUT adapters, test data APIs, and lab access agreements.
- Name the role on your team that will provide cleared lab access and commit to sample handoffs.
- Assess whether your team has the available bench engineers and ATE operators needed for the pilot, and if not, where the gaps are.
- Are there regulatory, export, or NDA steps your team must complete before hardware can cross site boundaries?
Who's Watching and Who Can Move the Needle
- Name the executive on your side who will decide whether this project continues after the pilot, and their primary success metric.
- Provide the engineering stakeholder roles on your team who must be hands on during characterization, and note those who will only be informed.
- When a yield issue appears in your production line, who becomes the incident owner and what SLA triggers are expected?
- Provide the approval path on your side for emergency resource increases, including roles and typical response time.
- Explain the procurement or legal gating steps on your side that usually add two or more weeks to timelines.
Exact Acceptance Criteria Your Team Will Use
- Assuming the pilot meets your acceptance numbers, what would still prevent your team from signing within one week?
- Specify the fault coverage percentage and maximum test time per device your team will accept for production release.
- State your acceptable bench to ATE correlation threshold, and how your team measures that threshold.
- Rank the acceptance gates for your program in order of importance, for example delivery, integration, performance, and economics.
- Give the magnitude of cost per unit impact for your product if test time increases by 20 percent across your target site count.
If It Works, When Can Your Team Move Fast?
- Assuming all acceptance gates are met, can your team commit to contract signature, and on what timeline?
- Detail the internal milestones on your side that must align before you can book production ATE time, and who owns each milestone.
- Outline the minimal legal and procurement packet your team will need to see to accelerate signing.
- State the earliest date your team can provide first production-grade samples for qualification.
- Are there budget approval windows or fiscal constraints your team must respect that will affect when you can sign?
-
Pilot Evaluation
Run a hands-on pilot on representative silicon to validate fault coverage, test time, and bench-to-ATE correlation against agreed acceptance criteria.
- success_criteria
- current_state
- stakeholders
- gaps
- desired_state
- decision_readiness
- current_state
- decision_readiness
- success_criteria
- desired_state
- gaps
- stakeholders
- current_state
- success_criteria
- stakeholders
- desired_state
- gaps
- decision_readiness
- decision_readiness
- decision_readiness
- decision_readiness
- decision_readiness
-
-
Solution Scope
Define deliverables, responsibilities, hardware and software boundaries, ATE portability requirements, acceptance criteria, and timelines.
Scope Configuration
- Develop and Deliver ATE Test Program
- Design and Fabricate Probe Card
- Provide Probe Card SI Simulation Package
- Probe Card Electrical Characterization and Tuning
- Design and Fabricate Load Board
- Load Board Functional Verification
- On-site ATE Bring-up and Debug
- Bench Characterization Test Suite
- Correlation Analysis and Production Limit Sets
- Optimize Multi-site Parallel Test Efficiency
- Failure Analysis and Yield Debug Support
- ATE Pin Map and Handler Interface Delivery
Scope Questions
Develop and Deliver ATE Test Program
- Specify target ATE platforms and firmware versions the delivered test program must run on (platform family, OS/firmware release).
- List the DUT variants and pin-map families the program must support (part numbers, pin-map revisions).
- Identify maximum acceptable per-device test time and per-site throughput targets (ms/test, desired sites in parallel).
- Define quantitative acceptance criteria for the delivered ATE test program (target fault coverage %, maximum test time per device, and allowable pass/fail correlation delta).
- Who will be the primary technical owner for ATE program acceptance and ongoing maintenance?
Design and Fabricate Probe Card
- Specify wafer probe targets the probe card must support (die dimensions, bond pad pitch, pad count per die).
- List required probe tip technologies and preferred styles (cantilever, MEMS, pogo tip families).
- Are there prober interface or handler mechanical constraints we must design the probe card to fit (socket dimensions, probe holder interface)?
- Estimate target probe card lifecycle (number of touchdowns or wafers before replacement) and acceptable repair cycles.
- Provide any non-standard cleanroom, ESD, or shipping requirements for probe card fabrication and delivery.
Provide Probe Card SI Simulation Package
- Which SI deliverables do you require in the probe card simulation package (S-parameters, TDR models, extracted netlist, full channel model)?
- Attach or reference existing DUT package or board S-parameter files and stack-up documents we must include in the simulation.
- State the frequency range and rise/fall timing the SI simulation must cover for your high-speed interfaces.
- Indicate required margin targets for return loss, crosstalk, and insertion loss (dB thresholds) to guide design tolerances.
- Confirm whether the simulation deliverable must include compatible file exports for your SI tools (Touchstone, S2P, CSV).
Probe Card Electrical Characterization and Tuning
- When will the first probe card arrive for bench tuning relative to your ATE handoff timeline (days/weeks)?
- Describe the electrical bench tests you require for initial probe card tuning (contact resistance distribution, continuity, leakage, S-parameter verification).
- Define the test evidence that will confirm probe card electrical performance for handoff (measured contact resistance CDF, swept S-parameter files, continuity matrix).
- Name the sign-off owner and the documentation they require for probe card tuning acceptance (tuning report, raw logs, pass/fail checklist).
- Are there environmental or thermal conditions during tuning we must replicate (chuck temperature, humidity)?
Design and Fabricate Load Board
- Detail package types, socket types, and pin-mapping variants the load board must support (BGA pitch, QFN outlines, test socket family).
- Provide power domain voltages and maximum currents the load board must deliver for each domain.
- Clarify mechanical constraints and handler footprint requirements for the load board (mounting holes, standoff height, thermal clamp locations).
- Who will supply the golden device pin-map and any reference schematics needed for load board design?
- Confirm availability of test sockets or indicate if a custom socket must be designed and fabricated.
Load Board Functional Verification
- Outline the functional verification steps you require on the completed load board (power-up sequence, clamp verification, timing checks with ATE handshake).
- Select mandatory functional tests from this list: power sequencing, JTAG continuity, scan chain validation, IDDQ, high-current stress.
- Give the expected lab where load board verification will be executed (your bench, our lab, third-party) and any access restrictions.
- Do you require witnessed verification with formal sign-off at completion?
- Document pass/fail criteria for each functional verification test (acceptable thresholds, allowable pin failures).
On-site ATE Bring-up and Debug
- When will ATE access be available on-site for bring-up and debug (date or weeks from now)?
- Identify the on-site personnel roles you will make available during ATE bring-up (ATE operator, handler technician, production engineer).
- Confirm whether remote VPN access to the ATE is permitted during bring-up for off-site engineers.
- Enter preferred ATE operator shift patterns and shift overlap for debugging sessions.
- Detail the expected escalation path and contact information for critical ATE failures during on-site debug.
Bench Characterization Test Suite
- Name the bench instruments and models you require support for in the characterization suite (SMU, oscilloscope, TDR, logic analyzer).
- Describe the bench test sequences to be included (parametric IV sweeps, timing margin sweeps, functional vectors) and their order.
- Confirm availability of golden wafers or known-good samples for bench correlation.
- Choose preferred telemetry and logging formats for bench runs (CSV, waveform files, binary instrument logs) and any naming conventions.
- Estimate number of sample devices you can provide for bench characterization and expected lot-to-lot variability.
Correlation Analysis and Production Limit Sets
- State numerical correlation thresholds between bench characterization and ATE results that will define acceptance for production limit sets (param delta, pass-rate shift).
- Document the metrics and plots you require in the correlation report (bin mapping tables, param delta matrices, ROC curves, FMEA linkage).
- Assign an owner for production limit set updates after correlation analysis and indicate the expected SLA for changes.
- Give target sample sizes and confidence levels you require for establishing limits (e.g., 95% at N devices per lot).
- Mention downstream manufacturing gates that will consume these limit sets (final test, assembly test, burn-in) and their acceptance windows.
Optimize Multi-site Parallel Test Efficiency
- Share your target sites-per-card and desired site-utilization percentage for production throughput planning.
- Select acceptable multi-site parallelization strategies you permit (site interleaving, program multi-threading, bank multiplexing).
- Assign responsibility for multi-site mapping and ATE resource arbitration during test runs.
- How many parallel test threads can your handler and production flow support without degrading mechanical life?
- Outline acceptable trade-offs between reduced coverage and shorter test time for higher site counts (give examples or thresholds).
Failure Analysis and Yield Debug Support
- Enumerate the failure analysis techniques you expect included in scope (optical inspection, SEM, FIB, cross-section, edge-bonding).
- Clarify whether you require root-cause reports that map test escapes to specific defect modes and include recommended corrective actions.
- Enter expected turnaround times for failure analysis cycles from part receipt to final report (hours/days/weeks).
- Indicate who will coordinate failure analysis sampling and shipping logistics and any preferred carriers or internal procedures.
- Are you expecting ongoing FA support during initial production runs (weeks/months)?
ATE Pin Map and Handler Interface Delivery
- Which pin map format and handler interface description do you require (ATE pin-map CSV, handler mapping table, connector drawings)?
- Attach any existing ATE pin maps, handler scripts, or connector drawings we must align to during delivery.
- Confirm whether the delivered pin-map must include alternate multi-site mappings and documented site limits.
- Enter copyright and ownership expectations for delivered handler interfaces and pin-map artifacts.
- Describe the acceptance evidence required for handler interface handoff (sample handler run results, pin continuity logs, documented pin-map).
-
Mutual Commit
Finalize commercial and contractual terms, resource commitments, fabrication milestones, ATE booking responsibilities, and acceptance gates.
Agreement Modules
- Master Services Agreement (MSA)
- Statement of Work (SOW)
- Commercial Proposal / Order Form
- Fabrication Milestones Schedule (Annex)
- ATE Reservation & Resource Commitment
- Acceptance Criteria & Test Acceptance Protocol
- Resource Allocation & Staffing Commitment
- Change Order Agreement
- Payment & Invoicing Terms
- Confidentiality & Data Handling Addendum (NDA)
-
Deployment
Operationalize rollout with readiness checks, execution, and outcome validation.
-
Kickoff & Technical Working Sessions
Align engineering teams on test vectors, signal-integrity assumptions, handoff details, and the pilot execution plan.
Working Meetings
- Kickoff and Roles Alignment
- Signal Integrity and Interface Assumptions Workshop
- Test Vector and Acceptance Criteria Decision
- Pilot Execution Plan and Handoff
- Complete the sample and hardware handoff checklist and arrange delivery to the lab.
- Deliverable test vector set with documented timing parameters is approved for implementation.
- Pass/fail limits and correlation checkpoints are defined and logged.
- Data format and reporting template for bench-to-ATE correlation are confirmed.
- Publish the approved test vector files and parameter sheet to the repository.
- Create the correlation data template and example report for automated comparison.
- Schedule initial bench execution and ATE correlation slot according to the agreed timeline.
- Review pilot milestones and go/no-go gates
- A time-phased pilot execution plan with named milestones and owners is published.
- ATE booking times and baseline configuration values are confirmed and recorded.
- Handoff checklist for samples and hardware delivery is finalized for execution.
- Publish the pilot execution plan and milestone tracker to the shared repository.
- Confirm and record ATE reservations and baseline configuration settings.
- Confirm pilot scope and acceptance criteria
- Pilot scope and acceptance criteria are ratified and documented for the pilot.
- Owners are named for each major workstream and a RACI matrix is agreed.
- Communication channel, escalation path, and artifact repository are confirmed.
- Publish a one-page pilot scope and acceptance criteria summary to the shared repository.
- Publish the stakeholder RACI matrix and contact list.
- Create the agreed shared folder and grant access to named participants.
- Review existing measurements and electrical constraints
- A single signal integrity model with numeric parasitic budgets is agreed and archived.
- Pin map and connector assignments are finalized for probe and load board designers.
- Simulation input list and versioning rules are confirmed so design work can proceed.
- Publish the agreed SI model file and parasitic budget document to the repository.
- Deliver the finalized pin map and connector mapping as the interface spec.
- Run the first set of agreed simulations and upload results to the shared folder by the agreed date.
- Confirm test objectives and coverage targets
- Define stakeholder roles and RACI
- Finalize vector set and timing parameters
- Confirm hardware deliverables and fabrication schedule
- Agree signal path model and parasitic budget
- Lock ATE configuration, multi-site mapping, and time reservations
- Define pin assignment and connector mapping
- Agree communication and escalation paths
- Set pass/fail limits and correlation checkpoints
- Specify simulation inputs and version control
- Define data and reporting format for correlation
- Finalize sample handoff and lab access checklist
- Data access, security, and artifact repository
- Confirm immediate next steps and meeting cadence
-
Pre-Deployment Readiness
Capture concrete readiness facts — lab access, sample handoff, ATE reservations, owners, and timeline constraints required before execution.
Pre-Deployment Questions
Environment and site access
- Which physical site will host execution (select the closest and we'll request site name in the next field) — so we can confirm logistics and access?
- Named on‑site contact and earliest on‑site access date (owner and date) — so we can schedule staff and shipping
Samples and tooling
- What sample type and quantity will be handed off for pilot (select best match)? — this determines characterization scope and fixture needs
- Committed sample handoff date and sample owner (name and role) — so we can lock shipment and test windows
- Probe card / load board mechanical interface availability (who provides the mechanicals or interface hardware?) — affects lead time for fixtures
ATE and instrumentation reservations
- Is production ATE / characterization ATE time reserved for pilot and initial runs (slot owner and rough dates)?
- Which ATE category will be used for execution (select the closest) — we will confirm exact model in DeploymentConfig
People, ownership, timing & constraints
- Are named owners assigned for these workstreams? (select all that have an owner assigned now) — lets us route approvals and questions directly
- Named acceptance authority for pilot results (role and contact) and the target acceptance cutoff date — so we know who signs off and by when
- Are there any hard blackout windows, facility freezes, or fabrication milestones that block execution (select one) — list windows in DeploymentConfig if yes
-
Configuration & Scheduling
Lock exact configuration values and schedules the team will use — ATE settings, multi-site mapping, probe/load board parameters, and booked time slots.
Configuration Details
Platform, Test Program & Portability
- Your ATE platform family (select the platform family that will run production tests). Default: High-parallel multi-site ATE.
- Exact ATE platform variant identifier (single value, free text). Use format: family-variant (e.g., High-parallel-v2).
- Test program portability target (select one). Default: Dual ATE variants.
Multi-site Mapping, Hardware & Signal Integrity
- Number of parallel sites to configure per ATE instance (integer). Default: 32.
- Multi-site pin mapping file URL or repository path (single value). Format: https://... or file://... . If not applicable, enter 'N/A'.
- Probe card maximum probe force per probe in grams (integer). Default: 10 (grams).
- Signal-integrity model selection for interface simulation (select one). Default: Default SI model v1 (recommended).
- Customer signal-integrity model file URL or repository path (single value). Format: https://... or file://... . If using provided models, enter 'N/A'.
Scheduling, Bookings & Acceptance Criteria
- Confirmed ATE booked start datetime (single value, ISO 8601 format: YYYY-MM-DDTHH:MMZ). Enter the start of the reserved window.
- Confirmed ATE booked end datetime (single value, ISO 8601 format: YYYY-MM-DDTHH:MMZ). Enter the end of the reserved window.
- Production acceptance minimum fault coverage percentage (integer). Default: 98 (%).
- Production throughput target (devices per hour, integer). Default: 1000 devices/hour.
-
Execution & Characterization
Fabricate interfaces, run characterization and production test runs, iterate limits, and document yield correlation with named owners and milestones.
-
-
Success
Confirm acceptance against fault coverage and throughput targets, capture lessons learned, and maintain a shared channel for issues and enhancements.
Success Reviews
- Go-live Health Check (weeks 1-4)
- First Outcome Measurement (weeks 4-10)
- Acceptance Gate Review (around day 90)
- Quarterly Operational Review — Ongoing Realization
Issues & Enhancements
- Circulate the prioritized enhancement backlog with proposed timing for the next quarter.
- Export and share the bench-to-ATE correlation dataset and the test logs used for the measurement.
- Schedule verification runs on ATE and bench to validate corrective actions before the Acceptance Gate meeting.
- Restate acceptance criteria and numeric targets
- Produce a documented pass or fail for each numeric acceptance criterion recorded in Pilot Evaluation.
- Capture the named signatory's acceptance decision or conditional acceptance with remediation timelines.
- If applicable, define a bounded remediation plan and a final verification date for any failed criteria.
- Publish the acceptance decision record with the named signatory and recorded outcomes for each criterion.
- If acceptance is conditional, publish the remediation tracker with tasks, dates, and verification checkpoints.
- Schedule the final verification run for any conditional items and confirm data delivery expectations for sign-off.
- Trend review for key metrics
- Confirm fault coverage percentage and multi-site parallel efficiency remain at or above the thresholds recorded in Pilot Evaluation, or document deviation and remediation.
- Ensure open incidents affecting throughput or correlation are assigned resolution dates and tracked to closure.
- Agree the short-term enhancement backlog items and scheduling constraints for the next quarter.
- Publish a quarterly metric dashboard highlighting fault coverage percentage, multi-site parallel efficiency, and average test time per device.
- Open tickets for any agreed limit or site-mapping adjustments and record expected verification runs and dates.
- Re-confirm acceptance criteria and owners
- Confirm each acceptance criterion from Pilot Evaluation has an identified owner and an initial status.
- Establish an immediate remediation plan for any showstopper issues with timelines.
- Verify the baseline deployment configuration is correct and documented for follow-up measurement.
- Publish a short deployment validation checklist with owners and current status.
- Document and circulate first-run error logs and temporary mitigations for asynchronous review.
- Reserve next measurement checkpoint date and required data exports for the First Outcome Measurement meeting.
- Present measured outcomes
- Establish whether fault coverage percentage and average test time per device are trending toward the targets recorded in Pilot Evaluation.
- Identify root causes for any metric gaps and agree concrete corrective actions with completion dates.
- Confirm the data set and remediation status required for the Acceptance Gate meeting.
- Deliver a remediation plan listing technical tasks, expected effect on each metric, and dates for verification runs.
- Present outcome data against each criterion
- Persistent issues and incident burn-down
- Deployment and handoff validation
- Compare against Pilot Evaluation targets
- Document pass/fail per criterion
- Early execution signals
- Yield correlation and limit adjustments
- Root-cause diagnosis for gaps
- Enhancement backlog and short-term schedule
- Formal acceptance decision and signatory
- Blockers and open issues
- Agree corrective actions and timeline
- Confirm readiness for Acceptance Gate
- Remediation plan for failed criteria
- Meeting cadence and escalation checkpoints
- Immediate remediation actions