An ADAS SoC processes camera, radar, and lidar streams every frame. Each sensor lands at a different rate, with different latency, into different memory regions. A fusion engine reconciles them into a scene, hands it to a perception network, and the network outputs decisions the vehicle acts on. Sixteen milliseconds. Repeat.
None of that fits inside a block-level testbench. You can UVM the camera pipeline to a hundred percent coverage and still ship a bug that only surfaces when the camera, radar, and lidar interleave under load.
This note is about the class of bugs full-SoC verification is designed to catch. And why sensor fusion is the workload we anchor our testbenches to.
What block-level testing misses
Block-level UVM is good at what it does. It stresses a block against its interface contract. It hits corner cases the designer thought of. It runs coverage until the bins fill.
What it cannot do:
- Reproduce contention between the memory arbiter, the fusion DMA, and the CNN accelerator all pulling from the same DRAM channel at frame rate.
- Exercise the case where camera frame N and lidar sweep N+1 arrive out of order because of an interconnect stall three cycles deep.
- Catch a fusion engine that emits stale timestamps because the M-core interrupt latency stretched past the frame boundary during a firmware update window.
None of those bugs live inside a single block. All of them ship in silicon.
What the ADAS workload actually looks like
At every frame, the following sequence unfolds across the SoC:
- Camera pipeline lands raw frame data in DRAM through MIPI-CSI.
- Radar block streams range-doppler tensors from its own memory into shared DDR.
- Lidar block writes a point cloud into a mapped buffer.
- RISC-V M-core signals fusion ready.
- Fusion engine reads all three, aligns timestamps, projects into a common frame, writes a scene tensor.
- CNN accelerator consumes the scene tensor, runs perception, writes output boxes.
- RISC-V A-core acts on the boxes.
- Sixteen milliseconds elapsed. Everything happens again.
Every step is a synchronization event. Every synchronization event is a race condition waiting to break. Block-level testbenches do not see any of it.
Sensor fusion, the crown jewel
Sensor fusion is where the design either delivers or does not. Every other block feeds into it. Every downstream block depends on it. When it works, the CNN sees a consistent scene. When it does not, the network trains on ground truth and infers on garbage.
Our full-SoC testbench executes real sensor VIPs (camera, radar, lidar, ultrasonic) into a real RISC-V multicore setup running real M-core and A-core firmware. The fusion engine runs against actual timestamped streams, not synthetic drops. Coverage bins are anchored to fusion outputs, not sub-block state.
That is what workload-anchored coverage means. Coverage is only useful if it correlates with a functional outcome the customer cares about. For ADAS, that outcome is fused scene quality, frame after frame, across the environment envelope the vehicle will see.
The classes of bugs this surfaces
A few concrete classes of bug that only surface in full-SoC TB:
Timestamp drift under contention
The fusion engine assumes camera and radar timestamps arrive within a bounded window. Under memory pressure, the radar DMA finishes late and its timestamp shifts. The fusion output is off by one frame. The CNN infers correctly on the wrong scene. In a controlled lab this is invisible. On a highway it can be catastrophic.
M-core interrupt latency stretch
The M-core services the fusion-ready interrupt on its normal ISR path. Under a spike in system activity (a diagnostic sweep, an over-the-air firmware check, a safety event on another core), the ISR is delayed past the next frame boundary. The next fusion runs on stale data. Then the frame after recovers. Then it happens again ten minutes later.
Coherency window edge case
The A-core reads a fusion output while the fusion engine is still writing it. The cache coherency protocol handles it correctly for most access patterns, but a specific size and alignment combination bypasses the coherency window. The A-core reads half-old, half-new data. Once every ten thousand frames. Deterministic given the trigger. Impossible to hit at block level.
None of these bugs live in a single block. All of them ship if you do not verify at the workload level.
Coverage that matters
We bin coverage against outcomes, not registers:
- Fusion output correctness across full frame sequences (thousands of frames, not tens).
- Timestamp reconciliation edge cases: frame skew, drop, reorder.
- Memory contention under mixed sensor and accelerator load.
- Safety-critical corner cases: fusion under M-core fault, S-core takeover, watchdog trigger during scene handoff.
Coverage that never fills those bins is not signoff-ready coverage, regardless of what a block-level report shows in green.
The takeaway
Block-level UVM is necessary. It is not sufficient. For automotive, the sufficient part is running the actual workload against actual RISC-V multicore firmware with actual sensor VIPs feeding actual fusion RTL. Coverage anchored to the outcome the customer will judge in the field.
That is the testbench that catches the bug that would have shipped.