Issue on Reporting mechanism

UVM
, ,
1

I am developing a test bench which contains 2 BFMs (apart from driver) instantiated in env class. It takes transactions from driver class modify them before driving it to DUT(Though not a standard mechanism, it’s required for my use case)
I have extended the BFM class from uvm_component.
Now I observe the reporting mechanism like this.

UVM_INFO lbc_bfm.sv(78) @ 0: uvm_test_top.BIST_ENV.LBC_BFM [uvm_test_top.BIST_ENV.LBC_BFM] RESET : Entered into reset phase for CBC
UVM_INFO lbc_bfm.sv(101) @ 0: uvm_test_top.BIST_ENV.LBC_BFM [uvm_test_top.BIST_ENV.LBC_BFM] Detceted reset
UVM_INFO test_library.svh(61) @ 0: uvm_test_top [uvm_test_top] Running RESET TEST
UVM_INFO lbc_bfm.sv(87) @ 18000: uvm_test_top.BIST_ENV.LBC_BFM [uvm_test_top.BIST_ENV.LBC_BFM] RESET : Reset deasserted for DUT
UVM_INFO test_library.svh(67) @ 50000: uvm_test_top [uvm_test_top] ------------------ SIMULATION ENDED at 50000 -----------------------------------

Normally we expect uvm_test_top class messages to printed first. But here BFMs(uvm_component) take precedence
How to resolve this issue

2

In reply to bachan21:

Why would you expect uvm_test_top class messages to print first? When you have multiple messages at any given time, the order of display is non-deterministic.

What issue is there with the messages being in this order?

3

In reply to cgales:

In my previous experience below signal is printed first, that denotes the test name

UVM_INFO test_library.svh(61) @ 0: uvm_test_top [uvm_test_top] Running RESET TEST

But in my TB the reset driving signal prints come first. Thats the issue

UVM_INFO lbc_bfm.sv(78) @ 0: uvm_test_top.BIST_ENV.LBC_BFM [uvm_test_top.BIST_ENV.LBC_BFM] RESET : Entered into reset phase for CBC
UVM_INFO lbc_bfm.sv(101) @ 0: uvm_test_top.BIST_ENV.LBC_BFM [uvm_test_top.BIST_ENV.LBC_BFM
UVM_INFO test_library.svh(61) @ 0: uvm_test_top [uvm_test_top] Running RESET TEST

4

In reply to bachan21:

You have race conditions in your environment. That’s the issue. There is no guarantee that messages generated at time 0 will be displayed in a known order.

In general, you should reduce the amount of testbench messaging to the bare minimum. This will likely improve your testbench performance as messaging is often the highest consumer of time in a UVM environment. Why are you printing out messages for each component/driver? I recommend that you only enable those messages with UVM_HIGH verbosity.

5

In reply to cgales:

The messaging from component is to improve the debug capability during reset(in this particular case).
I understand the scenario you explained. That clarify my doubts.