Can't randomize members of class derived from uvm_sequence

[Erling]

I have problems randomizing individual members of classes derived from uvm_sequence, for example:

class MySeq extends uvm_sequence #(MyItem);

rand int i;

task body();

assert(randomize(i));

endtask

endclass

The randomize call fails with this message:

# test.sv(10)randomize() failed due to conflicts between the following constraints:

# ../../uvm_1.0p1/seq/uvm_sequence_base.svh(154): #unknown#.c_randomized { 1'h0; }

The simulator debug info is as follows:

# test.sv(10): randomize() failed; generating simplified testcase scenario...

# ----- begin testcase -----

# module top;

#

# class TFoo;

# constraint all_constraints {

# // ../../uvm_1.0p1/seq/uvm_sequence_base.svh(154): #unknown#.c_randomized{ 1'h0; }

# 1'h0;

# }

# endclass

#

# TFoo f = new;

# int status;

#

# initial begin

# status = f.randomize();

# $display(status);

# end

The problem goes away if I comment out the constraint c_randomized in class uvm_sequence_base, but I would guess this isn't a good workaround.

Ideas?

Regards,

Erling

[uwes]

hi,

first this smells like a tool issue as UVM doesnt do the randomization itself. two things however are suspicious to me

1. you randomize the own object "this". while this is legal its strange to me (i usually randomize the object and then perform operation with it)

2. you only generate "i". you should probably use "std::randomize(i)" instead of the class randomize

[Erling]

hi,

first this smells like a tool issue as UVM doesnt do the randomization itself. two things however are suspicious to me

1. you randomize the own object "this". while this is legal its strange to me (i usually randomize the object and then perform operation with it)

2. you only generate "i". you should probably use "std::randomize(i)" instead of the class randomize

Well, I learned the habit from the uvm source, in this case uvm_random_sequence (which is broken on Questa (at least) due to this issue). uvm_random_sequence has been deprecated in uvm 1.0, but I would guess there are quite a few test-benches still using it.

Regards,

Erling

[dave_59]

Erling,

See the LRM section 18.11 In-line random variable control. When you call randomize(i), all rand variables in MySeq (including the is_randomized bit in uvm_sequence_base) become state variables except for i. All constraints remain enforced, so the c_randomized constraint is not able to set the is_randomized bit to 1.

Not knowing what you are really trying to do, there are a number of things you could do:

• is_randomized = 1; before calling randomize(i)
• c_randomized.constraint_mode(0); before calling randomize(i)
• call randomize(i,is_randomized)
• call std::randomize(i) with {your_constraints};

[Erling]

Erling,

See the LRM section 18.11 In-line random variable control. When you call randomize(i), all rand variables in MySeq (including the is_randomized bit in uvm_sequence_base) become state variables except for i. All constraints remain enforced, so the c_randomized constraint is not able to set the is_randomized bit to 1.

Not knowing what you are really trying to do, there are a number of things you could do:

Thanks for advice. But what about uvm_random_sequence? It would seem many a EA testbench is broken under 1.0p1 due to this.

Regards,

Erling

[dave_59]

Erling,

The UVM EA kit was an early adopter release -- a work in progress, not for production use.

The body() method in ovm_random_sequence correctly turned turned the pick_sequence constraint off in ovm_sequence_base. Then, uvm_sequence_base added the c_randomized constraint, but uvm_random_sequence forgot to turn it off as well.

This section of the UVM (the sequence built-in's) had no examples/tests to catch this error, and is now deprecated, so I guess you are left with one of my suggested workarounds, or modify the source yourself.

[ryz]

I do have the same problem when I try to randomize my own members. What I do not understand is if is_randomized should be considered a state variable why does the tool still enforce the constrain of the variable? Is this stated in the LRM that though the user has defined that it only wants to randomize some members all members has to full fill it constrains to return true? This seems a strange thing to do.

[Erling]

I do have the same problem when I try to randomize my own members. What I do not understand is if is_randomized should be considered a state variable why does the tool still enforce the constrain of the variable?.

A constraint block isn't a per variable construct, it is simply a list of expressions. Unwanted behavior would result if a constraint block was implictly disabled just because one or more expressions in it refer to rand members to be considered state variables during a given call to randomize().

Erling

[ryz]

Does this mean that I can constrain an member that is not declared as rand and have the randomize fail if the member does not contain an valid value for the constrain because that is exactly what we doing here?

The reason I asks is because of my question here

constraining repeated sequence

[ryz]

Well I did a read up on the LRM and it states that it is perfectly valid to constrain none random members and use them as a checker. That unfortunately makes my way of using constraining repeated sequence to be not so good.

[Erling]

The reason I asks is because of my question here

constraining repeated sequence

It seems to me this sequence should work. What problem do you have with it?

Erling

[ryz]

Well for starter I have to set is_randomized to 1 else the

assert(this.randomize(ph_num, pkt_size));

Will fail.

It also seems a little dangerous to do an randomization on your self where you turned of all but two members. Depending on how constrains is set up when used this could lead to unexpected constrain solver errors.

I guess it is better to take this discussion in the other thread.

[Erling]

Well for starter I have to set is_randomized to 1 else the

assert(this.randomize(ph_num, pkt_size));

Will fail.

.

Why would that fail? The sequence is randomized by the test, and thus one should think is_randomized is 1 at entry of the sequence body, and the local randomize should work. What am I missing?

Erling

[ryz]

Yes you are right. I had done something wrong In my test bench where I use this approach but with more complex sequences so it did not get randomize properly in the test case.

It would not work if some test case decides that it does not need to randomize the sequence before sending it which should be perfectly valid.