Rapid-fire questions an interviewer asks around UVM Testbench Puzzles. Answer out loud, then check yourself.
Answer: The set made from the context higher in the hierarchy wins, whatever the timing; only between sets of the same level does the later write win. So the env should not hard-set a value the test may want to change: let the env only get with a default, and the test sets.
Trap: Saying 'the last set wins' or 'the most specific pattern wins'.
Answer: Check in order: the type parameter equals the type used in set (a base set is not found by a derived get, int is not bit [31:0]); the path includes the real full name (uvm_test_top.... for a null context); the set ran before the get (the reader's phase has not passed); and the context argument of get plus its instance string.
Trap: Assuming the object's dynamic type is used for lookup.
Answer: Because nothing holds a run-phase objection while it runs: a default sequence, a sequence started with no raise, or an objection dropped early ends the phase and kills the threads. Make the owner of the activity raise and drop (for example set_automatic_phase_objection in UVM 1.2) and check in the log that the expected number of items passed.
Trap: Treating 'no errors' as success when zero transactions were compared.
Answer: build and final go parents first; connect, end_of_elaboration, start_of_simulation, extract, check and report go children first; run is concurrent. So a parent can create and configure its children in build, and a parent can rely on its children's connections being done in connect; verdicts belong in check/report, not earlier.
Trap: Believing create() runs the child's build_phase immediately.
Answer: Decide how the mirror is predicted (auto-predict only if the model is the sole master, otherwise an explicit predictor on a monitor that sees all traffic), then use front-door reads with mirror(UVM_CHECK) and use backdoor access only for setup and peeks, remembering that volatile and clear-on-read registers need front-door or directed checks.
Trap: Leaving the default (no auto-predict, no predictor) and then trusting mirror checks.
Answer: Use uvm_analysis_imp_decl to get separate write_exp/write_act methods, or use two uvm_tlm_analysis_fifos and read them in run_phase. Keep write() non-blocking; do the clocked compare in a task that pulls from the FIFOs.
Trap: Two imps of the same type calling one write(), or timing controls inside write().