Part 10 · Advanced Topics · Intermediate

Vendor Support Reality: Building a Portable Confidence Matrix

How to validate strict/compat behavior across simulators and turn tool variability into predictable CI policy.

Portability is tested, not assumed

Every major simulator supports 1800.2-oriented flows, but defaults, switches, diagnostics, and edge-case behavior differ. Portability claims are meaningful only when validated by a matrix that controls those variables.

The matrix should separate three questions: does it compile, does it behave equivalently, and does strict mode remain clean over time.

diagram

[ADV] portability matrix dimensions

  Axis A: simulator vendor/version
  Axis B: mode (compat vs strict)
  Axis C: test slice (smoke, feature, stress)
  Axis D: seed policy (fixed replay + random sample)

  Portability confidence = stable pass + stable signature across A/B/C/D

Practical CI matrix design

Start with a minimal but informative matrix: one smoke testlist in both modes across each simulator. Expand only after signatures are stable.

diagram

[UVM] initial CI matrix example

  Lane ID    Simulator    Mode      Testlist      Seed policy     Purpose
  -------------------------------------------------------------------------------
  A1         sim_A        compat    smoke_20      fixed           baseline behavior
  A2         sim_A        strict    smoke_20      fixed           strict debt signal
  B1         sim_B        compat    smoke_20      fixed           cross-vendor baseline
  B2         sim_B        strict    smoke_20      fixed           cross-vendor strict
  C1         sim_C        strict    smoke_20      fixed           strict variance probe

bash

# Pseudocode runner
for SIM in sim_A sim_B sim_C; do
  for MODE in compat strict; do
    make sim SIM=$SIM MODE=$MODE TESTLIST=smoke_20 SEED_MODE=fixed || exit 1
  done
done

Use fixed seeds first to compare deterministic signatures.
Add random lanes only after deterministic baseline converges.
Track failures by normalized signature, not raw log text.

Mode switch governance and documentation

Vendor flags and default behaviors evolve with releases. Keep mode selection in one owned build layer rather than scattered scripts.

diagram

[ADV] build governance pattern

  tb/
    tools/
      sim_A.mk
      sim_B.mk
      sim_C.mk
    policy/
      mode_policy.mk      # maps MODE=strict|compat to each simulator switch set
    ci/
      matrix.yml          # lane definitions and required gates

diagram

[UVM] vendor support checklist

  For each simulator update:
    [ ] verify strict and compat switch mapping still valid
    [ ] rerun fixed-seed matrix, compare signature drift
    [ ] confirm log parsing still extracts report IDs and severities
    [ ] update support notes with known deltas and workarounds
    [ ] communicate lane policy changes to verification users

Release-upgrade smoke workflow

Freeze one replayable seed bundle and signature baseline.
Run both modes on old and new simulator versions.
Classify drift into parser, reporting, factory, or true functional differences.
Apply fixes in tool adapters before touching testbench logic.
Promote new simulator version only when strict lane quality is preserved.

Failure taxonomy for vendor lanes

A shared taxonomy prevents teams from arguing about ownership during bring-up. Each failure should map to exactly one primary class.

diagram

[ADV] portability failure taxonomy

  Class                       Owner             Typical action
  -------------------------------------------------------------------------------
  Build-switch mismatch       CAD/flow          fix mode mapping in build system
  Parser/signature mismatch   Infra             normalize log extraction rules
  Compatibility alias usage   TB owners         migrate code path to strict-safe API
  Factory/report semantics    TB owners         explicit configuration + tests
  Real functional divergence  DV + design       debug DUT/model behavior

Do not mix classes in one ticket; split work for parallel closure.
Track closure time per class to forecast migration runway.
Use same taxonomy in postmortems and weekly migration dashboards.

Key takeaways

Vendor portability requires explicit matrixing of simulator, mode, testlist, and seed policy.
Centralized mode governance prevents build-flag drift across teams.
Failure taxonomies convert noisy bring-up into predictable closure loops.

Common pitfalls

Treating simulator upgrades as compile-only validation tasks.
Comparing random-seed failures before fixed-seed baselines stabilize.
Allowing each project to invent incompatible strict/compat switch conventions.

Practice this lessonQuestions tagged for this topic in the bank