Architecture Tradeoff Matrix: Document Decisions With Rationale

Why document trade-offs

Senior engineers defend architecture choices with explicit trade-offs — not 'we always do it this way.' A tradeoff matrix makes reviews productive and onboarding faster.

[ARCH][SENIOR][UVM] tradeoff matrix template

DECISION          OPTION A          OPTION B          CHOSEN    RATIONALE
agent reuse       fork per level    one VIP           one VIP   maintenance
checking owner    block SB only     chip SB only      both      block early, chip e2e
stimulus at SoC   pin active agents SW-like vseqs     hybrid    real pins + fw boot
config path       plusargs in agt   cfg object        cfg obj   reuse API
coverage merge    per-level DB      unified chip DB   unified   closure at top

// tradeoff example: central vs distributed scoreboard
// CHOSEN: block SB at block/subsys, chip SB at SoC
// RATIONALE: block bugs caught early; chip SB checks SW-visible e2e
// COST: integration SB needed at subsys for cross-block checks

class architecture_decision_record;
  string decision_id;
  string option_a, option_b, chosen;
  string rationale;
  string owner;
  time   review_date;
endclass

Key takeaways

• Every architecture decision should cite alternatives and rationale.

• Tradeoff matrix is a living doc — update when constraints change.

• Reviewers challenge rationale, not just approve diagrams.

Common pitfalls

• Undocumented 'tribal knowledge' architecture choices.

• Tradeoff matrix written once at project start and never updated.

• Choosing flexibility over reuse without measuring maintenance cost.

Common architecture trade-offs

These trade-offs appear in every block-to-SoC project. Know the patterns and when to pick each side.

Trade-off catalog

[ARCH][SENIOR][UVM] common trade-offs

REUSE vs SPEED:
  reuse: one VIP, longer initial design
  speed: per-level rewrite, faster block bring-up, SoC debt

CHECKING LOCATION:
  block SB: fast debug, protocol proven early
  chip SB only: less TB code, block bugs escape

ACTIVE vs PASSIVE at subsystem:
  active: controllable stimulus for integration
  passive: realistic but harder to hit corners

RAL at chip:
  full RAL: SW register tests accurate
  minimal RAL: faster sim, less register coverage

• Reuse vs speed: senior projects pick reuse unless block is throwaway.

• Checking: block + integration + chip SB is standard for sign-off quality.

• Passive default at SoC unless pin-level stimulus is required.

• RAL depth scales with firmware verification responsibility.

Review meeting template

1. Present reuse ladder diagram for this project.

2. Walk tradeoff matrix row by row — justify CHOSEN column.

3. Identify risks in rejected options (what could go wrong).

4. Assign owners for cfg API, integration SB, and chip SB.

5. Record sign-off criteria per hierarchy level.

[ARCH][SENIOR][UVM] arch review sign-off

level:       subsystem
reviewers:   VIP owner, integration lead, chip TB lead
decisions:   6 rows in tradeoff matrix approved
actions:     integration_sb owner = Jane, due sprint 12
criteria:    block VIP passive smoke pass on subsys testbench

# arch validation bundle
for level in block subsys chip; do
  simv +UVM_TESTNAME=${level}_smoke_test -l ${level}_arch_smoke.log
  grep -c UVM_ERROR ${level}_arch_smoke.log
done

Key takeaways

• Rejected options and their risks belong in the matrix too.

• Architecture sign-off ties decisions to owners and criteria.

• Senior reviews end with actionable assignments, not vague approval.

Common pitfalls

• Review approves diagram without challenging CHOSEN rationale.

• No owner assigned for integration checking — gap persists to SoC.

• Arch doc frozen while design changes make passive flip impossible.