RISC-V Safety-Verification Evidence Director — Automotive Semiconductors

The mandate

An automotive processor programme has extended a RISC-V core with proprietary vector, diagnostic and real-time features, but requirements, assertions, coverage and safety claims no longer share a stable configuration baseline. Random simulation reports closure while formal analysis finds unreachable safety states, and fault campaigns cannot distinguish architectural protection from testbench assumptions. The defined problem is to create reviewable evidence that the implemented core behaves safely under specified faults and privilege interactions.

The deliverables are a configuration-controlled verification plan, extension requirement trace, formal proof strategy, coverage-closure argument, fault-injection model, privilege and interrupt stress suite, safety-mechanism effectiveness report and independent-assessment dossier. Artefacts must bind core revision, parameters, tool versions and assumptions. The engagement will expose genuinely unverified behaviour instead of converting waived properties or unreachable cover points into cosmetic closure.

Four milestones govern six months: verification and safety-gap baseline by 30 October 2026; approved proof decomposition, reference models and fault taxonomy by 18 December; witnessed closure on priority custom extensions and safety mechanisms by 12 February 2027; and accepted dossier, assessor responses and client-led rerun by 31 March. Each milestone includes executable evidence against the declared RTL configuration.

Acceptance requires architecture to approve intended behaviour, verification to reproduce proofs and simulations, safety engineering to trace diagnostic coverage to hazards, and the independent assessor to close all major evidence defects. The sponsor responds with one consolidated variance list within six working days. Coverage percentage alone cannot satisfy acceptance when exclusions, constraints or reference-model agreement remain unexplained.

The client provides controlled RTL, architectural specifications, safety goals, verification environments, emulation capacity, tool licences, fault lists, software tests and named assessor access. It resolves configuration questions within two working days and funds approved compute expansion. The director cannot sign the safety case, approve silicon release, redefine vehicle hazards or disclose proprietary instruction extensions outside authorised environments.

Why this is external work

The teams who created the extensions and test environments also own the assumptions now under challenge. An external verification director can reconcile formal, simulation, emulation and safety evidence without protecting a particular methodology’s closure claim. The work ends when executable proof and fault results are accepted and the internal team can rerun the argument unaided.

What you will own

• Reconcile architectural intent, custom-extension specifications, RTL parameters, reference models and safety requirements under one controlled baseline.
• Partition formal proofs, constrained-random simulation, emulation and software tests by reachable risk and methodological strength.
• Challenge assumptions, waivers, abstractions and unreachable states that could make a property pass without representing implemented behaviour.
• Direct privilege, interrupt, debug, memory-ordering and exception scenarios where custom extensions interact with standard architectural guarantees.
• Build fault campaigns covering latent combinations, diagnostic timing, common-cause assumptions and measurable safety-mechanism effectiveness.
• Convert code and functional coverage into an argued closure position tied to safety relevance, not dashboard completeness.
• Deliver assessor-ready evidence, unresolved limitations, regression ownership and a witnessed internal rerun of priority claims.

Candidate qualifications

• Directed verification closure for complex CPU, automotive SoC or safety-relevant programmable processor designs.
• Can evidence a formal assumption or coverage waiver that concealed material implemented behaviour before tape-out.
• Understands RISC-V privilege, interrupts, memory ordering, debug, custom extensions, formal methods and fault injection.
• Has integrated simulation, emulation, software validation and safety analysis without allowing tool metrics to substitute for argument.
• Worked directly with independent functional-safety assessors while preserving engineering ownership of executable evidence.
• Leaves reusable proof and regression capability rather than a consultant-controlled dossier that cannot survive RTL change.

Non-negotiables

• Will work in Bengaluru and attend the scheduled Chennai and Munich assessment sessions.
• Has personally closed verification on a production processor with proprietary extensions and safety mechanisms.
• Accepts milestone rejection if evidence depends on undocumented constraints, waivers or mismatched RTL configuration.
• Will disclose IP-core, EDA, automotive semiconductor and independent-assessment relationships before mobilisation.

1. 49 words maximum. Which verification assumption produced your most misleading proof or coverage result?
2. 49 words maximum. How would you connect injected faults to architectural behaviour and a vehicle safety claim?
3. 49 words maximum. What evidence must remain executable after the next custom-extension RTL change?