[RNDFLD] Randomization failed in uvm_do_with/uvm_rand_send_with

UVM
, ,
1

Hi,

In a case we receive randomization errors in log, for example:

  • Solver failed when solving following set of constraints
  • Randomization failed in uvm_rand_send_with action
  • Error-[CNST-NPE] Constraint null pointer error

Is it possible to use the uvm_report_catcher and change these messages to be UVM_FATAL? I mean that the test will finish simulation on detection of these strings, since these errors are not of a UVM_INFO, UVM_WARNING or UVM_ERROR severity?
Is it a common practice? Or advised?

Thanks,
Michael

2

In reply to Michael54:

The best practice is to not use the `uvm_do_* macros.

Instead, you should create(), randomize() and send/start your sequence_items/sequences using the direct API calls. You can then catch any randomization failure with the appropriate action.

3

In reply to cgales:

In reply to Michael54:
The best practice is to not use the `uvm_do_* macros.
Instead, you should create(), randomize() and send/start your sequence_items/sequences using the direct API calls. You can then catch any randomization failure with the appropriate action.

I was interested to hear if as general practice, is it a good idea to add few messages to the uvm_report_catcher which will assert the action of $finish simulation, instead of all the time checking if randomization worked?
My question is not only related to the uvm_do* macros, I know that is better to use the: create, randomize (query if randomize was successful) and send/start. I am working on IP/SoC and reusing sequences written by sub-IP block owners, all the sequences there are written using the sequence macros (uvm_do*), and not interested in re-writing their code… pretty much a headache to ask them do anything different…
Is it easy to achieve it using the uvm_report_catcher construct?
Is this approach correct from methodological point of view?

Thanks!

4

In reply to Michael54:

You could use the report catcher to promote all “RNDFLD” warning messages to UVM_FATAL.

The report catcher cookbook page has an example of applying a catcher to all messages.

5

In reply to Michael54:

This is what I do in such (typical IP level) cases:


// Inside my base_test
set_report_severity_id_action_hier
    (UVM_WARNING, "RNDFLD", UVM_EXIT);

You can tweak the uvm_action according to what you need. I believe you could also promote it to ERROR/FATAL.

Cheers
Srini

6

In reply to Michael54:

In reply to cgales:
I was interested to hear if as general practice, is it a good idea to add few messages to the uvm_report_catcher which will assert the action of $finish simulation, instead of all the time checking if randomization worked?
My question is not only related to the uvm_do* macros, I know that is better to use the: create, randomize (query if randomize was successful) and send/start. I am working on IP/SoC and reusing sequences written by sub-IP block owners, all the sequences there are written using the sequence macros (uvm_do*), and not interested in re-writing their code… pretty much a headache to ask them do anything different…
Is it easy to achieve it using the uvm_report_catcher construct?
Is this approach correct from methodological point of view?

@Michael54: You have 2 options to change the uvm verbosity:
(1) Override the default report_catcher, especially you have to implement

function action_e catch

(2) you can use

set_report_severity_id_action_hier

(what Srini is proposing)
Finally it is up to you to make your decision.