Phase Domains & Sync Interview Q&A

[INT][SENIOR][UVM] MODEL ANSWER

Q: What is a phase domain?

A:
  MECHANISM:  Independent phase scheduler — components assigned to a domain run their
              task phases on that domain's timeline, not the default uvm domain.
  MOTIVATION:  Power domains, async clock blocks, or SW co-simulation need separate
              reset/configure/main without blocking the entire testbench.
  WHEN:       Multi-power SoC, UVM-DPI SW scheduler, TB with physically independent
              subsystems that reset at different real times.
  PITFALL:    Using domains to fix connect/build ordering bugs — domains solve temporal
              independence, not structural wiring mistakes.
  EXAMPLE:    AXI domain runs main while APB domain still in reset_phase — coordinated
              by explicit sync event, not shared objections across domains.

[INT][SENIOR][UVM] MODEL ANSWER

Q: Assign component to domain?

A:
  MECHANISM:  uvm_domain::get("domain_name") returns domain handle; component's phase
              nodes re-parent via set_domain or domain assignment at build/elaboration.
  MOTIVATION:  Domain membership determines which scheduler executes component's
              run_phase and sub-phases — must be set before phase execution begins.
  WHEN:       Set during build_phase or end_of_elaboration after hierarchy complete.
              Common pattern: env assigns each power island agent group to its domain.
  PITFALL:    Assigning domain after run_phase started — component already on wrong
              schedule, partial phase execution in mixed state.
  EXAMPLE:    env.build creates pd_axi_domain and pd_apb_domain; assigns agt_axi to
              axi domain, agt_apb to apb domain before start_of_simulation.

[INT][SENIOR][UVM] MODEL ANSWER

Q: Objections across domains?

A:
  MECHANISM:  Objections are per-phase-per-domain — raise in domain A does not block
              phase completion in domain B.
  MOTIVATION:  Domains exist for independence — shared objections would re-couple
              schedules and defeat the purpose.
  WHEN:       Use explicit sync barriers (uvm_event, uvm_barrier, custom phase jump)
              for cross-domain coordination instead of shared objections.
  PITFALL:    Expecting test run_phase objection to hold all domains — test is in
              default domain; PD domain main_phase proceeds independently.
  EXAMPLE:    Sync barrier: APB domain waits on axi_domain_main_done event before
              entering main_phase — explicit handshake, not objection sharing.

[INT][SENIOR][UVM] MODEL ANSWER

Q: When NOT use domains?

A:
  MECHANISM:  Single default domain runs all components on one schedule — simpler
              objection model, easier debug, less sync infrastructure.
  MOTIVATION:  Domains add coordination cost — every cross-domain interaction needs
              explicit sync; debug requires multi-scheduler reasoning.
  WHEN:       Single clock/reset block TB, single power domain, no SW co-simulation.
              Use sub-phases in default domain instead.
  PITFALL:    Adding domains preemptively 'for flexibility' — team spends weeks on
              sync bugs that sub-phases would have handled.
  EXAMPLE:    Single AXI block VIP TB stays default domain; chip with 3 power islands
              adds domains only after block TBs integrate unchanged.

[INT][SENIOR][UVM] MODEL ANSWER

Q: Sync two domains before main?

A:
  MECHANISM:  uvm_barrier with N waiters — each domain's pre_main_phase waits on
              barrier; last arrival releases all to main_phase together.
  MOTIVATION:  Chip-level tests need all power domains out of reset before system
              traffic — barrier provides deterministic rendezvous.
  WHEN:       Multi-PD bring-up, CPU subsystem + peripheral subsystem coordinated start.
  PITFALL:    Wrong waiter count — barrier never releases (hang) or releases early
              (one domain still in reset during traffic).
  PITFALL:    Using fixed #delay instead of barrier — non-deterministic across seeds.
  EXAMPLE:    3 domains, uvm_barrier(3): each post_reset_phase waits; all enter
              main_phase same cycle after last PD reports clock stable.

[INT][SENIOR][UVM] MODEL ANSWER

Q: Domains with SW co-simulation?

A:
  MECHANISM:  SW domain runs on DPI-driven scheduler — C code advances SW phase
              nodes while HW domain runs on SV simulation time.
  MOTIVATION:  Firmware boot and HW reset occur on different timelines — coupling
              them in one domain causes SW to run before HW reset completes.
  WHEN:       UVM-DPI testbenches with embedded CPU model or virtual platform sync.
  PITFALL:    Calling DPI from every cycle without phase domain — SW races ahead of
              HW reset, reads garbage CSRs, debug nightmare.
  EXAMPLE:    HW domain: reset_phase deasserts rst_n. SW domain: main_phase starts
              firmware only after hw_ready uvm_event triggered from post_reset_phase.

[INT][SENIOR][UVM] multi-domain whiteboard

  Domain A (AXI PD):  reset → configure → [barrier] → main
  Domain B (APB PD):  reset → configure → [barrier] → main
  Domain C (SW):      idle   → idle      → [barrier] → main (DPI)

  barrier in pre_main_phase — NOT shared objections

[INT][SENIOR][UVM] MODEL ANSWER

Q: Debug domain hangs?

A:
  MECHANISM:  Each domain has independent phase state — display_objections per domain,
              print domain phase state via uvm_domain API and phase trace.
  MOTIVATION:  Domain hang often means barrier mismatch or one domain stuck in reset
              while others wait at pre_main forever.
  WHEN:       Enable UVM_PHASE_TRACE; check barrier waiter count; verify each domain's
              reset_phase completed.
  PITFALL:    Debugging only default domain objections while PD domain stuck — miss
              half the schedule.
  EXAMPLE:    Barrier set to 3 waiters but only 2 domains registered — third wait
              never arrives, pre_main hangs indefinitely.