Part 11 · Senior Prep · Intermediate

Interview Q&A: VIP Packaging

Model answers on reusable VIP structure, config objects, sequence libraries, stable public API, documentation, and version discipline.

VIP structure and API

Q: How do you structure a reusable VIP?

diagram
[INT][SENIOR][UVM] MODEL ANSWER

Q: Reusable VIP structure?

A:
  MECHANISM:  Package exports: agent, cfg object, seq_lib, txn types, optional coverage.
              Internals (driver, monitor impl) local or protected — not in integration guide.
  MOTIVATION:  Integrators configure and connect — never edit VIP internals per project.
  WHEN:       Any interface reused blockchip or across projects.
  PITFALL:    Exposing agt.drv or agt.mon handles — coupling to implementation.
  EXAMPLE:    axi_vip_pkg: axi_agent, axi_cfg, axi_seq_lib::*, axi_txn — hide drv/mon.

Q: What belongs in the VIP config object?

diagram
[INT][SENIOR][UVM] MODEL ANSWER

Q: VIP config object contents?

A:
  MECHANISM:  is_active, timing knobs (ready delay ranges), protocol variant flags,
              checker/coverage enables, address map hints if applicable.
  MOTIVATION:  All integrator-tunable params in one typed object via config_db.
  WHEN:       Every VIP — cfg rand or directed set in test, get in agent build.
  PITFALL:    Scatter of individual int config_db fields — untyped, hard to audit.
  EXAMPLE:    axi_cfg: is_active, id_width, enable_cov, max_outstanding — one set/get.

Q: What is the public API integrators should use?

diagram
[INT][SENIOR][UVM] MODEL ANSWER

Q: VIP public API?

A:
  MECHANISM:  cfg via config_db; sequences via seq_lib or documented seq types;
              observation via agt.ap analysis_port; optional cov enable flag.
  MOTIVATION:  Stable API survives VIP internal refactors — integrator code unchanged.
  WHEN:       Document in integration guide: 'connect agt.ap to scb; start axi_wr_seq'.
  PITFALL:    Integration guide says 'edit driver delay in line 847' — not a VIP.
  EXAMPLE:    Integrator never imports axi_driver; starts axi_rand_seq on agt.sequencer.
diagram
[INT][SENIOR][UVM] VIP API box (whiteboard)

  INTEGRATOR SEES:
    axi_cfg (config_db)
    axi_agent (hierarchy leaf)
    axi_seq_lib / scenario sequences
    agt.ap  env subscribers

  INTEGRATOR DOES NOT SEE:
    axi_driver internals, monitor sampling details

Key takeaways

  • VIP = pkg with agent + cfg + seq_lib + txn — hide drv/mon.

  • Config object consolidates all integrator knobs.

  • Public API: cfg, seq, ap — document and freeze across releases.

Common pitfalls

  • Exposing driver for 'quick hack' — forks VIP per project.

  • Undocumented config fields — integrators guess wrong defaults.


Maintenance and integration

Q: How do you version and maintain a VIP across projects?

diagram
[INT][SENIOR][UVM] MODEL ANSWER

Q: VIP versioning?

A:
  MECHANISM:  Semantic versioning on package; changelog for API breaks; regression
              suite inside VIP repo; integrators pin version in manifest.
  MOTIVATION:  Silent behavior change in monitor breaks chip scb — version discipline required.
  WHEN:       Central VIP team serves multiple chip projects.
  PITFALL:    Per-project fork of VIP — divergence, double maintenance, bug reintroduction.
  EXAMPLE:    axi_vip 2.1.0  2.2.0 adds cfg field with default — backward compatible.

Q: Factory overrides in VIP context?

diagram
[INT][SENIOR][UVM] MODEL ANSWER

Q: Factory override on VIP components?

A:
  MECHANISM:  Test set_type_override on driver or seq type before env.build — VIP
              create() picks substituted type without VIP source edit.
  MOTIVATION:  Error injection, debug driver, enhanced monitor — test-time only.
  WHEN:       err_test overrides axi_driver  axi_err_driver; VIP unchanged.
  PITFALL:    Override path typo — silent no-match, test thinks err injected but is not.
  EXAMPLE:    set_type_override(axi_driver::get_type(), axi_err_driver::get_type()) in test.

Q: VIP with RAL — how packaged?

diagram
[INT][SENIOR][UVM] MODEL ANSWER

Q: VIP + RAL packaging?

A:
  MECHANISM:  regmodel often separate from agent VIP; adapter bridges agent bus txn
              to reg access; integrator connects predictor to mon.ap.
  MOTIVATION:  Not all integrators use RAL — agent VIP usable without regmodel.
  WHEN:       Optional regmodel pkg layer; adapter as separate connectable component.
  PITFALL:    Hard-wiring RAL inside agent — forces RAL on all users.
  EXAMPLE:    axi_vip standalone; axi_regmodel_pkg + axi_reg_adapter optional add-on.

Q: How do you document VIP integration for junior integrators?

diagram
[INT][SENIOR][UVM] MODEL ANSWER

Q: VIP integration documentation?

A:
  MECHANISM:  Minimal working example: top vif bind, cfg set, env instantiate agent,
              connect ap, one seq.start — copy-paste bring-up under 50 lines.
  MOTIVATION:  Integration friction kills VIP adoption — docs are part of architecture.
  WHEN:       Every VIP release ships quickstart + cfg field reference table.
  PITFALL:    Docs reference internal hierarchy paths — break on refactor.
  EXAMPLE:    Quickstart uses only public API names — agt.ap, axi_cfg, base_wr_seq.

Key takeaways

  • Version VIP; avoid per-project forks — central maintenance wins.

  • Factory override for test-time variants without VIP edits.

  • RAL optional layer — agent VIP standalone usable.

Common pitfalls

  • Hard-coding RAL in agent — forces unnecessary dependency.

  • Integration docs exposing internal paths — API instability.