Hardware-Emulation Evidence Director — Multi-Die Systems

The mandate

A multi-die programme has expanded emulation capacity, yet nightly throughput declines and failures cannot be reproduced between model partitions, acceleration modes and hardware revisions. Teams reserve platforms defensively, firmware tests bypass slow coherency paths, and performance claims use transactors that do not preserve timing or backpressure. The defined problem is to establish what the emulation estate proves, how scarce capacity is allocated and which evidence survives into silicon decisions.

The deliverables are an emulation-use-case taxonomy, model-fidelity register, partition and compile baseline, capacity allocation design, workload and transactor qualification, debug custody standard, performance-credit rules, regression portfolio, operating metrics and transfer dossier. Artefacts must bind RTL, model, compiler, platform, transactor, firmware and configuration. Every acceleration shortcut requires a declared verification limitation and alternate evidence.

Four milestones govern five months: workload, fidelity and queue baseline by 30 October 2026; approved partition, capacity and evidence model by 11 December; witnessed multi-die regression and debug pilots by 29 January 2027; and accepted operating system, client-led compile and closure review by 26 February. Milestone evidence includes failed compiles, nonreproducible bugs and capacity lost to debug capture.

Acceptance requires verification teams to reproduce seeded multi-die failures, firmware to run without undocumented bypasses, EDA operations to meet allocation and availability thresholds, and architecture to approve performance-credit limits. The sponsor returns one consolidated evidence-defect register within six working days. High utilisation cannot satisfy acceptance if queue delay, compile churn, model divergence or debug loss increases.

The client provides RTL and model revisions, emulation platforms, compiler records, queue telemetry, workload libraries, transactors, debug traces, firmware teams and authorised EDA support. It funds agreed model and capacity adjustments. The director cannot release silicon, negotiate enterprise licences, approve architectural performance claims or expose proprietary designs outside controlled environments.

Why this is external work

Verification teams and EDA operations measure success differently: one values evidence while the other sees utilisation and queue throughput. Platform vendors also have incentives to attribute failures to modelling practice or insufficient capacity. An external director can define credit and allocation neutrally, finishing when client teams reproduce the complete compile-to-debug chain.

What you will own

• Classify use cases for functional closure, firmware, coherency, error recovery, performance exploration and post-silicon preparation.
• Reconcile RTL, models, partitions, compilers, transactors, clocks, memories, firmware and platform hardware under configuration custody.
• Quantify model fidelity and acceleration limitations for timing, ordering, backpressure, analogue behaviour and external interfaces.
• Redesign capacity allocation around critical evidence, compile readiness, debug duration, regression value and fair pre-emption.
• Establish reproducible debug capture, checkpoint, replay, waveform, trace and failure-reduction paths across sites.
• Define when emulation supports architecture or performance credit and what complementary evidence remains mandatory.
• Deliver regression priorities, capacity metrics, model debts, EDA actions and client-led closure demonstrations.

Candidate qualifications

• Directed hardware emulation or acceleration for large SoCs, chiplet systems or complex processor verification programmes across distributed engineering teams.
• Can evidence a passing accelerated workload that concealed a material model or transactor fidelity gap.
• Understands emulation partitioning, compilation, transactors, clocking, debug, replay, firmware and performance limitations.
• Has governed scarce platform queues without rewarding poorly prepared reservations or sacrificing critical long-debug cases.
• Challenged EDA vendors and internal teams using reproducible configuration and failure evidence.
• Leaves client engineers able to compile, replay and defend verification credit without consultant dependency.

Non-negotiables

• Will attend San Jose, Austin and Bengaluru verification and operations sessions in the milestone plan.
• Has personally closed consequential multi-die or large-SoC defects using emulation evidence.
• Accepts milestone rejection when models, transactors or compile configuration cannot reproduce a claimed result.
• Will disclose EDA, emulation, IP, verification-services and semiconductor-client relationships before engagement.

1. 49 words maximum. Which emulation shortcut produced the most misleading passing system result?
2. 49 words maximum. How would you allocate scarce platforms between long debug and high-throughput regressions?
3. 49 words maximum. What evidence permits architecture credit from a timing-abstracted model?