Store reference to array/queue in SystemVerilog - system-verilog

I'd like to store a reference to an array/queue inside a class. It's doesn't seem possible to do this, though.
I'd like to do something like this:
class some_class;
// class member that points to the 'q' supplied as a constructor arg
??? q_ref;
function new(ref int q[$]);
this.q_ref = q;
endfunction
endclass
If q_ref is merely defined as int q_ref[$], then the assignment operator will create a copy, which isn't what I want. I'd like changes in 'q' to be visible inside the class.
Is there some hidden section in the LRM that shows how this can be done?
I'm not looking for the obvious "you have to wrap the array/queue in a class answer", but for something that allows me to interact with code that uses native arrays/queues.

There are only three variable types in SystemVerilog that can store references: class, event, and virtual interfaces variables.
You have to wrap the array/queue as a member in a class object. Then, any method of that class can be used in an event expression. Any change to a member of the class object causes a re-evaluation of that method. See the last paragraph and example in section 9.4.2 Event control of the 1800-2012 LRM.

So, the only solution for you would be to wrap the queue in a class. The latter is always assigned by a reference, as in this example:
class QueueRef #(type T = int);
T queue[$];
function void push_back(T t);
queue.push_back(t);
endfunction // push_back
endclass // Queue
class some_class;
QueueRef q_ref;
function new(QueueRef q);
this.q_ref = q;
endfunction
endclass
program test;
QueueRef q = new;
some_class c = new (q);
initial begin
q.push_back(1);
q.push_back(2);
$display(c.q_ref.queue);
end
endprogram // test

Related

Distinguishing between local data member and child-class data member in an inline constraint

I have a class with a rand data member i. This class (child) is a member of class parent, which also has a data member i. I would like to constrain the value of i in the child class to be the same as the value of i in the parent class. I want to do something like:
c.randomize with {i==this.i;};
but the this.i doesn't seem to refer to the i data member of the parent class. (Why?)
I can do this:
function void f;
int dummy = i;
c.randomize with {i==dummy;};
endfunction
or this:
function void f;
c.randomize with {i==m.blk.p.i;}; // yuck!
endfunction
but wonder if there is a better (built-in, non-hacky) way of distinguishing between the two is.
MCVE:
class child;
rand int i;
endclass
class parent;
child c = new;
int i=1;
function void f;
c.randomize with {i==this.i;};
endfunction
endclass
module m;
initial begin : blk
parent p = new;
p.f;
$display("%p", p);
end
endmodule
https://www.edaplayground.com/x/2_8P
You want {i==local::i}. See section 18.7.1 of the 1800-2017 LRM
The reason this.i does not do what you expect is the combination of these two rules:
all class methods, including the built-in randomize method, have a built-in this argument. So c.method(args) is really method(args, c) and this becomes a variable local to the method set to the value of c
Identifiers within the with clause try to bind into the scope being randomized first before searching locally at the point where calling randomize().
So i and this.i refer to the same class variable just as if you wrote
class A;
bit i;
function void method;
i = 1;
this.i = 2;
endfunction
endclass

Modifying queue of class in systemverilog function

I met a problem when I trying to modify a queue of class in systemverilog function.
Here are the codes:
module my_module;
class dscr;
logic mode;
function void print_dscr;
$display("mode = %d", this.mode);
endfunction
endclass
dscr a_dscr_q[$];
dscr b_dscr_q[$];
initial begin
descriptor_decode(0, a_dscr_q);
for (int I=0; I<a_dscr_q.size(); i++)
a_dscr_q[i].print_dscr();
descriptor_decode(1, b_dscr_q);
for (int I=0; I<a_dscr_q.size(); i++)
a_dscr_q[i].print_dscr();
for (int I=0; I<b_dscr_q.size(); i++)
b_dscr_q[i].print_dscr();
end
function void descriptor_decode(logic mode, ref dscr dscr_q[$]);
dscr dscr_dec = new;
dscr_dec.mode = mode;
dscr_q.pushback(dscr_dec);
endfunction
endmodule
I am trying to create different class queue in function "descriptor_decoder", with different value of input mode. In function, I firstly create a new dscr class and then push it to a class queue. However the simulation result are:
mode = 0
mode = 1
mode = 1
The first time I call the function, it did push back the correct class into a_dscr_q. But the second function call, it seems the class is push back into both a_dscr_q and b_dscr_q. I am quite confused, What happened in here?
Your code was made illegal syntax in the IEEE 1800-2009 LRM because of the very problem you are experiencing. Most tools now report this as an error.
Your descriptor_decode is function with a static lifetime, and the dscr_dec variable declared inside it has a static lifetime as well.
You are not allowed to have an initialization on a variable whose lifetime is implicitly static and has the option to be declared automatic. This is because unlike most programming languages, the default lifetime of variables in a SystemVerilog function is static, and initialization of static variables happens once before time 0, not each occurrence of calling the function. In your example, you are expecting dscr_dec to behave as an automatic.
So you need to make one of the following code changes:
explicitly declare dscr_dec automatic
declare the function automatic, which makes variables declared inside it implicitly automatic
declare the module automatic, which makes functions declared inside it implicitly automatic
split the declaration and initialization do that the initialization happens when the function gets called.

Is it possible to call new in SystemVerilog outside an assign statement?

This is how I usely call new in SystemVerilog:
class A;
endclass
A a = new();
But sometimes, I don't need a local object, I just want to send it directly to a function taking an A. Is there a way to call the new function explicitly here:
function use_a(A obj);
endfunction
use_a(new()); // <--- How to write this call to specify which new to call?
use_a(A::new()); // <--- new not expected here :(
Unfortunately, SystemVerilog's syntax does not allow this. The special new method is not a static method, and a class handle has to exist in some variable because of the way class memory management is defined. You could get around this by wrapping new around a static method:
class A;
static function A create();
create = new();
endfunction
endclass
...
use_a(A::create());
BTW, the UVM has create methods in the BCL and you almost never need to call new() directly.

system verilog : Overridden members system verilog classes

class my_a;
int member1 = 1;
endclass
class my_ea extends my_a;
int member1 = 2;
endclass
Now when I do
my_a A;
my_ea EA;
EA =new();
A=EA;
EA = new(); has given handle to object of type my_ea to class variable EA.
A=EA; passes the same handle (pointer value which points to object of my_ea) to A. So, A.member1 should refer to value 2.
But it refers to value 1. Why?
So far, System-Verilog does not allow overriding of class variables. Only virtual methods can be overridden.
There is nothing like virtual for class members, so parent class can never directly access them. When using class_object.member, the particular class is referred to. Henceforth, this is not possible.
You cannot redefine an existing member by extending a class. You should use virtual methods to access (get/set) them. For instance, I added "get_member1" function to your code, and it returns 2 when called from a base class handle as you wanted.
class my_a;
int member1 = 1;
virtual function int get_member1();
return member1;
endfunction
endclass
class my_ea extends my_a;
int member1 = 2;
virtual function int get_member1();
return member1;
endfunction
endclass
module tb;
initial begin
my_a A;
my_ea EA;
EA =new();
A=EA;
$display("%0d", A.get_member1());
end
endmodule
You can similarly define "set_member1(int value)" function and use it to change its value.
In your case A.member1 should return the original member of its own class. When you are overriding a class members, you are basically hiding the overridden members. Super/base class can never access overridden member in its subclass.
As far as I know, only method identified with virtual, randomize() function and class constraint can be overridden without hiding them from the base class - thus they allow base class to reference to them (polymorphism)
For more info, please find here IEEE 1800-2012 in section 8.14 Overridden members.

Is there any method to know whether a member is declared random or not in a class in SV

// Current Class
class x;
rand int a;
int b; // b is nonrandom as of now
function new();
endfunction
function abc;
// if a != ref.a, where ref is reference object of class x, declared somewhere else
a.rand_mode(0);
endfunciton
// Future Possible Class
class x;
rand int a;
rand int b; // b is also a random variable now
function new();
endfunction
function abc;
// if a != ref.a, where ref is reference object of class x, declared somewhere else
a.rand_mode(0);
// if b != ref.b, where ref is reference object of class x, declared somewhere else
b.rand_mode(0);
endfunciton
So in function abc, depending upon whether a rand member value matches or doesn't match with the value of that member in reference class, that rand declared members of class x, should be active or inactive accordinly.
Purpose - I need to check if a rand variable matches with reference class value then only it should be randomized, otherwise not.
I want to generalize method abc, for all possible future variations (So I don't need to modify it, as done in the above example), and as I don't know, when a class member may become rand or nonrand member, Is there any inbuilt method to know, whether a member of a class is declared as rand or not in that class?
You could change your perspective on the problem slightly. Instead of trying to disable randomization for fields that are declared rand, why not say that when they get randomized, they should keep their value?
According to this nice post, there's a new construct in SV 2012, const'(...) that would work in this case. Unfortunately I don't think many vendors support it. Your randomize() call would look like this:
if (!rand_obj.randomize() with {
const'(a) != ref_obj.a -> a == const'(a);
})
$fatal(0, "rand error");
Let's dissect this code. const(a) will sample the value of a prior to doing any sort of randomization. If the value of a before randomization is not equal to the reference value, then we have the second part of the constraint that says a should keep its value. I've tried this code on two simulators but it wasn't supported by either (though it should be legal SV 2012 syntax). Maybe you're lucky enough to have a vendor that supports it.
You can write such constraints even for state variables, as they will still hold.
If you can't get the const syntax to work in your simulator, then the same post shows how you could work around the issue. You could store the values prior to randomization inside the object and use those in the constraint:
class some_class;
rand bit [2:0] a;
bit [2:0] b;
bit [2:0] pre_rand_a;
bit [2:0] pre_rand_b;
function void pre_randomize();
pre_rand_a = a;
pre_rand_b = b;
endfunction
endclass
When you want to randomize, you'd add the following constraints:
if (!rand_obj.randomize() with {
pre_rand_a != ref_obj.a -> a == pre_rand_a;
pre_rand_b != ref_obj.b -> b == pre_rand_b;
})
$fatal(0, "rand error");
You can find a full example on EDAPlayground.
You mention that your function that does randomization is defined outside of the object. Because of that, the pre_rand_* fields can't be local/protected, which isn't very nice. You should consider making the function a class member and pass the reference object to it, so that you can enforce proper encapsulation.
This isn't possible as SystemVerilog doesn't provide any reflection capabilities. You could probably figure this out using the VPI, but I'm not sure how complete the implementation of the VPI is for classes.
Based on what you want to do, I'd say it anyway doesn't make sense to implement such a query just to future proof your code in case some fields will one day become rand. Just as how you add the rand modifier to the field, you can also add it to the list of fields for which randomization should be disabled. Both code locations reside in the same file, so it's difficult to miss.
One certain simulator will return -1 when interrogating a state variable's rand_mode(), but this is non-standard. The LRM explicitly states that it's a compile error to call rand_mode() on non-random fields.