Part 6 · Agents & Protocol IP · Intermediate

Protocol Comparison Table: Choosing the Right Agent Architecture

Side-by-side APB, AXI, and streaming pattern comparison across complexity, ordering, buffering, monitor design, and debug surfaces.

Why compare explicitly

Teams often overgeneralize one protocol experience into another. A structured comparison helps pick architecture and qualification strategy before implementation drift begins.

Use this table as a design kickoff aid and as a review artifact for new VIP developments.

diagram

[VIP][AGT] high-level comparison

dimension                 APB                    AXI                        STREAM
----------------------------------------------------------------------------------------
channels                  1 request path         5 decoupled channels       1 data flow
ordering                  mostly serialized      may be out-of-order        sequence by beat/frame
state complexity          low                    high                        medium
driver architecture       simple FSM             multi-thread/channel        handshake loop + framing
monitor architecture      phase merge            channel correlator          beat-to-packet assembler
primary risk              timing phase errors    ID/order correlation bugs   stall/framing bugs

diagram

[UVM] decision heuristic

if control register bus:
  APB-like pattern

if memory/interconnect data fabric:
  AXI-like pattern

if unidirectional throughput pipeline:
  streaming pattern

Compare architecture choices using protocol behavior, not naming similarity.
Primary risk areas differ significantly by protocol family.
Qualification plans should mirror protocol complexity profile.

Comparison dimensions in depth

Beyond channels and ordering, compare reset behavior, checker strategy, coverage model, and debugging observability requirements.

diagram

[VIP] detailed dimension table

dimension                  APB                       AXI                          STREAM
----------------------------------------------------------------------------------------------
reset handling             transaction abort simple  per-channel recovery needed  packet flush policy
backpressure focus         moderate                  high (per channel)           very high
outstanding tracking       minimal                   mandatory                    optional (pipeline depth)
item schema size           compact                   large metadata-rich          packet/beat arrays
checker complexity         low-medium                high                         medium
coverage focus             addr/rw/resp bins         burst/id/order/interleave    size/stall/utilization

diagram

[DEBUG] instrumentation priority

APB:
  setup/access state trace

AXI:
  per-channel timeline + ID tracker dumps

STREAM:
  stall counters + frame boundary logs

diagram

[CI] regression profile by protocol

APB:
  broad directed + light random stress

AXI:
  heavy random + concurrency stress + long runs

STREAM:
  throughput/backpressure sweep + framing stress

Match checker and coverage complexity to protocol concurrency level.
Instrument debug based on each protocol's dominant failure surface.
Allocate CI budget proportionally to protocol risk profile.

Choosing reusable abstractions

Not all code should be shared across protocol families. Share wrapper and tooling patterns; keep protocol engines independent.

diagram

[AGT] share vs specialize

good to share:
  cfg validation utilities
  mode switching framework
  logging conventions
  release/testing scaffolding

must specialize:
  driver timing engines
  monitor reconstruction logic
  transaction schemas
  protocol checkers

diagram

[VIP] layered architecture

layer 1: common infrastructure (factory, cfg base, reporting)
layer 2: protocol-specific item/driver/monitor/checkers
layer 3: env-specific adapters and scoreboards

this keeps reuse high without correctness compromise

diagram

[SOC] integration planning question set

1) which interfaces map to which protocol family?
2) where is active ownership needed vs passive observation?
3) what checker depth is required per interface criticality?
4) what CI runtime budget exists per protocol class?

Share infrastructure patterns, not protocol semantics.
Layer architecture to keep specialization boundaries clear.
Use planning questions early to avoid late integration churn.

Comparison-driven review checklist

Before implementation sign-off, run a comparison-driven review to ensure architecture choices align with target protocol needs.

diagram

[REVIEW] pre-implementation checklist

[ ] protocol channel model captured correctly
[ ] ordering assumptions explicitly documented
[ ] item schema includes all mandatory semantics
[ ] driver concurrency model matches protocol needs
[ ] monitor correlation/framing logic defined
[ ] debug instrumentation plan protocol-specific
[ ] qualification suite scope aligned with complexity

diagram

[VIP][AGT] design review anti-patterns

anti-pattern:
  "AXI is just APB with more signals"

anti-pattern:
  "One generic item for all protocols"

anti-pattern:
  "Single smoke test proves all protocol variants"

diagram

[DOC] comparison artifact usage

store the comparison table with:
  architecture decision records
  VIP onboarding docs
  release qualification rationale

update when protocol support scope evolves

Key takeaways

Structured comparison prevents protocol-pattern misapplication.
Share reusable scaffolding while specializing protocol engines.
Protocol complexity should drive debug and CI strategy depth.
Comparison checklists improve design review quality and consistency.

Common pitfalls

Forcing one protocol implementation style across all bus families.
Ignoring ordering/correlation demands in complex protocols.
Under-scoping qualification for high-concurrency protocols.
Failing to refresh comparison docs as VIP scope changes.

Practice this lessonQuestions tagged for this topic in the bank