Technology
›
Semiconductor & Chip Design
›
Automotive Chip Design
Automotive System-on-Chip Design
Long-cycle design programs where IP, foundry, and ecosystem partnerships execute against tapeout and market windows.
Qualcomm
NXP Semiconductors
Renesas
Texas Instruments
Inside this journey
-
Pre-Discovery
Align the room on outcomes, decision process, and constraints before deeper discovery.
-
Stakeholder Alignment
Confirm decision roles, timelines, program constraints, and what ‘good’ looks like for each stakeholder.
Alignment Questions
Quick introductions — the program you're trying to win
- Briefly describe the vehicle program or platform you’re evaluating (vehicle segment, intended features, approximate launch year).
- What is the program’s target annual unit volume once in production?
- Who owns the final silicon selection and who are the primary technical stakeholders we should engage?
- What are the top three business goals this compute platform must deliver (e.g., consolidate domains, enable ADAS, reduce BOM, faster time to market)?
- What is the target program decision timeline for selecting an SoC and committing to long‑term supply?
- Do you already have prototype hardware or an integration lab available for vendor bring‑up?
What keeps your engineers awake at 2AM?
- If your current compute platform hit a performance cliff tomorrow, what would immediately break for your program (safety functions, UX, production milestone)?
- Which failure modes have you seen most often in recent integrations?
- How often do integration issues push schedules or require scope changes?
- When a failure occurs, how long does root‑cause identification and recovery typically take?
- Tell us about a recent integration incident that changed your plans — what happened and what did you learn?
- Which of these areas are currently the highest source of schedule risk for you?
Are you sure your architecture will scale for the next decade?
- How confident are you that the current compute architecture can absorb a 2–3x growth in workload over the next 5–10 years?
- Which consolidation strategy are you using or planning (centralized domain controller, zonal ECUs, mixed)?
- Estimate current compute headroom available for new features (CPU/GPU/NPU) as a percentage of sustained capacity.
- Which peripherals and vehicle networks must be integrated into the SoC (e.g., CAN FD, LIN, Ethernet AVB/TSN, FlexRay, ADAS sensors)?
- What external compute or co‑processors do you rely on today (e.g., MCUs for braking, external TPUs), and can they be consolidated?
- Are there architecture decisions you’ve deferred because of uncertainty in silicon direction? If so, what are they?
Where latency and safety collide — the functions you can’t afford to get wrong
- Which safety‑critical functions would silently fail to meet safety targets if latency or jitter increased by 2x?
- For each function (e.g., braking, steering assist, radar fusion), what is the hard latency budget you must meet (ms or µs)?
- What ASIL level(s) apply to your functions and which functions are ASIL‑D candidates?
- What real‑time OS or RTOS choices are you standardizing on (baremetal, AUTOSAR Classic, AUTOSAR Adaptive, QNX, FreeRTOS, Zephyr, Custom)?
- How do you currently validate latency and jitter in vehicle scenarios (test rigs, HIL, in‑vehicle logging)?
- Describe the consequences (technical, programmatic, safety) if a chosen SoC cannot meet those real‑time budgets.
Thermals, power, and the sealed box — what are you silently compromising on?
- If you could redesign the vehicle enclosure to remove thermal constraints, what features would you enable that you can’t today?
- What is the steady‑state power budget and peak power budget for the ECU(s) this SoC will inhabit?
- What’s the maximum ambient temperature and thermal strategy (passive conduction, active cooling, heat pipe, shared vehicle HVAC)?
- Have you observed thermal throttling or performance degradation in current builds? If so, describe frequency and impact.
- Which power management features are mandatory from a silicon vendor (DVFS, power islands, low power states, wake sources)?
- How much risk are you willing to accept in pushing SoC frequency/voltage for performance gains versus preserving margin for thermal headroom?
Software and ecosystem — the invisible path to success (or delay)
- If you had to bet on one single thing that would derail integration most often, would it be BSP gaps, middleware incompatibility, or toolchain instability?
- Which software stacks must be delivered or supported by the SoC vendor (select all that apply)?
- How mature is your team’s integration experience with vendor BSPs and drivers on similar silicon?
- What are the top three software deliverables that would accelerate your schedule (e.g., validated BSP, reference system, certified AUTOSAR modules)?
- Describe your CI/CD and validation pipeline for platform software — do you have automated tests, HIL, or manual verification?
- How do you prefer to handle software ownership and responsibilities (vendor provides full BSP and maintenance, vendor provides reference and customer owns integration, co‑development)?
Supply, commitments, and the contract that keeps programs alive
- How would your launch change if a silicon supplier constrained supply by 30% in year two?
- What long‑term supply guarantees do you require (e.g., 7+ years, 10+ years, continuity with change notifications)?
- Do you plan single‑sourcing for the SoC or require dual/multi‑source strategies?
- What qualification milestones and timelines are non‑negotiable (e.g., AEC‑Q100 lot dates, ISO 26262 audits, PPAP)?
- Which contractual terms are most important to procurement (price stability, volume flexibility, change notification windows, indemnity)?
- What engineering sample cadence and lead times do you require to keep your schedule on track?
What does ‘good’ actually look like to each stakeholder?
- If leadership approved this platform today, what are the three non‑negotiable acceptance criteria they would insist on?
- Which KPIs will you use to judge the success of the SoC selection (select up to five)?
- Who must sign off on the final acceptance (roles and level of authority)?
- What level of post‑production support is expected from the silicon vendor (on‑site engineering, SLA response times, firmware updates)?
- How important is an established security and HSM roadmap to your acceptance criteria?
Turning insight into action — what would meaningful next steps look like?
- What would you need to see or hear within the next 30 days to feel confident this vendor can meet your needs?
- Which outputs from us would move you forward fastest (select up to three)?
- What is your preferred cadence for collaboration during qualification (weekly tech calls, biweekly milestones, monthly executive reviews)?
- What access will your team provide to make integration efficient (lab access, data logs, test rigs, safety artifacts)?
- Who are the immediate owners on your side for the next milestones and what are their contact roles?
-
Current Program Mapping
Document the vehicle architecture, existing compute domains, qualification gates, and current failure modes.
Program Mapping
Open the Hood: A Quick Program Snapshot
- In one sentence, how would you describe this vehicle program and your role in it?
- What is the program stage today?
- Which vehicle segment and project timelines apply to this program?
- Which hard constraints are non‑negotiable for your SoC selection (pick all that apply)?
- Who are the internal and OEM decision stakeholders for SoC and platform choices?
If Your Architecture Failed Tomorrow, Would You See It Coming?
- Walk us through the current vehicle compute architecture and how you’ve partitioned domains today.
- Which compute domains are currently distinct vs intended for consolidation?
- Which vehicle networks and high‑speed interfaces are in your architecture today?
- Where are the current single points of failure or brittle hand‑offs in that architecture?
- Do you have planned hardware redundancy or failover strategies?
Where It Hurts: The Moments That Stop Progress
- Which recurring integration or validation failures consume the most calendar time and budget?
- Tell us about a specific recent failure that derailed a milestone—what happened, who discovered it, and what was the root cause?
- At which phase do these failures most often surface?
- How do these repeated issues affect stakeholder confidence, schedule pressure, and team morale?
- Which issues do you quietly accept as 'just how it is' today?
Are Your Gates Helping or Hiding Problems?
- Do your qualification gates expose the right problems early, or do they push risk downstream until it's costly?
- Which formal gates or milestones do you enforce on this program?
- At which gate do you see the highest failure rate and what typically triggers those failures?
- Who is the formal sign‑off owner for each gate (name/role)?
- How long does remediation typically take after a failed gate?
Who’s Quietly Running the Program — and Who’s Really Accountable?
- Are the people making technical tradeoffs empowered by timely data, or are they frequently forced to choose on instinct?
- Which teams own SoC selection, integration, software stacks, and validation in your org?
- Describe a past misalignment between teams that caused delays—what was the mismatch and how was it resolved (or not)?
- How often do you run cross‑functional architecture or safety reviews?
- Which KPIs or artifacts give your leaders confidence (pick all that apply)?
If You Had Perfect Silicon, What’s the First Thing You Would Change?
- Would more CPU/GPU/NPU, lower jitter/latency, or richer I/O actually unblock your schedule—or is the software and test infrastructure the gating factor?
- Which SoC capability would most change program outcomes in the next 12 months?
- What gaps in your software stack (BSP, AUTOSAR, hypervisor, drivers) would prevent you from exploiting a new SoC immediately?
- How important is a production‑grade BSP and AUTOSAR support at first bring‑up?
- What timeline from prototype silicon to production‑qualified SoC would keep your program on schedule?
- What risks—technical, organizational, or commercial—would stop you from switching to a new SoC family even if specs match?
Let's Make a Deal with Reality: One Small Win to Change the Trajectory
- If we guaranteed one measurable outcome in the next 90 days, which would change your program's trajectory most?
- What artifacts, lab access, test equipment, and personnel would we need from you to hit that milestone?
- Who will be our primary technical POC(s) and who are the formal decision approvers?
- If we discover a critical failure during early validation, what escalation path and timeline do you expect?
- How do you prefer progress and issue updates during early phases?
-
-
Customer Discovery
Capture performance, real-time latency, peripheral integration, power/thermal, software maturity, and supply requirements.
Discovery Questions
Opening: Tell Me About The Program You’re Building
- Which vehicle program or platform is this SoC evaluation tied to?
- What is your target production start date or program milestone we should align to?
- Who are the core decision-makers and approvers for this platform (roles/titles)?
- At a high level, what are the top three outcomes this compute platform must deliver for your program?
- How confident are you today that your current architecture choices will meet the program timeline and reliability needs?
- If you could wave a magic wand and fix one immediate blocker on this program, what would it be?
Are You Quietly Accepting Performance Shortfalls?
- Where do you notice compute headroom running out when multiple domains consolidate on one platform?
- Describe a recent incident where processing limits forced a design compromise or late rework.
- Which workloads push your CPUs/NPUs/GPU the hardest today (quantify if possible)?
- What peak performance metrics do you require (e.g., TOPS, DMIPS, GPU FLOPS) and under what operating conditions?
- How much headroom (percentage of peak) do you want reserved for future updates or feature growth?
- What would it feel like to have predictable, validated compute headroom for the next 5–10 years of your program?
What Latency Problems Are We Mistaking For Architecture Limits?
- Where have you observed real-time latency or jitter causing degraded safety or user experience?
- How do you currently measure worst-case latency across the stack—from interrupt to actuation?
- Tell us about a jitter or deadline miss you’ve debugged recently—what root cause surprised you?
- What end-to-end latency targets are non-negotiable for ASIL- or safety-critical functions?
- Which layers do you expect the SoC vendor to own for latency guarantees (hardware, RTOS, hypervisor, drivers)?
- How would resolving these latency gaps change validation time, risk, or your program schedule?
Which Peripheral Gaps Force Workarounds And Cost Time?
- Are you settling for external bridges or discrete controllers because the SoC lacks required vehicle interfaces?
- Which vehicle interfaces must be native on the SoC (select all that apply)?
- Describe a time when a missing peripheral forced additional ECUs, and what that cost in weight/complexity/schedule.
- How important is in-hardware security isolation for peripheral access (HSM-backed CAN, secure boot for comms)?
- Would you prefer more on-die integration even if it increases SoC cost, or keep functions off-chip to reduce unit price?
- What peripheral feature or interface, if delivered out-of-the-box, would remove the biggest integration risk for your team?
When Power and Heat Start Slicing Features Away
- Which thermal or enclosure constraints force you to derate performance today?
- Have you had to remove or limit features because power/thermal margins were insufficient?
- What are your peak and sustained power budgets for this compute node (W)?
- How do you currently validate thermal behavior—simulation, laboratory soak tests, or in-vehicle long runs?
- Would you value vendor-provided power/thermal models and validated DVFS/thermal policies?
- If you could pick one power/thermal win from a new SoC, what would it be (e.g., sustained high perf at 60°C, lower idle power)?
How Ready Is Your Software Stack—And Your Team—to Ship?
- Are you assuming the provided BSPs, AUTOSAR MCAL, and hypervisor support will be production-ready on day one?
- Which software components are highest risk for your schedule (choose up to 4)?
- Describe a past integration problem that cost weeks of debugging—what was the root cause and how was it resolved?
- Do you have CI/CD and automated validation harnesses that can consume vendor-provided images and autotests?
- What level of software deliverables do you expect from the vendor as part of qualification (source, binary, test suites, documentation)?
- How stretched is your firmware/embedded team—can they absorb additional integration work without delaying milestones?
Can You Rely On Supply When The Program Scales?
- If demand spikes or a part lifecycle change occurs, how would that affect your program delivery and cost?
- What supply guarantees do you require from a silicon partner (select all that apply)?
- Have you experienced lead-time or allocation issues with previous SoC vendors? If so, how did you mitigate them?
- What is your acceptable vendor lead time for production parts once NPI is complete?
- Would multi-sourcing (different nodes/variants) be acceptable to your program for supply resilience?
- What contractual or operational assurances matter most—price stability, capacity allocation, priority yields, or something else?
What Would Success Look Like—and Who’s Going To Sign Off?
- If this SoC enabled your ideal outcome, what three measurable program milestones would show we've succeeded?
- Who must be convinced internally (roles or committees) before you can commit to a design win on a new SoC?
- What acceptance criteria (performance, latency, thermal, safety) will you use during qualification?
- What unresolved risks would prevent you from selecting a new silicon today?
- Are you open to a phased engagement (early evaluation silicon → pilot → production) with defined gates?
- What would make you feel comfortable signing an NDA and sharing deeper integration materials with our engineering team?
-
Solution Experience
Walk through how the SoC family achieves the customer’s outcomes across representative vehicle scenarios and qualification tests.
Experience Meetings
- Pre-Experience Alignment
- Representative Vehicle Scenario Walkthrough — Performance & Latency
- Qualification & Test Mapping Workshop
- Integration Risk & Mitigation Workshop — Power, Thermal, Peripherals & SW
- Validation & Decision Checkpoint — Executive Alignment
- Confirm software deliverables (BSP, drivers) and target release milestones required for integration testing.
- Review Customer Qualification Gates
- Produce a mutually agreed test matrix mapping SoC variants to the customer's qualification gates.
- Agree measurable acceptance criteria and required evidence for each gate.
- Assign clear owners for test execution, results collection, and defect remediation.
- Establish a preliminary qualification timeline with dependencies and contingency windows.
- Seller to deliver the draft test matrix (variant → tests → acceptance criteria → evidence) within 4 business days.
- Customer to confirm available test facilities, shadow-test agreements, and point-of-contact for each gate.
- Both parties to capture the change control and AN(Automotive Notification) process for any post-signoff modifications.
- Top-Line Risk Register Review
- Identify the top integration risks and agree targeted mitigations that map to acceptance criteria.
- Assign clear owners and deadlines for each mitigation item to eliminate ambiguity during qualification.
- Welcome & Objectives
- Seller to provide BSP/driver roadmap and integration checklist with expected delivery milestones.
- Customer to share enclosure CAD, thermal constraints, and connector/PCB integration notes for detailed power/thermal analysis.
- Both parties to populate and accept the mitigation plan with owners and dates in the shared project tracker.
- Executive Summary of Findings vs Future State
- Secure executive alignment on whether the SoC family meets the customer's defined future state or what remains to be done.
- Obtain an explicit decision to move to Solution Scope and Mutual Commit or to require targeted remediation with timelines.
- Agree the immediate next milestones, owners, and timeline for qualification and commercial discussions.
- If 'Proceed', seller to produce the Solution Experience Executive Summary and proposed Solution Scope package within 3 business days.
- If 'Require remediation', owner(s) to deliver a remediation plan with clear success criteria and dates prior to next executive checkpoint.
- Both parties to confirm program owner contacts and schedule the formal Solution Scope kickoff meeting.
- Obtain customer sign-off on a one-sentence current state.
- Agree the quantified consequences of the current state in measurable terms.
- Define a one-sentence, outcome-focused future state to validate against.
- Capture required artifacts and assign owners so scenario walkthroughs can be evidence-based.
- Customer to confirm or edit the current state sentence and approve it in writing.
- Customer to provide representative scenario definitions, test vectors, worst-case power/thermal profiles, and acceptance thresholds within 5 business days.
- Seller to prepare scenario scripts and baseline telemetry tailored to customer inputs.
- Reiterate Current State, Consequence, Future State
- Demonstrate measurable evidence that the SoC meets the customer's outcome metrics across prioritized scenarios.
- Identify any scenario-specific gaps and classify them as integration, HW variant, software maturity, or qualification concerns.
- Obtain explicit customer validation (accept / needs remediation) for each scenario.
- Agree next steps and owners for any non-conforming scenarios.
- Seller to deliver a scenario performance pack (telemetry, logs, pass/fail evidence) within 3 business days.
- Customer to mark each scenario as Accept / Accept-with-conditions / Needs Work and provide prioritized list of items requiring remediation.
- If 'Needs Work', schedule follow-up technical deep-dive(s) targeted at the gap owners within 7 business days.
- Scenario 1 — Cockpit Consolidation (multi-domain)
- Current State Statement (forced)
- Thermal & Power Mitigations
- Residual Risks and Mitigation Status
- Map SoC Variants to Tests
- Commercial & Program Implications
- Peripheral & Network Integration
- Define Acceptance Criteria & Evidence
- Consequence Quantification
- Scenario 2 — ADAS/Real-Time Safety Path
- Assign Responsibilities & Test Environments
- Future State Definition (forced)
- Decision & Next Steps
- Scenario 3 — Zone/Body Controller (power & thermal extremes)
- Software Maturity & BSP Roadmap
- Traceability & Change Control Process
- Commitments & Close
- Live Failure-Mode & Recovery Demonstration
- Mitigation Plan & Owners
- Preconditions & Data Checklist
- Confirm Agenda & Next Steps
- Validation Checkpoints (forced confirmations)
-
Solution Scope
Define selected SoC variants, software stacks, integration responsibilities, qualification milestones, and acceptance criteria.
Scope Configuration
- Ship Automotive-Qualified SoC Evaluation Samples
- Deliver Reference Carrier Board Schematics and PCB Layout
- Provide Linux Board Support Package (kernel and DT)
- Deliver AUTOSAR MCAL and Basic Software (BSW) Drivers
- Provide Hypervisor BSP and Reference Virtualized Images
- Supply Real-Time Controller Firmware and RTOS BSP
- Deliver GPU/NPU SDK with Optimized Inference Libraries
- Provide CAN-FD, Ethernet-TSN, and LIN Driver Packages
- Deliver Hardware Security Module SDK and Key Provisioning Tools
- Provide ISO 26262 Functional Safety Artifacts and Safety Manual
- Provide Thermal Management Curves and Cooling Guidelines
- Deliver Production Maskset and Long-Term Wafer Supply
Scope Questions
Ship Automotive-Qualified SoC Evaluation Samples
- Which SoC variants do you want delivered as evaluation samples (part numbers or performance tiers)?
- How many samples of each variant are required for initial integration and validation?
- What delivery timeline do you need for samples (relative to project milestones)?
- Do you require special packaging, screening, or traceability (e.g., lot trace, serial numbers, AEC-Q100 screening)?
- Will samples be used for safety-critical qualification tests that require unique test fixtures or ID labeling?
- Are there NDA, export control, or customs requirements we should account for when shipping samples?
Deliver Reference Carrier Board Schematics and PCB Layout
- Which carrier board configurations are needed (e.g., base evaluation, camera-cockpit, network gateway)?
- What form-factor or mechanical constraints must the carrier board meet (dimensions, connector locations, enclosure constraints)?
- Which high-speed interfaces must be exposed on the reference board (e.g., PCIe, MIPI-CSI, Ethernet PHYs, SATA)?
- Do you require full PCB fabrication files (Gerber, ODB++) and placement drawings or only schematic + reference mechanical drawings?
- Will you require layout license/transfer terms or restrictions on derivative designs?
- Do you want BOM (manufacturer + part numbers) and preferred alternate parts included for production planning?
Provide Linux Board Support Package (kernel and DT)
- Which Linux kernel baseline do you require for the BSP (e.g., longterm kernel version or vendor-maintained branch)?
- Do you require PREEMPT_RT or other real-time patches applied to the BSP kernel?
- What device tree coverage is expected (full production mappings, example DTs, or minimal DTs for lab testing)?
- Which user-space components must be included in the reference image (init system, middleware, container runtime)?
- What level of ongoing BSP maintenance and security patching do you require (duration and SLAs)?
- Do you need integration support (on-site or remote) to port the BSP to your carrier or firmware?
Deliver AUTOSAR MCAL and Basic Software (BSW) Drivers
- Which AUTOSAR platform(s) do you target (Classic Platform version, Adaptive, AUTOSAR-MC)?
- Which MCAL modules and BSW services are required (e.g., ADC, GPIO, CAN transceiver, DMA, NVM, COM)?
- Do you require AUTOSAR-Compliant configuration files (ARXML) and tooling support for integration?
- What ASIL level will these BSW elements need to support or be integrated into?
- Do you need tuned timing and resource budgets (CPU cycles, memory) for the BSW to support multi-domain consolidation?
- Would you like sample integration projects or example configurations for common use-cases?
Provide Hypervisor BSP and Reference Virtualized Images
- Which hypervisor model do you plan to use or evaluate (Type-1 RT hypervisor, Type-2, vendor hypervisor)?
- How many isolated guest domains and what mix (safety-critical RT, infotainment Linux, Android) should reference images demonstrate?
- Do you require device passthroughs (GPU, Ethernet, CAN) or para-virtualized drivers in the images?
- What certification or deterministic latency targets must the hypervisor support for safety-critical guests?
- Do you need reference virtual images with complete boot chains and pre-installed middleware for rapid integration?
- Would you like guidance or scripts to reproduce the reference images and CI for guest updates?
Supply Real-Time Controller Firmware and RTOS BSP
- Which RTOS(es) do you plan to use on real-time controllers (vendor RTOS, FreeRTOS, QNX, others)?
- Do the real-time controllers require safety-certifiable RTOS variants or determinism guarantees (e.g., ISO 26262 ASIL support)?
- What performance metrics/constraints must firmware meet (interrupt latency, context switch times, jitter budget)?
- Do you need reference firmware with drivers for sensors, actuators, and peripheral interfaces pre-integrated?
- What toolchain and debugging environment do you require for RT controller BSP integration?
- Are secure firmware update mechanisms and rollback support required for RT controllers?
Deliver GPU/NPU SDK with Optimized Inference Libraries
- Which machine learning frameworks must be supported out-of-the-box (TensorFlow, PyTorch, ONNX Runtime)?
- What target model types and sizes will you run (vision CNNs, object detection, segmentation, transformer-based models)?
- Do you require quantization, pruning, or operator fusion tools in the SDK to meet latency and power targets?
- What inference performance targets are expected (frames per second, latency p95, TOPS) for representative workloads?
- Do you need reference benchmarks, example models, and optimized libraries for common automotive use-cases?
- Is support for GPU sharing across guests or secure NPU isolation required for your virtualization strategy?
Provide CAN-FD, Ethernet-TSN, and LIN Driver Packages
- Which vehicle network interfaces are in scope for your platform (CAN-FD, Ethernet-TSN, LIN, FlexRay, MOST)?
- For Ethernet-TSN, which TSN features are required (time sync, schedule, shaping, redundancy)?
- Do drivers need to support multiple controller instances and offload features (timestamping, hardware QoS)?
- Will you require protocol stacks or middleware (DoIP, SOME/IP, DoIP over TSN) alongside the low-level drivers?
- Do you need validation test suites, traffic generators, and example test scripts for network conformance testing?
- Are specific PHYs, transceivers, or cable types mandated for compatibility with your vehicle harness suppliers?
Deliver Hardware Security Module SDK and Key Provisioning Tools
- Which security features must the HSM and SDK support (secure boot, secure storage, attestation, crypto acceleration)?
- What key provisioning model do you plan to use (on-site ceremony, remote provisioning, factory pre-provisioning)?
- Do you require integration with existing PKI/CA infrastructure and HSM lifecycle management tools?
- Are certifications required for the security subsystem (Common Criteria, FIPS, PSA Certified)?
- Do you require example provisioning scripts, SDK APIs, and troubleshooting guides for onboarding keys and credentials?
- Is hardware-backed attestation and root-of-trust reporting needed for your supply chain and OTA processes?
Provide ISO 26262 Functional Safety Artifacts and Safety Manual
- What ASIL target(s) does your program require for the SoC and its software subsystems?
- Which safety artifacts are required up-front (safety manual, FMEDA, safety case, requirements traceability matrix)?
- Do you need assistance aligning our safety artifacts to your system safety plan and toolchain (e.g., DOORS mappings)?
- What level of independence is required for safety assessments (internal review, third-party audit)?
- Do you require artifact updates tied to product lifecycle (re-qualification after silicon respin, software updates)?
- Are there specific tooling or file formats you need (PDF safety manual, tool-generated FMEDA, CSV trace matrices)?
-
Mutual Commit
Finalize commercial terms, long‑term supply commitments, qualification schedule, and mutual obligations for success.
Agreement Modules
- Non-Disclosure Agreement (NDA)
- Master Supply Agreement (MSA)
- Statement of Work (SOW)
- Commercial Terms Summary
- Long‑Term Supply & Capacity Commitment
- Qualification Schedule & Acceptance Plan
- Non‑Recurring Engineering (NRE) & Development Funding
- Software Licensing & Support Agreement
- Product Change Notification (PCN) & ECN Process
- Warranty, Returns & RMA Terms
- Intellectual Property & Licensing Rights
- Regulatory & Functional Safety Compliance Annex
- Governance & Steering Committee Charter
- Payment Schedule & Invoicing
- Termination, Transition & Last‑Time‑Buy Plan
-
Deployment
Operationalize rollout with readiness checks, enablement, and outcome validation.
-
Pre-Deployment Readiness
Confirm prototypes, test environments, access, owners, and required safety artifacts are in place for execution.
Readiness Questions
Paint the Program — Where Does This Project Live?
- Can you briefly describe the vehicle program, its production start target (month/year), and which markets it serves?
- Which of these best describes the computing role we’d be supporting on this program?
- Who are the primary decision-makers and technical owners for semiconductor selection on your side? (roles/titles and team leads)
- What are the non-negotiable program constraints we should know up front (e.g., qualification level, temperature grade, 15‑year supply, AEC‑Q100 Grade)?
- What current program KPIs will determine whether a silicon choice is acceptable (e.g., latency limits, power envelope, consolidation targets, BOM impact)?
How Your Current Architecture Actually Behaves — Tell Me a Story
- If your current architecture had to scale down by 30% in compute or I/O, what breaks first and why?
- Describe your present compute topology: number of ECUs, consolidations planned, and where latency-critical functions live.
- Which SoC families or suppliers are you already evaluating, and what specifically is falling short for you?
- What telemetry or evidence can you share about current failure modes (e.g., thermal excursions, intermittent peripheral faults, boot instability, timing jitter)?
- How mature is your software baseline today (BSP, AUTOSAR Classic/Adaptive, hypervisor, Linux kernel), and what gaps are most urgent?
What’s Keeping Your Team Up at Night?
- Which single unresolved technical risk would most likely delay your program if it remains unaddressed?
- How often have these risks materialized in past programs and what was the typical remediation cost (time/person‑months or cost)?
- Which integration handoffs (hardware, BSP, middleware, calibration, QA) are poorly defined today and who currently owns them?
- Which supplier behaviors have historically caused the most friction during qualification (e.g., delayed samples, opaque change management, slow driver fixes)?
- Emotionally—how does your team feel about taking on a new SoC right now? (confidence, dread, cautious optimism, etc.)
What If Your Assumptions Are Wrong — Let’s Call Them Out
- What’s one assumption everyone’s working off that, if false, would force a program rethink (e.g., 'BSP will be production‑ready at samples', 'thermals will be solvable with passive cooling')?
- What test environments, tooling, or datasets are you assuming will be available during bring‑up that might not actually be in place?
- How long can you tolerate late changes to silicon/software before the schedule becomes at‑risk (in weeks)?
- Tell us about a past assumption that failed — what happened, who owned the recovery, and what did you learn?
- If we committed to a mitigation today (e.g., guaranteed driver delivery dates, sample lane prioritization), which assumption would you want us to eliminate first?
If Everything Worked — What Would That Unlock?
- If a candidate SoC met or exceeded your top three must‑have metrics, what program decisions would that enable (consolidation, cost savings, feature expansion)?
- Specify the quantitative acceptance criteria you need for sign‑off in the following areas: real‑time latency (ms/µs), sustained power (W), peak power (W), thermal limit (°C), and required throughput (Gbps).
- Which software deliverables would make you feel confident enough to start parallel development (select all that apply)?
- What production supply terms are necessary for your procurement group to greenlight a design win (e.g., MOQ, lead time targets, lifecycle guarantees)?
- Beyond specs, what would make your engineering leaders genuinely excited about this SoC (e.g., strong partner support, open toolchain, reference platforms)?
Bringing It Into the Lab — Who, What, and When?
- If we handed you evaluation silicon and an SDK tomorrow, what would be your first three integration milestones and their owners?
- Which of these test assets must be available before you consider scheduling bring‑up activities?
- How much lab access (hours per week) and which facilities will you need from us during the first 90 days?
- Who on your team will be the primary point of contact for hardware bring‑up, BSP integration, and functional safety respectively? (names/titles)
- What timeline do you expect for reaching a stable bring‑up (from first silicon to defined acceptance) in weeks?
Acceptance, Validation, and Evidence — What Will You Require?
- Which validation areas are mandatory for your acceptance gate (select all that apply)?
- For ASIL/functional safety, what artifacts do you expect to receive from the silicon supplier (e.g., FMEDA, safety manual, diagnostic coverage reports)?
- What are your minimum sample quantities and delivery cadence required to meet qualification milestones?
- Which test or certification labs do you plan to use (in‑house or third‑party), and are there constraints we should know about?
- In your view, what defines a 'design win' for this program beyond sample acceptance (e.g., production release, supply agreement, post‑launch support)?
Decisions, Commitments, and the Small Print
- What commercial or contractual terms are non‑negotiable for you before committing to a design (warranty, long‑term supply, change notification, IP licensing)?
- Who holds final budget authority and procurement sign‑off, and what is their typical review cadence?
- If we propose a joint mitigation plan for your top two risks, what governance cadence and artifacts would you expect (weekly standups, shared risk register, escalation path)?
- Realistically, what would make you say 'yes' to moving to evaluation samples within the next quarter?
- Are there procurement or policy hurdles (e.g., approved supplier lists, country‑of‑origin, certified processes) we should prepare for now?
Closing the Loop — Quick Signals & Next Steps
- After this discovery, which of these next steps would you most value from us first?
- How quickly can your team commit to an initial technical review session or lab hand‑on once samples are available?
- What metrics should we track together during evaluation to demonstrate progress (pick top three)?
- Any final concerns, deal breakers, or political constraints we haven’t asked about that could change the path forward?
-
Deployment Enablement
Schedule integration milestones, deliver BSPs and drivers, coordinate bring‑up tasks, and assign owners.
-
Validation Checklist
Execute and document ASIL, thermal, latency, peripheral, and supply validation against acceptance criteria.
Validation Questions
Start Here: Describe Your Program in One Breath
- In one sentence, how would you describe the vehicle program or platform you're evaluating?
- Which program type best matches this effort?
- Who is the primary buyer or internal champion for the SoC decision on this program?
- What is your target production start year or milestone for SoC lock?
Where the Pressure Really Is
- If the chosen compute solution under‑delivered, whose job would be at immediate risk and why would that failure be felt most acutely?
- Which domains feel most mission‑critical for this program right now?
- How often have compute limitations (performance, latency, thermal) caused late rework or schedule slips in your recent programs?
- Tell us about a recent incident where compute or thermal constraints forced a compromise—what was the trade‑off and the outcome?
- How long has this kind of constraint been repeating across your projects?
What's Breaking Your Flow?
- What's the single integration or software problem that consistently causes schedule slips—and why hasn't it been permanently solved?
- Which software stacks and runtimes are you committing to for the platform?
- How mature are your internal BSPs, drivers, and bring‑up processes for SoC integration?
- Who owns software bring‑up and integration inside your org, and how is that team structured?
- How much of the software integration work do you expect our team to own versus your team?
Unseen Risks That Keep You Up at Night
- What single safety, compliance, or supply risk could stop this program cold if not addressed immediately?
- Which ASIL or safety levels apply to the domains you plan to run on this SoC?
- Do you have an established functional safety flow (FMEDA,ASIL allocation, FMEA, SOTIF processes)? What are the largest gaps?
- How confident are you that the SoC and its software ecosystem can meet AEC‑Q100 Grade 1 and 15‑year support expectations?
- Which qualification gates have historically been the hardest to pass (thermal, EMC, HIL, reliability, long‑term stress testing)?
What Would Winning Feel Like—Tactile & Emotional
- Imagine the design win is announced—beyond specs, what will stakeholders be celebrating as proof we got it right?
- Which acceptance criteria are non‑negotiable for sign‑off at qualification?
- Which raw performance targets drive your architecture decisions (e.g., CPU cores, inferencing TOPS, deterministic ISR latencies)?
- How will acceptance differ between prototype validation and production qualification—what must be proven early versus later?
- Who must sign off on a design win internally, and what are their core emotional concerns (risk‑averse, cost‑focused, time‑to‑market pressure)?
Reality Check: Timelines, Budgets, and Trade‑offs
- If you had to cut functionality to hit your current deadline, what would you remove—and who would be most upset?
- What is your hard deadline for SoC selection or engineering sample availability?
- How flexible is your budget for a higher‑performance silicon that reduces integration and validation risk?
- What trade‑offs between cost, power, and performance are you willing to accept? Please give concrete thresholds or examples.
- Has budget pressure pushed you toward lower‑spec silicon before? What were the downstream consequences?
Supply Chain & Long‑Term Confidence
- If your SoC vendor could not meet demand for a three‑year period, how would that impact your program and what contingencies exist?
- Do you require long‑term supply agreements and what cadence of forecasting / inventory do you expect?
- Have you experienced lead‑time or allocation issues with semiconductor suppliers recently?
- What lifecycle management and change‑notification expectations do you have (e.g., pin‑compatible migrations, EOL timelines, long‑term test data)?
- Which manufacturing or quality certifications are must‑haves for your program?
How We Can Move the Needle—Next Steps & Support
- What's the single most valuable deliverable our team could produce in the next 30 days to materially reduce your risk—and why would it change the conversation?
- Which engagement model would accelerate your decision most effectively?
- What concrete artifacts or demo scenarios would convince your validation and safety engineers (e.g., worst‑case thermal run, deterministic latency demo, ASIL artifacts)?
- Who are the internal decision‑makers we should invite to the next technical review, and what is each person's top concern to address?
- When would you like a follow‑up workshop to review initial integration findings and co‑create a mutual validation checklist?
- Would you be open to co‑creating a joint validation checklist (ASIL, thermal, latency, peripherals, supply) that we both commit to executing?
-
-
Success
Confirm design win and production readiness, capture learnings, and maintain a shared channel for issues and enhancements.
Success Reviews
- Design Win Confirmation & Executive Sign-off
- Production Readiness Gate Review (PRG)
- Integration Handover & Support Channel Setup
- Lessons Learned & Continuous Improvement Workshop
- Post-Launch Monitoring & KPI Review
Issues & Enhancements
- Ensure feedback items are linked into the product roadmap or support backlog for visible tracking.
- Open CAPAs for any failed gate items with remediation plans and target close dates.
- Schedule a follow-up surveillance review after pilot run completion to confirm final acceptance criteria.
- Current Communication Landscape
- Establish a single shared channel and ticketing workflow that all parties commit to using for issues and enhancements.
- Agree measurable SLAs and an escalation matrix so critical production issues are handled predictably.
- Assign clear owners for software/BSP updates, safety artifacts, and change notifications.
- Provision the shared workspace and invite nominated participants with role-based access controls.
- Publish the SLA and escalation matrix and attach it to the shared channel as the canonical reference.
- Create intake templates for defect reports and enhancement requests to ensure consistent submissions.
- Set Scope & One-sentence Current State
- Produce a prioritized list of actionable improvements with assigned owners and clear acceptance criteria.
- Identify at least three process or product changes that will materially reduce risk or cycle time for the next program.
- One-sentence Current State
- Publish the retrospective report with prioritized actions, owners, and due dates to the shared channel.
- Create roadmap tickets for product-level feedback and assign product managers to review within two weeks.
- Schedule a 30/60/90-day follow-up to validate progress on improvement actions.
- KPI Dashboard Review
- Detect and triage early production issues before they materially impact fleets or supplier commitments.
- Maintain visibility into KPIs and supplier health to support confident production ramp and sustainment.
- Ensure the shared channel contains up-to-date telemetry, incident logs, and remediation status for stakeholders.
- Publish the KPI dashboard to the shared workspace and notify stakeholders of any KPI breaches immediately.
- Open high-severity incident tickets with defined containment and permanent fix timelines.
- Confirm the patch/release calendar and communicate blackout windows or compatibility advisories to customers.
- Obtain unambiguous executive sign-off confirming the design win or document conditional requirements for approval.
- Ensure every acceptance criterion has a cited proof artifact and a named owner for any open items.
- Agree on a committed timeline for production launch milestones and commercial actions (POs, contracts).
- Circulate the signed design-win confirmation including explicit acceptance criteria and any conditions within 24 hours.
- Assign owners and deadlines for all open non-conformances and publish a live tracker.
- Trigger procurement/legal to finalize long-term supply agreement and issue initial POs as agreed.
- Pre-work Summary & Required Artifacts
- Authorize or defer pilot/mass production based on objective gate criteria with documented reasons.
- Ensure cross-functional alignment on remaining risks and mitigation owners prior to release.
- Confirm that safety artifacts and reliability requirements meet program needs for production acceptance.
- Publish the PRG decision and update the production timeline in the shared program tracker.
- Shared Channel & Tooling Proposal
- Field Incidents & Root Cause Summaries
- Data Review: Metrics & Incidents
- Manufacturing Readiness
- Consequence & Business Impact
- Quality & Reliability
- Defined Future State / Acceptance Criteria
- Supplier Performance & Capacity Check
- SLA & Escalation Matrix
- What Worked / What Didn't (Breakout + Synthesis)
- RACI: Owners for Runbook, BSP, SW Fixes, and ECN/CN Procedures
- Evidence Pack Review (Diagnosis -> Proof)
- Supply Chain & Logistics
- Planned Releases & Patch Schedules
- Define Concrete Improvements & Owners
- Action Review & Prioritization
- Open Non-Conformances & Mitigations
- Process for Enhancement Requests & Roadmap Feedback
- Safety & Compliance Signoff
- Roadmap & Product Feedback Loop
- Risk Register & Contingency Plans
- Decision & Signature Capture
- Immediate Next Steps and Timeline