Quick start, how you evaluate a new processor choice

• How often does your team evaluate and select a new processor architecture for a product? Options: Multiple times per year, Once per year, Every few years, Rarely
• Which product type is this evaluation targeting, pick the primary use case for your design? Options: Battery-powered IoT endpoint, Industrial edge gateway, Automotive cockpit controller, Medical device, General purpose embedded appliance, Other
• Tell me about the evaluation board or prototype setup you typically bring to benchmarks, who manages it and how is it provisioned?
• When you compare processor candidates, which metric most often decides the shortlist for your team? Options: Performance per watt, Real-time latency, Safety certification readiness, Toolchain and ecosystem maturity, Long-term supply guarantee
• Who on your team is the final technical decision owner for processor selection? Options: Principal engineer / architect, Head of hardware engineering, VP engineering, Program manager, Procurement lead

Where the current design actually fails

• If you had to name one measurable failure of your current processor family that would trigger a redesign, what is it?
• Describe recent incidents where performance-per-watt or thermal limits forced a feature reduction, delayed a release, or increased unit cost.
• Estimate the incremental engineering or bill-of-materials cost per unit when your design exceeds its power budget. Options: <$1, $1–$5, $5–$20, >$20, Unknown
• List which certification or safety milestones have been delayed by your current architecture limitations.
• Which single technical shortfall, if unresolved within your target window, would make you abandon this candidate entirely?

Benchmarks that actually map to your product

• Would a benchmark that matches your real-time workload but requires 10 percent more power be acceptable for prototyping, or would that disqualify the candidate? Options: Acceptable for prototyping, Disqualifies candidate, Case-by-case, need more context
• Walk me through the exact workload you plan to run in evaluation, include thread counts, data rates, models, and which operations are latency sensitive.
• Provide the quantitative acceptance thresholds you require for throughput, tail latency, and average power, include units.
• Share the tools and measurement setup you use today to capture power and performance, and indicate whether these are automated Options: Fully automated lab, Partially automated, Manual runs with scripts, Ad hoc manual measurements
• If a run on our evaluation kit meets your stated thresholds, who signs technical acceptance and what artifacts do they require?

Migration cost, how much is too much

• Assuming firmware migration requires refactoring 30 percent of your codebase, would you still proceed with the architecture switch? Options: Yes, No, Maybe with vendor assistance
• Describe your current codebase size and language mix, include rough lines of C/C++ and any assembly hotspots.
• Name the critical middleware or board support packages that must be available before you can move forward.
• Are there legacy closed-source drivers, proprietary IP blocks, or third-party licenses that could block porting? Options: Yes, several, One or two edge cases, No, mostly open
• Who in your organization can allocate and commit dedicated engineering time for initial bring-up, and can that owner commit to a first bring-up within four weeks?

Ecosystem readiness, not just silicon

• Could you ship to production if one or more key RTOS or middleware vendors had not certified their stacks on the new core? Options: Yes, we can self-certify, No, vendor certification is required, Depends on which vendor
• Select the RTOS and middleware categories that are required for your product, check all that apply. Options: Commercial RTOS, Open-source RTOS, Safety certified middleware, Connectivity stacks (Ethernet, CAN, Wi‑Fi), ML inference runtime, Security root-of-trust and crypto
• Explain how toolchain and compiler version lockstep affects your release cadence and how you triage compiler-related bugs.
• Indicate the number of third-party integrations or vendor BSPs that must be validated before you declare firmware ready. Options: 1–2, 3–5, 6–10, >10
• Suppose your preferred RTOS vendor will not commit to qualification within your timeline, what is your fallback option and who owns that decision?

Safety and certification, the gating criteria

• How would a one-year delay in a required safety certification change your product launch plan and revenue expectations?
• When do you need the critical certifications (functional safety, EMI, medical) completed on the path to first production, select the target window Options: Before pilot, During pilot, Before mass production, Not applicable
• List specific lab tests or facilities you cannot complete without the seller's support, for example shock, thermal chambers, or automated EMC sweeps.
• Identify who in your organization is responsible for certification sign-off and whether they have prior experience with a processor migration of this scale.
• Name the single certification risk that would stop production, and describe your contingency options.

Supply chain, pricing, and long-term availability

• Would the inability to guarantee production beyond five years change your supplier selection for this product? Options: Yes, would disqualify, No, other factors matter more, Depends on mitigation terms
• Select the production horizon you require for this processor. Options: 3 years, 5 years, 7 years, 10 years
• Estimate the annual volume profile you expect in year one and at peak production, provide ranges if helpful.
• Are there contract terms, minimum purchase commitments, or pricing ceilings your procurement team requires before approving a vendor? Options: Yes, strict MPCs, Flexible, need negotiation, No strict requirements
• Identify the procurement contact who can approve long-term supply commitments, and state the lead time they require.

Competitive landscape, what you are actively comparing

• Looking at your finalist list, which option feels the safest and what would need to be true for you to stay with the incumbent?
• Choose all alternatives you are evaluating today, including internal or custom options. Options: Current incumbent with minor changes, Another external architecture, Internal re-architecture, Open-source core supported in-house, Custom silicon partner, Undecided
• Explain the single advantage each finalist claims that matters most to your product, one sentence per finalist.
• Has anyone on your team proposed solving this problem internally rather than adopting an external core, and what resources did they estimate would be required?
• Suppose the incumbent offered a transition-supported roadmap today, what would you need to see to cancel the switch?

Acceptance criteria and clear decision triggers

• What single measurable pass/fail criterion will let your team move from evaluation to commercial commitment?
• Provide the evidence formats you require for acceptance, for example raw power traces, signed test reports, reproducible benchmark scripts, and bug limits. Options: Raw logs and traces, Automated regression runs, Signed acceptance form, Third-party lab report, Other
• Choose the roles that must sign acceptance and indicate the default decision owner for this program. Options: Principal engineer / architect, VP engineering, Head of procurement, Program manager, Quality manager
• Could you enter a limited-run contract contingent on a later price review if the pilot proves the metrics? Options: Yes, No, Require legal review
• Choose the earliest realistic window for delivery of an evaluation kit and initial support plan. Options: Next 2 weeks, 2–4 weeks, 1–2 months, Later than 2 months

Next steps and mutual commitments to move forward

• Indicate who we need to involve this week to either accelerate or block the project, and whether they are available for an alignment call.
• State the top three deliverables you would need from the seller to start a lab trial within four weeks.
• Pick the preferred communication cadence during integration. Options: Weekly technical sync, Biweekly, Ad hoc on demand, Monthly steering meeting
• Given a seller engineer onsite for the first two weeks, could your team commit to a milestone-driven pilot and a firm go/no-go decision date? Options: Yes, No, Need internal alignment
• Confirm the ideal kickoff window for your team. Options: Next 2 weeks, 2–4 weeks, 1–2 months, Later than 2 months

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

• Ship evaluation board with reference firmware
• Deliver production-ready board support package and drivers
• Provide compiler toolchain and build-system integration
• Port RTOS and hardware abstraction layer
• Integrate middleware libraries and BSP extensions
• Implement secure boot and cryptographic primitives
• Provide field application engineering for silicon bring-up
• Deliver reference hardware schematics and PCB layout files
• Supply NPI silicon samples and packaging options
• Deliver thermal and power characterization data
• Provide production test firmware and ATE vectors
• Issue 10-year production supply agreement and pricing
• Deliver functional-safety integration kit and artifacts
• Provide long-term BSP security maintenance and backports

Ship evaluation board with reference firmware

• 1. Provide the exact evaluation board model/identifier and serial numbers (or quantity range) you require for lab validation.
• 2. Which reference firmware image file and checksum (filename, git tag or SHA256) should be pre-flashed on each board you receive?
• 3. Specify the number of boards per destination, target delivery date, and receiving test facility names you will use for benchmark runs.
• 4. Indicate the board test connectors and measurement hooks you require for power/perf capture (shunt resistor location, sense points, JTAG pins, PMBus header).
• 5. List the benchmark workload (binary or profile name) and the minimum performance-per-watt threshold we must demonstrate on the evaluation board (include units, e.g., ops/W) for acceptance.

Deliver production-ready board support package and drivers

• 6. Provide the target BSP version identifier and source-control branch or tag you expect us to deliver.
• 7. Identify the kernel major.minor or RTOS kernel branch the BSP must support and the minimum supported patch level.
• 8. Specify the peripheral driver coverage required (list peripherals such as PCIe controller, Ethernet MAC, USB PHY, CAN controller, ADC channels) and required test vectors.
• 9. Who on your team will own BSP integration acceptance testing and what CI endpoint should we target for driver regressions (job name or repository path)?
• 10. List measurable acceptance criteria for BSP readiness (for example: driver functional test pass rate on your CI, maximum allowed open critical defects, device-tree parity checks).

Provide compiler toolchain and build-system integration

• 11. Choose the host cross-compiler category you require for reproducible builds. Options: Open-source GCC-compatible, Open-source Clang/LLVM-compatible, Commercial vendor toolchain, Other
• 12. State the exact toolchain version, ABI and any required linker script constraints (for example: gcc 10.3.0, arm-none-eabi, custom linker regions).
• 13. Identify the build-system and CI endpoints you want integrated (for example: Jenkins job name, GitHub Actions workflow, internal CI pipeline URL).
• 14. Detail reproducible-build validation you will require (artifact checksums, deterministic build flags, build recipe archive format).
• 15. Select the patch/backport cadence for toolchain security fixes you require. Options: Monthly, Quarterly, On-demand for critical fixes

Port RTOS and hardware abstraction layer

• 16. State the RTOS family and minimum kernel version you require us to port and qualify (include kernel config artifact if available).
• 17. Include the list of HAL modules to port (GPIO, timers, DMA, UART, I2C, SPI, CAN, ADC) and any custom board glue functions you rely on.
• 18. Define the real-time validation metrics you will use for the port (worst-case interrupt latency in microseconds, context switch time, ISR execution time bounds).
• 19. Attach or point to the HAL API signatures, linker symbols and config headers we must conform to for your existing firmware (repo path or file list).
• 20. What are the acceptance criteria for the RTOS port (for example: no higher-than-X% regression on worst-case latency, required certified test count passed)?

Integrate middleware libraries and BSP extensions

• 21. Name the middleware components to integrate (network stack, TLS library, file system, database, AI inference runtime) and provide repo or artifact references.
• 22. Define API compatibility requirements (for example POSIX subset, BSD sockets, lwIP API, or specific RTOS glue layer) we must preserve.
• 23. Indicate memory and storage budgets per middleware component (RAM and Flash in KB/MB) you will enforce at integration time.
• 24. Outline licensing constraints that affect middleware inclusion (per-device royalty, GPL/AGPL compatibility, permissive license needs).
• 25. Who will run middleware functional validation on target HW and what test-case or performance targets should they report (test ID list or metric thresholds)?

Implement secure boot and cryptographic primitives

• 26. Choose the secure-boot model you require (ROM root-of-trust with fixed key, chain-of-trust with signed bootloader, hardware secure element-backed boot). Options: ROM root-of-trust with signed images, Chain-of-trust with signed bootloader and firmware, Hardware secure element required, Other
• 27. Detail required cryptographic algorithms and key sizes (for example ECDSA P-256, RSA-2048, AES-256-GCM) and any compliance targets.
• 28. Outline the key provisioning workflow you expect (factory injection, on-field provisioning, HSM-based provisioning) and provide the format of key manifests.
• 29. Enumerate anti-rollback and tamper protections you require (monotonic counters, secure boot version enforcement, secure element anti-rollback flags).
• 30. Indicate attestation artifacts required in production (signed measurements, device identity certificate format, audit log schema).

Provide field application engineering for silicon bring-up

• 31. Provide the number and timezone of FAE support hours you expect and the on-call response SLA for lab support.
• 32. Specify which bring-up milestones require on-site FAE (first power-up, DDR training, thermal validation) and preferred date windows.
• 33. Report expected FAE deliverables from each session (console logs, JTAG traces, kernel oops reports, root-cause summaries).
• 34. Designate lab access and security requirements for FAEs (network VLAN access, ESD protocols, badge access) we must observe when on-site.
• 35. Schedule the knowledge-transfer workshop for your firmware team and indicate the preferred duration (half-day, full-day, multi-day). Options: Half-day, Full-day, Multi-day

Deliver reference hardware schematics and PCB layout files

• 36. Provide the PCB revision identifier and schematic sheet references you will accept for the reference design deliverable.
• 37. Select required CAD and manufacturing deliverable formats (Gerber, ODB++, native CAD source, IPC-2581). Options: Gerber, ODB++, Native CAD files, IPC-2581
• 38. Specify BOM versioning and approved component sourcing constraints for DFM review (approved manufacturer list or restrictions).
• 39. Identify critical layout constraints (impedance control, differential pair spacing, thermal vias under BGA, keepouts) that must be enforced in the PCB deliverable.
• 40. List out-of-scope items for the PCB deliverable (for example: manufacturing, panelization, supplier selection) so we can treat them as separate work.

Supply NPI silicon samples and packaging options

• 41. Provide NPI sample part numbers or wafer IDs, sample counts required per test lab, and any associated test lot identifiers.
• 42. Which package options do you require for evaluation (BGA ball count, LGA, QFN) and what thermal pad specifications must be met?
• 43. Specify expected lead times for NPI sample shipments and any expedite shipping requirements for critical path testing. Options: Standard lead time, Expedited (air), Custom agreement required
• 44. Indicate minimum sample quantities needed to complete your validation matrix (per test type: functional, thermal, reliability).
• 45. Name the electrical characterization limits you will validate on NPI samples (Vdd operating range, standby Idd, speed-grade frequency targets).

Deliver thermal and power characterization data

• 46. Provide the workload profiles and binary names we must run for thermal and power characterization (idle, 50% load, peak application workload).
• 47. Specify the measurement fixture, probe points and instrumentation you require (shunt resistor locations, power-supply rails tracked, sample rate in Hz).
• 48. State ambient and enclosure test conditions required for thermal runs (ambient °C, airflow rate, enclosure dimensions or thermal coupling to chassis).
• 49. Provide the file format and data schema you require for delivered characterization data (time-series CSV with timestamp, thermal image PNG, per-rail CSV columns).
• 50. Indicate the set of power-versus-frequency or power-versus-utilization curves you expect (for example: idle, nominal frequency, turbo frequency points) and sample granularity.

Provide production test firmware and ATE vectors

• 51. Which production-test platforms must be supported (bed-of-nails ATE, boundary-scan, functional tester) and what ATE vendor file formats are required?
• 52. Specify the test-vector file format and naming convention we must deliver for your ATE (for example vector file extension, versioning).
• 53. Indicate target test coverage metrics (for example percentage of pins exercised, functional coverage goals) and acceptable yield thresholds.
• 54. Who will integrate the ATE vectors into your factory test floor and what credentials or artifact handoff format are required for integration?
• 55. Provide burn-in, soak, or extended stress test durations and pass/fail thresholds required before parts may ship to production.

Issue 10-year production supply agreement and pricing

• 56. Provide the minimum annual volumes, pricing tiers and forecast windows you expect in the 10-year supply agreement.
• 57. Specify the lifecycle notification windows and last-time-buy lead-times you require (for example 24 months EOL notice plus 12 months last-time-buy).
• 58. Indicate whether pin-compatible silicon revisions are acceptable and list constraints on allowed die or package changes during the 10-year period.
• 59. Identify required reliability and qualification artifacts to be supplied with parts (for example PPAP submission, AEC-Q certificate, qualification test report).
• 60. Specify contractual remedies or continuity clauses you require for supply interruptions (inventory buffers, guaranteed allocation, penalty milestones).

• Master Supply and License Agreement
• Order Confirmation / Purchase Agreement
• Price and Volume Commitment Annex
• Long-Term Supply Guarantee & Capacity Allocation
• Support Service Level Agreement (SLA)
• Acceptance Test Plan and Formal Acceptance Criteria
• Intellectual Property License Schedule
• Warranty, Returns, and Liability Schedule
• Change Order Procedure
• Regulatory, Certification & Industry Compliance Addendum
• Export Controls & Trade Compliance Addendum
• Statement of Work — Engineering Support (optional)

• Go-live Health Check
• First Performance Measurement
• Supply Continuity and Support Review
• Quarterly Realization Review
• Annual Lifecycle and Enhancement Planning Review

• Publish a quarterly performance digest showing key telemetry against Solution Scope targets.
• Identify any supplier performance or forecast variances that create a risk to production or field support.
• Agree remediation or contingency steps for any SLA breaches or high-severity support items.
• Prioritize enhancement requests that materially reduce support load or certification risk.
• Update the supply forecast and document contingency sourcing options for at-risk components.
• Create action tickets for the top high-severity support incidents with planned resolution dates.
• Publish a prioritized list of enhancement requests and the acceptance criteria for each item to be addressed this quarter.
• In-field performance and power profile trends
• Verify that performance and certification metrics remain on track against the recorded targets or document required remediation.
• Agree which lifecycle tasks will be scheduled in the next quarter and their acceptance criteria.
• Confirm any required escalations for unresolved, high-risk items.
• Schedule targeted engineering sprints or certification test windows to resolve outstanding items.
• Re-confirm commitments and owners
• List escalations with escalation path and target resolution dates.
• Supply forecast, EOL and lifecycle timeline
• Approve a 12-month lifecycle roadmap with dates for silicon revisions, certification gates, and supply checkpoints.
• Reduce the count of high-priority enhancement requests older than 90 days by agreeing owners and delivery windows.
• Confirm the long-term supply contingency plan and minimum days-of-supply targets recorded in Mutual Commit are specific.
• Publish the approved 12-month lifecycle roadmap with milestone acceptance criteria and monitoring cadence.
• Define acceptance criteria and delivery dates for the top high-priority enhancement requests older than 90 days.
• Document the supply contingency plan including alternative sources and trigger thresholds for action.
• All committed deliverables have a named owner and a documented current status.
• Critical go-live blockers are identified and have defined remediation actions and target dates.
• Telemetry and logs required for root-cause analysis are collected and accessible for the next review.
• Distribute the deployed configuration and firmware inventory for all production SKUs with current status.
• Create remediation task entries for each critical blocker with expected resolution dates.
• Capture and share representative telemetry snapshots (power, boot logs, crash dumps) for follow-up analysis.
• Present measured performance-per-watt and power-profile telemetry
• Confirm whether performance-per-watt and field defect rate are within tolerance relative to targets recorded in Solution Scope, or else document the gap and required fixes.
• Confirm incumbent decommission status including archive or read-only retention and closure of fallback processes.
• Agree a remediation plan with discrete test windows and dates for re-measurement.
• Publish a remediation plan listing corrective actions, re-test dates, and criteria for closure.
• Deliver the incumbent decommission record or archive confirmation and any required access controls.
• Schedule the next measurement window and define required telemetry and test artifacts to be collected.
• Supplier delivery performance and forecast variance
• Certification and functional-safety status
• Inventory buffer and days-of-supply review
• Present field defect, crash rate, and stability data
• Deployment and migration validation
• Enhancement request backlog and prioritization
• Firmware stability and crash-rate trends
• Early telemetry and adoption signals
• Support ticket trends and SLA compliance
• Diagnose root causes for any metric gaps
• Support trend summary and resource planning
• Enhancement backlog and lifecycle task review
• Risk register and contingency planning
• Incumbent system wind-down confirmation
• Enhancement request backlog and prioritization
• Open issues and blockers
• Agree supply and support mitigation actions
• Agree remediation actions and timelines
• Decide on escalations and next monitoring steps
• Agree lifecycle milestones and monitoring cadence
• Agree immediate remediation actions