Constrained Random Verification depending on the output of the module

Hi all,

I was wondering if it was possible to constrain a variable depending on an output value of the same module.

For example, variable “a” must be ‘1’ only one time until variable “done” is ‘1’.

Is possible to model this into a constraint? I’ve seen that they cannot be temporal, so it’s hard to think about it.

Thanks,
Marc

In reply to Marc43:

You can use post_randomize() to create a state machine. I think you need three states

typedef enum {INIT,ONCE, DONE} fsm_t;
class foo;
  fsm_t fsm = INIT;
  rand int a;
  constraint c_fsm {
    fsm == ONCE -> a != 0;
  }
  function void poet_randomize ();
    if (fsm == INIT && a == 1) fsm = ONCE;
    if (done == 1) fsm == DONE;
  endfunction
endclass

In reply to dave_59:

In reply to Marc43:
You can use post_randomize() to create a state machine. I think you need three states

typedef enum {INIT,ONCE, DONE} fsm_t;
class foo;
fsm_t fsm = INIT;
rand int a;
constraint c_fsm {
fsm == ONCE -> a != 0;
}
function void poet_randomize ();
if (fsm == INIT && a == 1) fsm = ONCE;
if (done == 1) fsm == DONE;
endfunction
endclass

Hi, Dave, thank you for your reply :)

I see your point, but considering that “done” is an output this is also possible? I guess it is, but maybe for a UVM environment would be ugly and philosophy breaking?

Thanks again.

In reply to Marc43:

That’s new information about your environment you didn’t mention in your original post.

You can always probe your DUT from any class based environment. Then you can use those probed values as state variables in your constraints, or wherever you want in your environment. See Updated Example Code from DVCon Paper: The Missing Link: The Testbench to DUT Connection | Verification Academy

In reply to dave_59:

Thank you, Dave, for your response.

Sorry for not indicating that I was using UVM. I did want to see if there was any solution without UVM.

Okay, I read the paper and seen the example. I see that for the probe interface do you use the port fashion, in UVM I have only seen class members, so I was wondering, it would be possible to use class members for the signals that I don’t want to probe (I will stimulate them in the driver with the sequences) and the ports of the interface for the signals I want to probe?

In reply to Marc43:

In reply to dave_59:
Thank you, Dave, for your response.
Sorry for not indicating that I was using UVM. I did want to see if there was any solution without UVM.
Okay, I read the paper and seen the example. I see that for the probe interface do you use the port fashion, in UVM I have only seen class members, so I was wondering, it would be possible to use class members for the signals that I don’t want to probe (I will stimulate them in the driver with the sequences) and the ports of the interface for the signals I want to probe?

Okay I see, in a certain way you do this.

But, how are you using create_object? I guess you use it because the factory can’t find the registered type and you are not able to do something like probe::type_id::create(…). Using create_object I have this error:

The name ('create_object') was not found in the current scope.  Please verify the spelling of the name 'create_object'.

Great to have you in the forums Dave, thank you very much.

In reply to Marc43:

I’m using uvm_component::create_object because there’s no way to access the class type since it’s declared inside an instance of a module.

In reply to dave_59:

Then, as this is a uvm_component class method, I would not be able to use it from a uvm_sequence_item, just where I put the constraints, right?

Any other workaround?

In reply to Marc43:

Check the link I just gave you.

In reply to dave_59:

Yes, I had to use the equivalent version I did not see the first time.

Now I am able to probe the signal I wanted to probe and I have the state machine working. Thank you very much!