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.
Example organizations in this space:
Qualcomm
NXP Semiconductors
Renesas
Texas Instruments
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 diagnose before investing in a full evaluation cycle.
-
Qualification
Confirm budget range, decision-makers, timeline, and high-level fit before investing in detailed technical discovery.
Qualification Questions
High-level technical and compliance fit
- To make the best use of your time, which functional-safety level must the platform support?
- Which of these technical constraints are must-haves for your program? Select all that apply.
- Roughly which class of compute does your target architecture require per vehicle?
- Does your program require automotive-grade qualification (AEC-Q100 Grade 1) or an alternate qualification?
Budget
- Is there an allocated budget range for the silicon platform in this program?
Decision authority
- Who will sign off on the silicon selection for this program?
Timeline and next step
- What is your target decision or commit milestone for selecting a silicon platform?
- If there is a single program date driving this timeline (prototype, vehicle freeze, production launch), please name it or its target month.
-
Technical Discovery
Map current architecture, performance targets, safety constraints, stakeholder roles, and program timelines.
Discovery Questions
Start Line: Program goals, scope, and decision signals
- Tell me the vehicle program class and the planned production start month and year.
- How many ECU domains or consolidated zones are you planning this architecture to support?
- Provide your target production volumes in year one and year three.
- Who on your team will be the decision owner for selecting the SoC family and who will own system integration?
- Do you already have a target budget range for compute and module cost per vehicle?
- If the first silicon candidate meets peak performance but misses a safety timing target, would you continue qualification, pause for a revision, or re-scope the prototype plan?
Where your architecture today diverges from the roadmap
- When you overlay your current architecture with your roadmap, where does capability fall short of your three-year target?
- Walk me through your current compute stack for the zone or controller that will host both safety and non-safety workloads, include CPU classes, real-time cores, GPUs, and accelerators.
- Select the vehicle networks and peripheral interfaces you use for this controller, choose all that apply.
- Estimate your current end-to-end latency budget for the most timing-critical function and the percent of that budget already consumed by software layers.
- Identify the team or role that currently verifies hardware-software interaction and signs off on timing and safety budgets.
- What single integration dependency in your current architecture, if unavailable, would force you to delay a prototype milestone?
Hard targets: what would make or break a candidate
- What single performance or safety metric would make you walk away from a candidate SoC immediately?
- Quantify your required sustained multi-core throughput for consolidation workloads in TOPS, DMIPS, or equivalent, and list which workloads consume the most compute.
- Which functions must meet ISO 26262 ASIL-D timing and how are you planning to partition safety-critical tasks across real-time and application cores?
- How much thermal headroom and package power budget do you reserve for peak scenarios in a sealed enclosure?
- Estimate the maximum tolerable soft error or fail rate for safety subsystems over a 15-year program and list any silicon-level mitigations you require.
- If the vendor cannot deliver required safety artifacts within your timeline, what is the shortest acceptable delay before the program is at material risk?
Software ecosystem and driver reality check
- Which middleware, hypervisor, and AUTOSAR RTE versions are you planning to use, and which gaps in those stacks would immediately block supplier qualification?
- Describe your preferred BSP and driver ownership model, do you expect the seller to deliver production-ready BSPs, or will your team own BSP maintenance?
- How many legacy peripheral variants and software forks do you support across product lines that would need BSP or driver adaptation?
- List ownership for CAN, LIN, MOST, Ethernet TSN and other interface stacks in your current integration plan, and note whether APIs are available for the integration endpoint.
- List the development toolchains, compilers, and CI environment types that must be supported out of the box to avoid rebuilds.
- If a required peripheral driver is missing, what is the maximum delay in weeks your integration schedule can tolerate before qualification milestones slip?
Where projects stall and what usually breaks first
- Describe a recurring integration failure or supplier behavior that historically caused the longest program delays for you.
- When a critical interface fails certification, who is enabled to re-scope the work and how long does that decision typically take?
- Roughly, what's the size of the engineering team you allocate to SoC bring-up and integration in the first six months?
- Provide the names of external vendors, test labs, or service providers you rely on for environmental, EMC, and ATE qualification, and flag any with long lead times.
- If you had to name the single schedule risk that would stop the program from moving to pilot, what would it be?
- How often do hardware supply issues drive changes to software schedules, in months between incidents?
Competitive landscape, alternatives, and the case for staying put
- Name the suppliers, incumbent options, and internal projects you are actively evaluating for SoC or internal options, and indicate which is the current frontrunner.
- Which alternatives on your short list are internal builds, incumbent suppliers, or third-party platforms, select all that apply.
- Explain the conditions under which you would keep the incumbent or internal approach rather than switching to a new supplier.
- Has anyone internally proposed solving this with in-house silicon or a software-only approach, and if so who owns that proposal?
- If a supplier demonstrated parity on performance but required longer support and supply commitments, would that change your preference?
- Which single business decision, if made this month, would accelerate a signature within 30 days?
Operational readiness and implementation constraints
- If you cannot commit lab access and test harnesses in the first 12 weeks, how will you meet the qualification timeline?
- Identify the owner of APIs and firmware updates for any third-party modules that must be integrated, and state when they can grant access.
- To proceed, the seller requires a primary point of contact with network access and appropriate approvals, can you provide that contact within two weeks?
- Do you have internal headcount experienced in ISO 26262 activities and AEC-Q100 acceptance testing, or will you rely on external consultants?
- Which software artifacts and test data are available now for the seller to run initial validation, select all that apply.
- If critical infrastructure is missing, what is the earliest date you could make it available without changing your project milestones?
Decisive acceptance criteria and next steps
- If an initial prototype meets the key acceptance criteria, which internal approvals would immediately clear you to enter a supply agreement, select all that apply.
- Provide your top three measurable acceptance criteria you require for qualification sign-off and include target numbers or pass thresholds.
- Who must sign the qualification gate within your organization and what is their approval timeline once results are available?
- If the pilot proves the metrics, what is the single remaining barrier that would prevent you from signing within 30 days?
- When would you prefer the seller to schedule a joint technical review, within the next 2 weeks, 4 weeks, 8 weeks, or later?
- Would a trial hardware loan and a two-week lab support window accelerate your evaluation and move you closer to decision?
-
-
Hardware Evaluation
Hands-on validation against the buyer's acceptance criteria for compute, latency, peripheral integration, power, and software ecosystem maturity.
- desired_state
- current_state
- decision_readiness
- stakeholders
- gaps
- success_criteria
- stakeholders
- decision_readiness
- current_state
- desired_state
- success_criteria
- gaps
- stakeholders
- desired_state
- current_state
- decision_readiness
- success_criteria
- gaps
- decision_readiness
- decision_readiness
- decision_readiness
- decision_readiness
-
Solution Scope
Define the SoC family options, responsibilities, verification milestones, and measurable acceptance criteria for qualification and production.
Scope Configuration
- Supply automotive-qualified SoC devices
- Deliver reference carrier board and EVK kit
- Provide Linux board support package (BSP)
- Provide AUTOSAR MCAL driver package
- Provide hypervisor BSP and reference partitioning
- Deliver safety‑ready RT-core firmware and safety libraries (ASIL‑D support)
- Deliver hardware security module and key provisioning tools
- Deliver vehicle network interface drivers (CAN/CAN‑FD/LIN/FlexRay/TSN)
- Deliver GPU and NPU driver stack with runtimes
- Deliver bootloader and secure boot implementation
- Provide power management firmware and DVFS profiles
- Deliver long‑term production supply and change‑notification agreement
Scope Questions
Supply automotive-qualified SoC devices
- For your program, which SoC family options should be evaluated (entry-level body controller, mid-range domain controller, high-performance cockpit/ADAS)?
- How many application CPU cores and how many real-time cores must available SoC variants include to meet your consolidation goals?
- Specify the AEC-Q100 grade and ambient temperature range your qualification requires for production devices.
- Describe the sustained multi-core throughput or inference targets you require (examples: TOPS for NPU, sustained CPU throughput targets, or benchmark names and target numbers).
- Identify the peripheral interface counts and types you require on the die (example: CAN FD controllers, TSN ports, PCIe lanes, MIPI-CSI/DSI lanes).
- Which acceptance evidence will confirm the devices meet automotive qualification for your program (examples: AEC-Q100 certificate, temperature cycle report, ISO 26262 safety assessment)?
Deliver reference carrier board and EVK kit
- Which EVK interfaces must be present on the carrier board to support your integration (examples: PCIe, multiple CAN FD transceivers, USB, M.2, TSN Ethernet)?
- How many populated peripheral connectors and how many thermal mounting points do you require on the EVK for your lab validation and harnessing?
- Specify the board-level power rails and maximum board power draw allowance the EVK must support for your peak and idle test profiles (in watts and voltage rails).
- Describe mechanical form factor or mezzanine footprint constraints the EVK must match for your integration (examples: SOM pinout compatibility, custom mezzanine dimensions).
- Which electrical and environmental test results will you accept for the EVK as evidence of readiness (examples: thermal soak data, EMI/EMC pre-compliance, measured power draw thresholds)?
- Do you require factory-flashed sample firmware, labeled kit contents, and serial-number traceability for EVK sample deliveries?
Provide Linux board support package (BSP)
- Which Linux kernel major baseline (example: LTS 5.x, LTS 6.x) and patch set do you plan to use as the BSP upstream for your integration?
- Which device tree overlays and middleware components must the BSP include for your vehicle platform (examples: display stack, CAN FD support, TSN config, GPU/NPU bindings)?
- Do you require PREEMPT_RT or other real-time kernel patches applied and maintained in the BSP for your deterministic workloads?
- Specify your cold start and boot-to-application time target for cockpit or instrument cluster use cases (time from power applied to first-frame or UI ready, in seconds).
- Identify the BSP delivery artifacts you need with the package (examples: kernel config, cross-toolchain, reproducible build scripts, kernel crash collection tooling).
- Do you require BSP security hardening guidance and secure-boot integration documentation as part of the BSP handoff?
Provide AUTOSAR MCAL driver package
- Which AUTOSAR stack type and MCAL baseline do you require (Classic Platform, Adaptive, or both) for your ECU integration?
- Specify the number and types of vehicle network controller channels the MCAL drivers must cover (examples: CAN FD controller count, LIN channels, FlexRay controllers, Ethernet ports).
- Describe timing constraints for MCAL driver responses that are critical to your ECU behavior (examples: ISR latency budget in microseconds, polling intervals).
- Do you need MCAL delivered with ARXML-compatible configuration exports that plug into your ECU configurator toolchain?
- Identify the MCAL configuration and test artifacts you will supply or require during integration (examples: generated ARXML, unit test logs, timing profiles).
- Are there legacy API compatibility requirements or specific function prototypes the MCAL must expose for reuse of your existing ECU software?
Provide hypervisor BSP and reference partitioning
- Which guest OS types and partitioning model should the hypervisor reference support (examples: Linux user domain, AUTOSAR Classic, RTOS for safety cores)?
- Specify the isolation boundaries and guaranteed performance you require for partitions (examples: CPU slices, memory carve-outs, worst-case latency budgets in microseconds).
- Do you require pre-built reference partition images and example VM layouts to use in your ISO 26262 demonstration and safety audits?
- Provide the expected boot and warm-reboot sequencing behavior for the hypervisor and partitions that your integration will rely on.
- Are you planning to run mixed-criticality workloads with ASIL-D domains alongside non-safety domains; if so, list the ASIL assignments per partition or domain.
- Which hypervisor configuration artifacts will you need delivered (examples: partition descriptors, resource tables, scheduling policy files)?
Deliver safety‑ready RT-core firmware and safety libraries (ASIL‑D support)
- List the RT-core firmware modules and safety libraries you need for your control functions (examples: watchdog, lockstep support, safe-IO drivers).
- Which ISO 26262 ASIL levels and specific safety goals must the delivered firmware and libraries support for your program?
- Identify the safety artifact file formats and documents you must consume during integration (examples: FMEDA spreadsheets, fault injection reports, software architectural design descriptions).
- Do you require cross-validation test benches, golden reference traces, or hardware-in-the-loop fixtures for RT-core deterministic behavior verification?
- Specify the maximum allowed interrupt latency and recovery time for safety-critical RT-core firmware in microseconds that your safety case depends on.
- Which toolchain and compiler versions must be used to build safety libraries to align with your tool qualification plan?
Deliver hardware security module and key provisioning tools
- Which root-of-trust functions and cryptographic algorithms do you require from the hardware security module (examples: secure key storage, ECDSA, AES-GCM, hardware RNG)?
- Specify the provisioning workflow you will adopt for device keys (examples: factory secure provisioning, on-site secure provisioning, offline provisioning with HSM appliance).
- Describe required attestation and secure-boot integration artifacts you expect from HSM delivery (examples: signed manifests, attestation certificates, audit logs).
- Do you require FIPS or Common Criteria certification levels for the hardware security module for your program?
- Identify key lifecycle management constraints you will enforce (examples: key rotation frequency, rollback prevention requirements, secure erase policy).
- Which developer tools, CLIs, or APIs do you need for automated key provisioning and integration into your factory test flow?
Deliver vehicle network interface drivers (CAN/CAN‑FD/LIN/FlexRay/TSN)
- Which vehicle bus types and channel counts must the driver package cover for your platform (examples: number of CAN FD channels, number of TSN ports)?
- Specify required bus speeds and timing parameters for each interface you will use (examples: CAN FD bitrates, TSN scheduling windows).
- Describe the diagnostics, logging, and DLT integration points you require from the network drivers for POC and field diagnostics.
- Do you require built-in support for ISO-TP or UDS over CAN in the delivered driver stack?
- List the test vector types you will run during network driver integration (examples: bus load, error injection, wake/sleep cycles).
- Are there specific transceiver variants or PHY vendor families your carrier board must be compatible with?
Deliver GPU and NPU driver stack with runtimes
- Which graphics and neural runtimes must be supported out of the box for your application (examples: Vulkan or OpenGL ES for graphics, and which NN runtime versions for NPU)?
- Specify the inference performance target (TOPS) and target frames-per-second for display workloads that the driver stack must sustain for your use case.
- Describe any deterministic rendering or preemption guarantees you need for mixed-criticality displays (examples: guaranteed frame latency under X ms).
- Do you require validated GPU/NPU power vs. performance curves and thermal throttling profiles to be delivered with the driver stack?
- Provide the profiling artifacts you expect with driver delivery (examples: trace logs, power vs. performance charts, benchmark scripts).
- Which user-space ABI stability commitments or long-term driver compatibility guarantees do you require for your program?
Deliver bootloader and secure boot implementation
- Specify the secure boot chain, signing algorithm families, and key storage expectations you require for production devices.
- Which bootloader features are mandatory for your OTA and field update strategy (examples: A/B update, rollback protection, signed update verification)?
- Describe the recovery and emergency flash programming process you require for field units and service bay procedures.
- Do you require a verified boot sequence and audit logs for each boot to support forensic analysis and field failure investigation?
- Identify the test vectors and boot logs you plan to review during bootloader validation (examples: chain-of-trust verification logs, rollback test traces).
- Are there secure element or TPM interfaces the bootloader must integrate with on your production hardware?
-
Mutual Commit
Finalize commercial and legal terms, long‑term supply commitments, qualification milestones, and mutual obligations.
Agreement Modules
- Long-Term Supply Agreement
- Purchase Agreement / Order Confirmation
- Qualification & Acceptance Plan
- Quality, Safety and Compliance Addendum
- Software License Agreement
- Warranty, Returns and Field Support Agreement
- Change Control and Engineering Change Notice (ECN) Process
- Confidentiality and IP Protection Agreement
- Source Code Escrow Agreement (conditional)
- Commercial Terms Summary & Payment Schedule
-
Deployment
Operationalize validation, production ramp, and release with readiness checks and acceptance gates.
-
Pre-Deployment Readiness
Confirm lab access, validation owners, test harnesses, sample schedules, and environment readiness required for integration and qualification runs.
Pre-Deployment Questions
Environment and site access
- Will integration and qualification runs occur at a single lab site or multiple sites? (so we can assign site-specific logistics)
- For each site to be used, provide the site name and primary lab contact (name, role, email) — this lets us open access requests and coordinate deliveries
- Is physical lab access for the seller's validation engineers granted at each site?
Test harnesses and samples
- Which validation harness types will be used during integration? (select all that apply)
- Are the buyer's acceptance criteria and canonical test cases available to the seller for pre‑run verification?
- Has a sample delivery schedule been agreed (initial eval, qualification, production samples)? If yes, list milestone names and dates so we can plan test windows.
People and ownership
- Who are the named owners for Validation lead, Integration lead, and Functional‑safety lead? Provide name, role, and primary contact so we can assign task ownership.
- Do the named owners have sign‑off authority for qualification test runs and sample acceptance?
- Who is responsible for lab network and cybersecurity during validation runs (buyer, seller, or third‑party lab)? Provide organization and contact to coordinate remote access setup.
Timing and constraints
- Are there blackout windows, production freezes, or compliance gates that restrict when integration/qualification runs can occur?
- Is the site infrastructure validated to support DUT environmental needs (power, cooling, and specified ambient/environment profile)?
- Will remote debug/telemetry be available to seller engineers during runs (VPN/remote console), or will debugging be on‑site only? Note restriction type so we can plan remote procedures.
-
Integration Configuration
Capture exact integration and configuration values the teams will use — interface mappings, firmware settings, BSP/hypervisor versions, and toolchain requirements.
Configuration Details
Integration environment & endpoints
- Primary integration environment name (single token; Default: lab-integration)
- Primary Linux BSP kernel version to deploy on integration boards (format: major.minor.patch — Default: 5.10.0)
- Primary hypervisor variant to use for integration (Default: Type-1 automotive hypervisor)
Interface & peripheral mappings (one mapping per question)
- Primary Ethernet interface mapping (format: SoC_interface->vehicle_domain_interface, e.g., GMAC1->domain_eth; Default mapping: eth0->domain_eth)
- Primary CAN/CAN-FD port mapping (format: SoC_port->vehicle_net_name, e.g., CAN1->powertrain_CAN)
- UART console port and baud rate for integration (format: UARTx,baud — Default: UART0,115200)
Firmware, bootloader, and toolchain
- Bootloader version or tag to install on integration boards (format: tag or semver — Default: v2023.04)
- Real-time MCU firmware image version for safety cores (format: major.minor.build — Default: 1.0.0)
- Cross-toolchain selection to build kernel and BSP images (Default: GCC 11.3)
- If you selected 'Other' for cross-toolchain, enter the exact toolchain identifier (e.g., customtoolchain-2024-07). Leave blank if not applicable.
Hypervisor partitioning, safety, and artifact handoff
- Hypervisor partitioning config filename or repo tag to load on integration (format: filename or repo:tag — Default: partition-config.yaml)
- CPU affinity mask for safety partitions (format: hex bitmask, e.g., 0x3 for cores 0-1 — Default: 0x3)
- Target functional-safety level for this integration (Default: ASIL-D)
- Primary artifact repository URL for BSPs, boot images, and firmware (format: https://... — Default: https://artifacts.example.com/integration)
- Artifact repository credential identifier (service account name or key name stored in your secrets manager). Do NOT paste secrets here; provide the non-secret identifier only.
- Secrets manager or secure handoff method where the artifact secret will be exchanged (choose one — Default: your secrets manager)
-
Validation & Production Ramp
Execute engineering validation, ISO/functional-safety activities, qualification testing, and scaled production ramp with clear owners and timelines.
-
Production Release Acceptance
Formal acceptance gate: verify qualification results, safety sign-offs, AEC compliance, and production sample approvals before full supply release.
Checklist items
- Receive signed final qualification test report
- Obtain functional safety sign-off
- Receive automotive qualification certificate and reliability summary
- Approve environmental and stress-test reports
- Obtain production sample approval
- Approve First Article Inspection (FAI) and process control plan
- Finalize packaging, labeling, and traceability
- Close or document engineering changes impacting release
- Approve failure analysis and field returns procedures
- Issue formal production release authorization
-
-
Success
Monitor outcomes, capture learnings from qualification and ramp, and maintain a shared channel for issues and enhancement requests.
Success Reviews
- Go-live Health Check (weeks 1-4)
- First Measurement Review (weeks 4-10)
- Acceptance Gate, Qualification Decision (around day 90)
- Production Ramp Review (month 3-6 post-acceptance)
- Quarterly Success Review (operational cadence)
Issues & Enhancements
- Launch supplier corrective action requests where supplier-related defects affect yield.
- Any failed criteria have a mitigation and verification plan with target completion dates.
- Acceptance records and evidence are archived for traceability to qualification artifacts.
- Publish the formal acceptance decision document that lists pass/fail per criterion and includes the signatory record.
- For failed items, publish a remediation and verification plan with concrete run windows and target dates.
- Update the project tracker to reflect the move to production ramp monitoring and set the next review date.
- Present production sample yield and test coverage
- Production yield and field failure metrics are shown vs targets from Solution Scope and either meet targets or have agreed remediation.
- Containment plans for any quality or supplier issues are defined with resolution dates.
- Schedule for subsequent verification runs and the next ramp review is confirmed.
- Issue a production-ramp status report that includes yield, PPM, and test coverage against Solution Scope targets.
- Reconfirm success criteria and owners
- Schedule extended thermal soak runs and publish results to the shared validation channel.
- Trend review of primary metrics
- Primary operational metrics remain within the range expected by the Solution Scope or have agreed corrective actions.
- Enhancement request backlog is reviewed and has a prioritized plan for the coming quarter.
- Shared issue channel and runbook are confirmed current and accessible to both teams.
- Publish the quarterly metric dashboard with trend lines for the cited metrics and link to the evidence.
- Close enhancement requests documented as obsolete and re-assign those requiring active work to the backlog with dates.
- Update the runbook and shared issue channel with the latest escalation contacts and verification steps.
- Deployment baseline is confirmed and all required lab and sample access is validated.
- Top open blockers are documented with remediation actions and target dates.
- Owners for each acceptance criterion recorded in the Solution Scope are confirmed.
- Publish a deployment baseline checklist confirming sample IDs, lab access credentials, and test harness versions.
- Document the top 5 open defects with temporary mitigations and target remediation dates.
- Circulate the agreed short-term remediation plan and schedule the first-measurement data collection window.
- Present measured results vs Solution Scope targets
- Measured values for the named metrics are recorded and compared to targets in Solution Scope.
- Root-cause actions are agreed for any metric outside target and have clear verification steps.
- Schedule for final acceptance gate is confirmed with the data set and owners defined.
- Publish the first-measurement report with raw logs and aggregated metrics referenced to the Solution Scope targets.
- Initiate the agreed remediation test runs and record the verification protocol and completion dates.
- Prepare the acceptance gate packet that lists each acceptance criterion and the supporting evidence to be presented.
- Restate acceptance criteria and pass/fail matrix
- Each acceptance criterion from Solution Scope is recorded as pass or fail with a documented signatory.
- Analyze field failure and warranty data
- Present outcome data against each criterion
- Diagnose root causes for any gaps
- Deployment and sample availability validation
- Persistent issues and blocker status
- Early integration and onboarding signals
- Enhancement request backlog review
- Document pass or fail per criterion and capture signatory
- Thermal and power stability verification
- Agree corrective actions and verification plan
- Confirm timeline to the acceptance gate
- Operational runbook and shared channel health
- Supply, quality, and supplier issue triage
- Agree remediation plan for any failed criteria
- Open defects and blocker triage
- Agree next quarter actions or shorten meeting if no changes
- Agree immediate remediation actions and timeline
- Close acceptance meeting and confirm next operational cadence
- Agree corrective actions and ramp-to-volume milestones