• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Blogs
  2. Verification
  3. Why Protocol Compliance Is Not Enough: Performance Verification…
PratikKumarGupta
PratikKumarGupta

Community Member

Blog Activity
Options
  • Subscribe by email
  • More
  • Cancel
Verification IP
AMBA Verification IP
AMBA
ATP

Why Protocol Compliance Is Not Enough: Performance Verification with ATP

12 Oct 2026 • 5 minute read

Constrained-random stimulus proves that an interconnect is functionally correct. It cannot prove that the interconnect will sustain the bandwidth of real traffic demands. Adaptive Traffic Profiles were defined to answer that second question, and Cadence Verification IP implements the model in full.

A fully passing Advanced eXtensible Interface (AXI) test suite and a system that misses its performance targets in the lab are not a contradiction. The conventional stimulus is written to exercise protocol corners, so it issues bursts as fast as the subordinate will accept. Real traffic sources behave nothing like that. A camera pipeline or a display controller produces a steady, rate-limited stream of bytes and stalls when its buffer runs out of space. A stimulus that ignores that behavior measures peak throughput on an idle fabric, which is rarely the number that decides whether a design ships.

What Adaptive Traffic Profiles Describe

Adaptive Traffic Profiles, defined by Arm as part of the AMBA specification family, take a different approach from a conventional sequence. Rather than describing individual transactions, a profile describes a traffic source or sink that sits behind a first-in, first-out (FIFO) buffer. Three parameters carry most of the meaning: the rate in bytes per clock cycle at which the buffer drains or fills, the buffer depth, and whether the buffer starts empty or full.

Traffic then generates itself from that description. A read profile models a consumer: the buffer drains at the specified rate, and a transaction is issued only when enough space exists to hold the data that will be returned. A write profile models a producer: the buffer fills at the specified rate, and a transaction is issued only once enough data has accumulated to send.

Write and Read ProfileThe rate always applies to the traffic side of the buffer; the bus drives the other side. That asymmetry is the whole model.

The word adaptive is the important one. Because the buffer level responds to the latency the design under test actually returns, a profile throttles itself when the fabric gets congested and catches up when the fabric clears. Traffic shapes itself around the design rather than being replayed blindly at it.

AMBA ATP Flow
Two loops run concurrently. The buffer fills and drains every cycle, while the issue loop consults the level before sending anything, which is where self-throttling comes from.

That property is also what makes a profile portable. Because it expresses a requirement rather than a fixed transaction list, the same description of a video pipeline holds its meaning in a block-level simulation, a full system run, an emulation platform, and a fabric that has since been reconfigured.

What the Model Demands of an Implementation

Expressing traffic this way is straightforward on paper and demanding in practice. A faithful implementation has to track buffer occupancy against in-flight data every cycle, convert a bandwidth figure into issue decisions, generate the address and identifier patterns the specification defines, honor outstanding-transaction limits, reproduce channel-level handshake timing, and do all of it without ever emitting a transaction that breaks protocol rules.

How Cadence Verification IP Delivers the Model

The Cadence Adaptive Traffic Profiles solution is built on the AMBA Verification IP, so profiles run inside a standard Universal Verification Methodology (UVM) environment and compose with existing stimulus rather than replacing it.

Coverage across the AMBA family

Profiles drive AXI, the Advanced High-performance Bus (AHB), AXI Coherency Extensions (ACE) with control over the non-shareable, inner, outer, and system coherency domains, and the Coherent Hub Interface (CHI). Protocol-independent behavior is shared, so a profile written for one protocol carries the same meaning on another. Both Manager-side and Subordinate-side traffic can be modeled.

The full pattern vocabulary

Addresses follow sequential, random, static, wrapping, or two-dimensional patterns, the last describing image-style access through an X range, a Y range, and a stride. Identifiers can be random, fixed, cycling, unique, or drawn from a supplied list, and generated addresses can be constrained to an alignment boundary.

Timing fidelity beyond the rate

Bandwidth is specified as a real number rather than a coarse approximation, outstanding transactions are capped independently, profile start can be offset, and the delay between consecutive transactions can be fixed or normally distributed around a mean. The specification's channel-level handshake delay parameters are supported under their standard names, so a timing requirement transfers directly from an architecture document into the testbench.

Protocol legality guaranteed

Bursts generated from a bandwidth figure are automatically split at the AXI 4KB boundary and the AHB 1KB boundary, and unaligned transfers are handled. A performance requirement cannot accidentally become a protocol violation.

Measurement built in

Every profile tracks the minimum and maximum levels its buffer reached, reports them per burst and per profile, and raises a warning whenever the buffer touches empty or full. The performance result is an output of the run, not something that has to be reconstructed afterward from a waveform.

Repeatable, trace-driven traffic

Addresses, identifiers, and data content can be supplied from plain text files in decimal or hexadecimal, so an address trace captured from software or a previous run can be replayed exactly. Files are shared across profiles and cycle automatically when shorter than the profile requires.
Because profiles are ordinary UVM sequences, many can run concurrently and compete for the same fabric. That is where results get interesting: a profile that comfortably meets its rate in isolation and starves once its neighbors become active is precisely the finding worth having before tapeout.

Seeing the Result

FIFO level vs read latency
A read profile requesting three bytes per cycle. The buffer holds near 900 bytes while read latency is 30 cycles, drains once latency rises to 420, and then starves for 351 cycles, continuing for 252 cycles after the congestion itself has cleared. A buffer that reaches empty once the profile is running is the failure signature.

The reported buffer levels answer the original question. A read profile whose minimum level stays well clear of zero was served comfortably throughout. One that reaches empty indicates a design that could not meet its own requirement, and the margin between that minimum and the buffer depth quantifies the headroom left for the next derivative. A bandwidth number stops being a spreadsheet entry and becomes a simulation result with a pass or fail attached.

Learn More

Performance questions are easier to answer early, while the fabric can still change. Full details of Adaptive Traffic Profiles support, including the complete parameter set and supported protocols, are available through the Cadence AMBA Verification IP documentation.

© 2026 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information