Part 11 · Senior Prep · Intermediate
TLM Unconnected & Debug Interview Q&A
Model answers on unconnected port diagnostics, analysis silent drops, TLM GP debug, and systematic TLM triage.
TLM debug fundamentals
TLM debug is about connection completeness and dataflow audit — senior engineers check size() and txn counts before opening waves.
Q: Simulation runs but scoreboard empty — first TLM checks?
[INT][SENIOR][UVM] MODEL ANSWER
Q: Scoreboard empty — first TLM checks?
A:
MECHANISM: Empty scb = no write() calls reached imp. Check mon.ap.size()>0, monitor
actually sampling, connect path correct, txn type match.
MOTIVATION: 90% of empty scb is connect bug not scoreboard logic bug — verify dataflow
before debugging compare algorithm.
WHEN: Step 1: ap.size(). Step 2: uvm_info in monitor write/sample. Step 3: uvm_info
in scb write first line. Step 4: end_of_elaboration topology print.
PITFALL: Debugging compare mismatch algorithm when write() never called — hours wasted.
EXAMPLE: ap.size()==0 — env.connect forgot agt_rx.mon.ap.connect(scb.rx_imp);
fix connect, scb immediately receives txns.Q: What is uvm_tlm_gp and when do you enable it?
[INT][SENIOR][UVM] MODEL ANSWER
Q: uvm_tlm_gp debug?
A:
MECHANISM: +UVM_TLM_TRACE or UVM TLM verbosity displays connect and transaction trace
at GP (generic payload) level for TLM-2.0 style; UVM 1.x has port display.
MOTIVATION: Traces TLM connect graph and write/put/get calls — confirms data movement.
WHEN: +UVM_VERBOSITY=UVM_HIGH on TLM-related components; port.display_connections().
PITFALL: Enabling global UVM_FULL on 12-hour sim — log volume TB; scope to scb/mon.
EXAMPLE: mon.ap.display_connections() shows 0 connections — immediate root cause
without waiting for stimulus phase debug.Q: Unconnected port — compile error vs runtime silent?
[INT][SENIOR][UVM] MODEL ANSWER
Q: Unconnected — compile or runtime?
A:
MECHANISM: port.connect() to invalid target = compile error. Never calling connect
= compiles fine; analysis write at runtime silent drop. put/get block forever
or fail on first call depending on implementation.
MOTIVATION: Analysis designed for optional subscribers — no connect is valid at compile.
put/get pipelines require connect or explicit block on first use.
WHEN: Audit connect completeness in end_of_elaboration with size() checks.
PITFALL: Assuming compiler catches all TLM errors — analysis unconnected is runtime silent.
EXAMPLE: ifdef DISABLE_SCB around connect call — compiles; scb empty at runtime;
size()==0 catches ifdef mistake in end_of_elaboration.Q: Driver stuck on get_next_item — TLM or objection?
[INT][SENIOR][UVM] MODEL ANSWER
Q: Driver stuck get_next_item?
A:
MECHANISM: get_next_item blocks until sequencer provides item — stall means no sequence
running, seq_item_port not connected, or sequencer arbitration lock.
MOTIVATION: Separate from objection hang — driver blocked in run_phase but phase may
still have objections from test; display_objections + driver log together.
WHEN: Check seq_item_port connection in agent.connect. Verify sequence started on
correct sequencer. Check arbitration if multiple sequences compete.
PITFALL: Adding delay in driver — does not fix missing sequence start.
EXAMPLE: vseq started on env.v_sqr but driver on agt.sqr — seq_item_port connected
yet no items for driver; fix vseq to start agt_seq on agt.sqr.Key takeaways
Empty scoreboard: check ap.size() and write() reachability first.
Analysis unconnected = runtime silent; put/get = block or fail.
get_next_item stall: sequence start and seq_item_port connect.
Common pitfalls
Debugging compare logic when write() never called.
ifdef-gated connect causing silent analysis drop.
Systematic TLM triage
Q: Describe systematic TLM triage from symptom to root cause
[INT][SENIOR][UVM] MODEL ANSWER
Q: Systematic TLM triage?
A:
MECHANISM: Symptom classify → connection audit → producer check → consumer check →
type/path match → compare logic (last).
MOTIVATION: Ordered triage prevents premature deep debug — connection bugs dominate.
WHEN: 1) ap.size()/display_connections 2) monitor sample count 3) scb write count
4) txn type/param match 5) compare algorithm 6) waves last.
PITFALL: Waveform-first on empty scb — 2 hours before checking ap.size()==0.
EXAMPLE: Mismatch symptom: scb write count=500, exp queue=500, act queue=500 but
compare fails — NOW debug algorithm. Before write count=0: connect bug.Q: Partial connect in generate loop — common bug pattern?
[INT][SENIOR][UVM] MODEL ANSWER
Q: Generate loop partial connect?
A:
MECHANISM: foreach/agt[i] connect loop with off-by-one, wrong index, or conditional
skip leaves some agents unwired — their txns silently drop.
MOTIVATION: Multi-agent chip TBs scale connect code — loop bugs are high frequency.
WHEN: end_of_elaboration: for i assert agt[i].mon.ap.size()>0. Log connect in
env.connect with index for audit trail.
PITFALL: Connect agt[1:N] but create agt[0:N-1] — index mismatch, agt[0] unwired.
EXAMPLE: 4 agents, loop for(int i=1;i<4;i++) — agt[0] never connected; 25% traffic
missing from scb, intermittent failures on agt[0]-only scenarios.[INT][SENIOR][UVM] TLM triage checklist
[ ] mon.ap.size() > 0 (end_of_elaboration)
[ ] monitor sample count > 0 (first 100 cycles)
[ ] scb write() count > 0
[ ] exp and act queue depths track
[ ] txn type match set/get/connect
[ ] THEN compare algorithm / wavesQ: uvm_error on analysis backpressure — can you detect subscriber slowness?
[INT][SENIOR][UVM] MODEL ANSWER
Q: Detect subscriber slowness?
A:
MECHANISM: analysis_port does not report backpressure — monitor unaware subscriber slow.
Detect via scb queue depth growth, time delta between sample and compare log.
MOTIVATION: Subscriber slowness does not block monitor but causes compare lag and
potential memory growth in scb internal queues.
WHEN: Monitor scb queue depth each write; assert depth < threshold. Profile
write() compute if depth grows unbounded.
PITFALL: Adding wait in monitor to 'slow down' for scb — distorts cycle accuracy;
fix scb performance or use fifo decoupling.
EXAMPLE: scb write() O(n) search in queue — 10k txn sim, queue depth 5000, sim
slows; fix hash map compare, depth stays O(1).Q: How do you test TLM connectivity in a smoke test?
[INT][SENIOR][UVM] MODEL ANSWER
Q: TLM connectivity smoke test?
A:
MECHANISM: Directed smoke: send 1 txn, assert scb write count==1 and compare pass.
end_of_elaboration assert all ap.size()>0 before run_phase.
MOTIVATION: Cheap test catches connect regression on every CI build before random stress.
WHEN: tlm_connect_smoke_test in <10s regression: one directed txn, count audit,
no randomization dependency.
PITFALL: Only random tests in CI — connect bug may hide until specific agent index
gets traffic in unlucky seed.
EXAMPLE: Smoke sends 1 MMIO write per agent in sequence; scb assert per-agent
write count >= 1 in check_phase — connect verified for all indices.Key takeaways
TLM triage order: connect → producer count → consumer count → algorithm.
Generate loop connect: assert ap.size() per index in end_of_elaboration.
Directed TLM smoke catches connect regression before random stress.
Common pitfalls
Waveform-first triage on connection-dominated symptoms.
Slowing monitor to compensate for slow scoreboard — wrong fix.