I am running a UVM testcase having AXI Driver(as one of the interface) to the Memory Control and on the other side is the Memory Block. But when i am running a simple WRITE sequence, the testcase got hanged (means its not coming out).
The last message what i am getting in the log file (I enabled UVM_OBJECTION_TRACE)::
UVM_INFO @ 0: run [OBJTN_TRC] Object uvm_test_top subtracted 1 objection(s)its total(dropped from source object uvm_test_top.tb.v_seqr.simple_vseq): count=0 total=0.
UVM_INFO …/base/uvm_objection.svh(1120) @ 0:reporter [TEST_DONE] 'run’phase is ready to proceed to the ‘extract’ phase
My basic code is something like this::
class simple_vtest extends uvm_test
…
function build_phase(uvm_phase phase)
uvm_config_wrapper::set(this,“env.v_seqr.run_phase”,“default_sequence”,simple_vseq::type_id::get());
super.build_phase(phase);
endfunction
Are you aware in which conditions pre/post_body are called or not called? We generally do not recommend using them because are not aware of the different situations.
Do you have a typo in your source code, or is it just in your post - bosy() should be body().
Hi Dave,
Thanks for the reply. bosy() its just a typing mistake.
So if i don’t want to use pre/post_body for objection raise and drop then what i suppose to use?
I also tried fork join_any to come out from the sequence but still getting the same result.
…
virtual task body();
starting_phase.raise_objection(this,get_type_name());
fork
begin
`uvm_do_on(veq_b,p_sequencer.axi_seqr)
end
begin #1000;
end
join_any
disable fork;
starting_phase.drop_objection(this,get_type_name());
endtask
…
Can you please tell me how to use the debugger or please share any link for this.
What the trace is telling you is that for some reason the body() task is completing in zero time and the post_body() task is dropping the objection leading to the end of the run_phase(). The UVM simulation then terminates.
Therefore you need to look at what is going on in the write_seq and/or the driver. Is there something happening that causes the body() method in write_seq to return in 0 time? Is it something like the driver doing a get(), and the write_seq only sending a single write sequence_item? If this is the case you would get this type of behaviour.
Something you could try is raising an objection in the run_phase of the test, or another component, to extend the run_phase, this will allow you to see whether your driver is actually doing anything. (Your initial block is outside the UVM and will have no effect).
I am seeing a similar issue…my build and connect phases are done…simulation enters run phase and hangs at time 0…Could you figure out what caused your simulation to hang?
There may be few possibilities but the important one is may be some thing (process) is running in background, That the same with me.Please check the loops in your code as may be some loops are going in infinite condition or its waiting for some signals or values.
I’m facing the similar issue, forever loops in the monitor are running even after dropping all the objections (enabled objection trace). How to end the testcase, in this case? Can’t we control this using objection mechanism only ?
For debugging, try changing your monitor’s forever loop to break out after some timeout, or by checking some variable that you interactively set when you notice the simulation not ending. Then see what the remaining activity in the testbench is doing.
Thanks Dave,
I found that objection is raised in main_phase of driver, but in run_phase all the objections are dropped. So the main_phase in env is not completed.
Hard to know without seeing your code. But this is why we recommend sticking with the run_phase, especially in your driver. Also, you driver should not be raising and dropping objections.
In my case, all phases were ending and reporting was run, but the sim never stopped. What? Why?
So I finally looked at uvm_root:
class uvm_root extends uvm_component;
// Task: run_test
//
// Phases all components through all registered phases. If the optional
// test_name argument is provided, or if a command-line plusarg,
// +UVM_TESTNAME=TEST_NAME, is found, then the specified component is created
// just prior to phasing. The test may contain new verification components or
// the entire testbench, in which case the test and testbench can be chosen from
// the command line without forcing recompilation. If the global (package)
// variable, finish_on_completion, is set, then $finish is called after
// phasing completes.
. . .
// Variable: finish_on_completion
//
// If set, then run_test will call $finish after all phases are executed.
bit finish_on_completion = 1;
. . .
task uvm_root::run_test(string test_name=“”);
. . .
// if test now defined, create it using common factory
if (test_name != “”) begin
$cast(uvm_test_top, factory.create_component_by_name(test_name,
“”, “uvm_test_top”, null));
. . .
// phase runner, isolated from calling process
fork begin
// spawn the phase runner task
phase_runner_proc = process::self();
uvm_phase::m_run_phases();
end
join_none #0; // let the phase runner start
. . .
wait (m_phase_all_done == 1);
// clean up after ourselves
phase_runner_proc.kill();
I was trying to bring up a BFM only full chip TB (CPUs stubbed out). The Top TB had this code, so UVM wouldn’t finish before the C tests:
uvm_top.finish_on_completion=0;
Solution: In full chip tests (non-BFM), C tests now write to a GPIO pin when they are finished. A UVM monitor waits for write and drops an objection, allowing UVM to finish. C tests no longer need a cycle count arg and finish_on_completion gets axed!!!