In reply to ben@SystemVerilog.us:
Thanks so much for your answers! I have added clocking blocks and that solves the problem.
For the big_driver/ big_ifc example, the variable x is not driven through a clocking block. However, I omitted the run phase which has a case statement to call the different tasks based on the command in the transaction.
virtual task run_phase(uvm_phase phase);
forever begin
// Grab the next sequence item to process
`uvm_info(tID, "Waiting for next item to process", UVM_DEBUG)
seq_item_port.get_next_item(req);
$cast(rsp, req.clone());
rsp.set_id_info(req);
id = rsp.get_transaction_id();
`uvm_info(tID, $sformatf("Trans (%0d): Starting\n%s", id, rsp.sprint()), UVM_DEBUG)
// Record the transaction
void'(begin_tr(rsp));
// Now call the correct task/function based on the command
case (req.command)
big_command::DEFAULT_INPUTS : setDefaultInputs(); // Set the default input values for our pins
big_command::SET_ALL_X_HIGH : set_all_x_high();
default : `uvm_error(tID, $sformatf("Trans (%0d) : Currently don't know how to implement the request", id))
endcase
// Done with this transaction
`uvm_info(tID, $sformatf("Trans (%0d) : Finished with transaction", id), UVM_DEBUG)
end_tr(rsp);
seq_item_port.item_done();
end
endtask : run_phase
Does this count as a “procedural means to drive a net through a virtual interface”? The small example and the big testbench have the same simulator, so there must be something in my omitted code that causes the difference.
Regardless, my problem is solved. Thanks for the help!