Performance & System Level Checks

A chip can pass every functional test in the regression, boot correctly, and run its target software - and still fail in the field because a video pipeline drops frames under real traffic load, or a DMA transfer takes long enough that a real-time control loop misses its deadline. Functional correctness answers whether the design does the right thing. It says nothing about whether it does it fast enough. This article covers the system-level checks that answer that second question.

12 min read | Intermediate Level

What You'll Learn

• Why performance verification is a distinct activity from functional verification, not an extension of it
• The metrics a performance check actually measures - latency, bandwidth, and QoS behavior under contention
• How traffic is generated and ranked to stress the interconnect toward its actual limits
• Why performance verification typically runs on emulation rather than simulation
• How security gets verified as its own system-level property, separate from functional and performance correctness
• How results get correlated across simulation, emulation, and real silicon as a design moves toward tapeout

Performance Verification Is a Different Question

A functional check asks a binary question: did the DMA engine move the correct data to the correct address? A performance check asks a quantitative one: did it move that data within the latency budget the system architecture assumed it would? Both checks can run against the exact same stimulus and the exact same DUT, and a design can pass the first while failing the second.

This distinction matters because the two questions require genuinely different kinds of stimulus. Functional verification, largely covered throughout this series, is designed to exercise correctness across the legal input space - individual scenarios, one at a time, each isolated enough to have a clear pass/fail outcome. Performance verification instead needs many things happening at once, competing for the same shared resources, because latency and bandwidth are properties of contention - a single isolated transaction on an otherwise idle interconnect will almost always meet its latency budget, and that result says nothing about what happens once real workloads start competing for the same paths.

What Actually Gets Measured

Three metrics dominate most performance verification efforts:

• Latency. The time between a request being issued and the corresponding data or completion arriving - through the interconnect, across any clock domain crossings, and out through memory or an external interface. A real-time system, such as a display pipeline or a closed-loop control application, typically has a hard latency budget rather than just a "faster is better" target, and missing that budget is a functional failure from the system's point of view even though the transaction itself completed correctly.
• Bandwidth. The sustained data-transfer rate a path can actually deliver under realistic contention, not the theoretical peak rate the interface protocol allows. A memory controller and interconnect can be functionally correct and still fail to sustain the bandwidth a video or networking use case actually requires once several masters are active simultaneously.
• QoS and arbitration behavior under contention. Whether the interconnect's quality-of-service and arbitration scheme actually honors the priority a system architect intended - a high-priority display refresh shouldn't stall behind a background DMA transfer just because both happen to be active at the same time. This overlaps directly with the arbitration and QoS coverage that a functional coverage model tracks, but performance verification adds the quantitative side: not just that every arbitration outcome was exercised, but that the winning transaction's actual latency stayed inside its budget when it won under load.

Building Traffic That Actually Stresses the System

Performance verification doesn't run one test at a time - it runs a defined set of application-level use cases, each one modeling several masters generating traffic concurrently the way a real workload would, and each ranked by how much bandwidth or latency pressure it puts on the interconnect. The most demanding use cases - the ones expected to come closest to violating a latency budget or saturating a shared path - get prioritized, since those are the scenarios most likely to actually expose a problem.

Corner cases get built deliberately on top of that baseline traffic by pushing parameters toward the edges of what the system allows rather than relying on typical-case values - staggering multiple video sources onto slightly different refresh rates so their bandwidth demands overlap unpredictably, for instance, instead of assuming they'll stay conveniently out of phase. The output of a performance run is typically a pass/fail result against each interface's budget, together with a margin statistic - not just whether a path met its budget, but by how much, since a path that barely meets its bandwidth target today has far less room to absorb a workload change than one running comfortably under budget.

Why This Runs on Emulation

Performance verification needs both realistic traffic volume and cycle accuracy at the same time, and that combination is exactly where software simulation struggles. A transaction-level model can run fast enough to generate the traffic volume a performance study needs, but it isn't cycle-accurate enough to measure real latency and buffer occupancy correctly. A fully cycle-accurate RTL simulation is accurate enough, but running millions of transactions through it, the volume a meaningful bandwidth study actually requires, is far too slow to be practical.

Hardware emulation, covered on its own, is usually the platform that resolves this: it runs the actual RTL, so timing and arbitration behavior are exactly what the real design would produce, while running fast enough - commonly on the order of a hundred to several hundred times faster than software simulation - to generate the transaction volumes a real performance study needs, sometimes into the millions of transactions per run.

Security as a Third System-Level Property

Latency and bandwidth aren't the only properties that only make sense to check once the whole chip is assembled. Security is the same kind of system-level concern - a block can be functionally correct and still leak information, or fail to enforce a privilege boundary, once it's wired into a real system with real firmware running on it.

A few categories of security check show up repeatedly at this level. Information-flow tracking labels sensitive data and monitors how those labels propagate through the design, catching a case where a value that should stay confidential ends up reaching a destination it was never supposed to reach. Access-control and privilege-transition checks confirm that a peripheral or memory region only becomes reachable from the privilege level the system architecture actually intends, which ties directly back into the illegal-access negative testing covered elsewhere in this series, except tested against real firmware and a real boot flow rather than a directed testbench sequence. Fault-resilience checks evaluate whether a security-critical state transition survives a deliberately injected fault, and whether the protection mechanisms meant to catch that fault - parity, redundancy, sensors - actually do.

Like performance verification, meaningful security verification at this level generally needs long-running, realistic software stacks and enough execution depth to hit rare states - which is why it tends to land on emulation for the same reason performance work does: simulation's speed limits how deep a security campaign can actually explore before it runs out of practical time.

Correlating Results Across Platforms

A single performance number from a single platform is rarely trusted on its own - it's checked against the same measurement taken somewhere else in the flow. A common pattern is a staged approach: an early, fast software-level model checks algorithmic behavior long before RTL is ready, a cycle-accurate subsystem simulation then validates data movement and interface timing once the RTL exists, and hardware-in-the-loop testing on real hardware - an FPGA-based prototype or an early engineering sample - closes the loop by confirming the earlier stages' numbers actually hold up outside a modeled environment. Each stage is deliberately cheaper to iterate on than the one after it, so a team only pays for the most expensive, most realistic stage once the earlier ones have already caught what they can.

Once real silicon exists, that correlation continues past tapeout: a performance or power number measured on the actual chip gets compared back against what emulation predicted for the same workload. A mismatch here is worth taking seriously in both directions - it can mean the pre-silicon model missed something about real-world operating conditions, or it can mean the methodology used to build that model needs adjusting before the next project trusts its numbers the same way.

Common Mistakes