I am create one sequence class which contain local variables with rand keyword. In task body I am creating transaction handle tr and randomize with inline constraint. In this randomization I am assign transaction variable with sequence local variable.
eg. assert(tr.randomize() with {line==this.line;pixel==this.pixel;bytepix==this.bytepix;framerate==this.framerate;colorinfo==this.colorinfo;frame_field_video==this.frame_field_video;})
In test class I am creating this sequence handle and in run phase I am randomize sequence handle wr1 with inline constraint.
eg. assert(wr1.randomize() with {wr1.line==14’d2;wr1.pixel==14’d1400;wr1.bytepix==32’d3;wr1.framerate==8’h08;wr1.colorinfo==4’d1;wr1.frame_field_video==4’d8;})
But it is not working correctly. transaction variable contain different value not as per test class value.
Please help me to solve this issue.
The problem came from the randomize method in your sequence class. You can change by using “local::” from LRM:
18.7.1 local:: scope resolution
The randomize() with constraint block can reference both class properties and variables local to the method call. Unqualified names in an unrestricted in-lined constraint block are then resolved by searching first in the scope of the randomize() with object class followed by a search of the scope containing the method call—the local scope. The local:: qualifier modifies the resolution search order. When applied to an identifier within an in-line constraint, the local:: qualifier bypasses the scope of the [randomize() with object] class and resolves the identifier in the local scope.
And you code will be:
assert(tr.randomize() with {
line==local::line;
pixel==local::pixel;
bytepix==local::bytepix;
framerate==local::framerate;
colorinfo==local::colorinfo;
frame_field_video==local::frame_field_video;
})
Or you can change the variable name to make sure they are different between sequence and sequence_item.
I am tried your code but simulation shows assertion error(randomization fail error).
I am tried with different name but simulation shows assertion error(randomization fail error).
In transaction randomization it does not take local variable for assignment.
Hi,
Generally We write different sequence class. We take these sequence class handle in corresponding test class. eg. sequence class are seq1, seq2 etc. we take seq1 class handle in test1 class, seq2 class handle in test2 class etc. we call these test cases. Here we write different sequence class for different testcase.
Can we write only one sequence class? can we take this sequence class handle in different test class? At the time of sequence class randomization in run phase of test class we assign values to sequence class variable. And we have only one sequence class in task body we randomize transaction handle and assign sequence class local variable to transaction class variable.
Is it correct approach?
I think your approach is fine. However, in my opinion, I usually create different sequences to generate different scenarios to DUT. And testcases will start these sequences indirectly (factory override) or directly. Your way is difficult to reuse, we usually reuse the sequences instead of testcases.
In reply to chris_le:
Hi,
Generally We write different sequence class. We take these sequence class handle in corresponding test class. eg. sequence class are seq1, seq2 etc. we take seq1 class handle in test1 class, seq2 class handle in test2 class etc. we call these test cases. Here we write different sequence class for different testcase.
Can we write only one sequence class? can we take this sequence class handle in different test class? At the time of sequence class randomization in run phase of test class we assign values to sequence class variable. And we have only one sequence class in task body we randomize transaction handle and assign sequence class local variable to transaction class variable.
Is it correct approach?
The question is not that it is a correct approach. I believe it is a very limiting approach, having 1 sequence and using the control knobs to constrain for certain test scenarios. It does not give you the freedom you need to cover all aspects of your design.
Depending on the complexity of your design you might have between around 50 and 500 different scenarios you have to verify. For each scenario you need one or more virtual sequences. Then you can estimate how many different sequences you need.
BTW, in the default approach we do not send sequence values. We generate seq items and they are retrieved by the driver from the sequencer.