I'm trying to learn about SystemVerilog. While reading about it, I came across the following code, which I cannot fully understand:
Test1.
class A ;
task disp();
$display(" This is class A ");
endtask
endclass
class EA extends A ;
task disp ();
$display(" This is Extended class A ");
endtask
endclass
program main ;
EA my_ea;
A my_a;
initial
begin
my_a.disp();
my_a = my_ea;
my_a.disp();
end
endprogram
Test2.
class A ;
virtual task disp ();
$display(" This is class A ");
endtask
endclass
class EA extends A ;
task disp ();
$display(" This is Extended class A ");
endtask
endclass
program main ;
EA my_ea;
A my_a;
initial
begin
my_a = new();
my_a.disp();
my_ea = new();
my_a = my_ea;
my_a.disp();
end
endprogram
I have some questions about the test1 code above. There is a call to some 'new' function, but the implementation of that is not provided anywhere. How can this code compile and run then?
Also in the test2, you can see the 'virtual' keyword. I do not understand the reason behind using 'virtual'. Can you please explain why do we have to use 'virtual' in this context?
update
I'd like to implement the example code from Greg.
But I've got some problem as the below
Chronologic VCS (TM)
Version J-2014.12-SP1-1 -- Wed Aug 8 08:33:23 2018
Copyright (c) 1991-2014 by Synopsys Inc.
ALL RIGHTS RESERVED
This program is proprietary and confidential information of Synopsys Inc.
and may be used and disclosed only as authorized in a license agreement
controlling such use and disclosure.
Parsing design file 'design.sv'
Parsing design file 'testbench.sv'
Error-[SE] Syntax error
Following verilog source has syntax error :
"testbench.sv", 21: token is '('
function(A a);
^
1 error
CPU time: .073 seconds to compile
Exit code expected: 0, received: 1
Done
The new keyword is a constructor, it creates the object. Since new is not defined it is inferring the default constructor:
function new();
endfunction
Objects must be constructed before you call any of there methods. Test1 should through a null pointer error because you call an object's method that hasn't been constructed.
The virtual keyword and concept is the same in C++, Java, etc. There are plenty of explanations of this already answered on the virtual topic and polymorphism, such as : Why do we need virtual functions in C++?
In a nutshell a parent handle pointing to a child object can execute the object's method if it is virtual. Best way understant this is the create a class and child class that has both a virtual and non-virtual methods. Example:
module main ;
class A ;
function void disp ();
$display(" Non-Virtual from A ");
endfunction
virtual function void vdisp ();
$display(" Virtual from A ");
endfunction
endclass
class EA extends A ;
function void disp ();
$display(" Non-Virtual from EA ");
endfunction
virtual function void vdisp ();
$display(" Virtual from EA ");
endfunction
endclass
function void disp(A a);
a.disp();
a.vdisp();
endfunction
EA my_ea;
A my_a;
initial
begin
my_a = new();
my_ea = new();
disp(my_a);
disp(my_ea);
my_a = my_ea;
disp(my_a);
end
endmodule
Related
How to send macros as parameters through a task?
In the testbench:
`define CPU1 tb.top.dual_processor_db_wrapper_i.dual_processor_db_i.cpu1.inst
`define CPU2 tb.top.dual_processor2_db_wrapper_i.dual_processor2_db_i.cpu2.inst
initial begin
fork
cpu_init(`CPU1);
cpu_init(`CPU2);
join
// Other stuff with `CPU1 and `CPU2
`CPU1.write_data(addr, 4, data, resp); // Works
end
task cpu_init(cpu);
cpu.por_srstb_reset(1'b1); // Does not work
// Other init stuff
endtask
Error when compiling:
ERROR: [VRFC 10-2991] 'por_srstb_reset' is not declared under prefix
'cpu'
The type of the `CPUs is unknown (to me). Perhaps Xilinx has a type for it, since it references their MPSoC VIP?
I assume por_srstb_reset and write_data are tasks or functions from Xilinx MPSoC VIP, but I'm not sure.
Xilinx documentation is very sparse
I general, it is possible to pass a macro as an argument to a task. However, it is not possible to pass a hierarchical reference as an argument to a task (it is illegal).
Operations on hierarchical references are very limited, in general.
Your task declaration is equivalent to the following:
task cpu_init (input logic cpu);
The cpu variable is a 1-bit type. So, the following is legal:
`define CPU1 1'b1
cpu_init(`CPU1);
The type of the argument must match between the declaration and the task call.
There is another approach to this problem by using bind and abstract/concrete classes
package pkg;
interface class abstract_init;
pure virtual task init; // prototype for each method you need
endclass
abstract_init lookup[string]; // database of concrete classes for each instance
endpackage
module bind_module #(string lookup_name);
import pkg::*;
class concrete_init implements abstract_init;
function new;
lookup[lookup_name] = this; // register this instance
endfunction
virtual task init;
processor.reset(); // upwards reference
endtask
endclass
concrete_init c = new; // each instance of this module gets registered in lookup
endmodule
`define cpu1 top.dut.cpu1
`define cpu2 top.dut.cpu2
// macro turns any argument into a quoted string
`define Q(arg) `"arg`"
module top;
dut dut();
bind `cpu1 bind_module #(.lookup_name(`Q(`cpu1))) b();
bind `cpu2 bind_module #(.lookup_name(`Q(`cpu2))) b();
initial fork
pkg::lookup[`Q(`cpu1)].init;
pkg::lookup[`Q(`cpu2)].init;
join
endmodule
module dut;
processor cpu1();
processor cpu2();
endmodule
module processor;
initial $display("Starting %m");
task reset;
#1 $display("executing reset on %m");
endtask
endmodule
This is described more detail in my DVCon paper: The Missing Link: The Testbench to DUT Connection.
What is the meaning of "virtual tinyalu_bfm" in the SystemVerilog code below? example:
uvm_config_db #(virtual tinyalu_bfm)::set(null, "*", "bfm", bfm);
would it make any difference if i omitted the virtual keyword? Just curious, because the usually oop meaning of virtual is applied only to classes or class members and here's an example where its applied to an interface being passed into a static function that's part of UVM package... just wanted to know why I need to call it virutal in this case and what its purpose is to make it virtual.
module top;
// UVM Framework
import uvm_pkg::*;
`include "uvm_macros.svh"
import tinyalu_pkg::*; //import all tb classes and types
tinyalu_bfm bfm();
// invoke APIs from uvm_pkg to start test...
initial begin
uvm_config_db #(virtual tinyalu_bfm)::set(null, "*", "bfm", bfm);
run_test();
end
endmodule : top
interface tinyalu_bfm;
byte unsigned A;
byte unsigned B;
bit clk;
bit reset_n;
initial begin
clk = 0;
forever begin
#10;
clk = ~clk;
end
end
task reset_alu();
reset_n = 1'b0;
#(negedge clk);
#(negedge clk);
reset_n = 1'b1;
start = 1'b0;
endtask : reset_alu
task send_op(input byte iA, input byte iB, input operation_t iop, output shortint alu_result);
// ...
endtask : send_op
endinterface : tinyalu_bfm
see here again... the interface object is declared virtual as well...why?
// FILE: random_test.svh
class random_test extends uvm_test;
// ...
virtual tinyalu_bfm bfm;
function new (string name, uvm_component parent);
super.new(name,parent);
if(!uvm_config_db #(virtual tinyalu_bfm)::get(null, "*","bfm", bfm))
$fatal("Failed to get BFM");
endfunction : new
task run_phase(uvm_phase phase);
//...
endtask : run_phase
endclass
SystemVerilog was created to be fully backward compatible with Verilog with the exception being newly reserved keywords. So SystemVerilog re-uses, or overloads existing keywords as much as possible to reduce keyword bloat. The virtual keyword in front of an interface name means you are declaring variable type that contains a handle to an actual interface instance, and not an actual interface instance,
Analog to a virtual interface in normal programming languages is a pointer or a reference (to the interface object). It is used as a reference in system verilog test bench components, passing it as function or task arguments or storing it in classes or other places.
System verilog is a huge language with a lot of ugliness in it. The virtual keyword is definitely overused, as in this case. There could have been a better choice.
|
I suggest the following define macro to make up for bad language choose by the designers of SystemVerilog to overload virtual keyword is a strange way:
`define REFERENCE virtual
module top;
// UVM Framework
import uvm_pkg::*;
`include "uvm_macros.svh"
import tinyalu_pkg::*; //import all tb classes and types
tinyalu_bfm bfm();
// invoke APIs from uvm_pkg to start test...
initial begin
uvm_config_db #(`REFERENCE tinyalu_bfm)::set(null, "*", "bfm", bfm);
run_test();
end
endmodule : top
interface tinyalu_bfm;
// ...
endinterface : tinyalu_bfm
see here again... the interface object is declared virtual as well...why?
// FILE: random_test.svh
class random_test extends uvm_test;
// ...
`REFERENCE tinyalu_bfm bfm;
function new (string name, uvm_component parent);
super.new(name,parent);
if(!uvm_config_db #(`REFERENCE tinyalu_bfm)::get(null, "*","bfm", bfm))
$fatal("Failed to get BFM");
endfunction : new
task run_phase(uvm_phase phase);
//...
endtask : run_phase
endclass
I'm trying to understand 'virtual' keyword along with function.
I've got some experiment as the below,
class A ;
function void disp ();
$display(" Non-Virtual from A ");
endfunction
virtual function void vdisp ();
$display(" Virtual from A ");
endfunction
endclass
class EA extends A ;
function void disp ();
$display(" Non-Virtual from EA ");
endfunction
virtual function void vdisp ();
$display(" Virtual from EA ");
endfunction
endclass
module main ;
function void disp( A a);
a.disp();
a.vdisp();
endfunction
A my_a;
EA my_ea;
initial
begin
my_a = new();
my_ea = new();
disp(my_a);
disp(my_ea);
end
endmodule
and I've got the below message from code,
Non-Virtual from A
Virtual from A
Non-Virtual from A
Virtual from EA
But my expectation is that should be like this,
Non-Virtual from A
Virtual from A
Non-Virtual from EA
Virtual from EA
What does " vitual" keyword work in systemverilog?
Would you please explain why do I get this result? and how to resolve this problem?
You have constructed two object, one of type A whose handle is stored in my_a, and the other of type EA whose handle is stored in my_ea. When you call disp(my_ea), you are upcasting the EA handle to the function argument class variable a of type A.
When you call a non-virtual function, it uses the fixed class type A of the class variable a to choose which method gets called. So function A::disp gets called.
When you call a virtual function, the dynamic type of the class handle EA stored in the class variable a is used to choose which method gets called. So EA::disp gets called.
In other words: virtual function is a special type of function that, when called, executes the “most” child method that exists between the parent and child classes. This property is also known as polymorphism. The child method is called when the signature (name, parameter types, and whether the method is a constant) and return type of the child method match the signature and return type of the parent class method. Such methods are called overrides (or "overridden methods"). Because of class EA extends A , you got Virtual from EA ,as EA `s method most child)
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
I'm running into a weird issue working with SystemVerilog on DVT. The code snippet in question looks something like this:
class parent;
int A;
function void foo();
A = 5;
endfunction
endclass
class childA extends parent;
function void foo();
bit test_one; //Does not flag as a syntax error.
super.foo();
bit test_two; //Flags as error: Expected endfunction, found bit.
endfunction //Subsequently: Expected endclass, found endfunction
endclass //And lastly: Unexpected token: Endclass
As far as I know it is legal to call any hidden parent function using super. but this behavior is perplexing me. Can someone tell me if this is legal SV syntax? Or if not: What's the reasoning behind this?
It is illegal syntax. All variables in a task or function must be declared before any operation. See IEEE Std 1800-2012 § 13 Tasks and functions (subroutines)
Legal syntax is:
function void foo();
bit test_one;
bit test_two;
super.foo();
endfunction
The only exception is a begin-end block in which case the variable can be declared at the top of the begin-end block before any operation (but you can nest begin-end block). This does however limit scope access and may be less readable. So it not a good practice
function void foo();
bit test_one;
super.foo();
begin
bit test_two; // only in scope within this begin-end
begin
bit test_three; // not the same 'test_three' as below, different scope
end
begin
bit test_three; // not the same 'test_three' as above, different scope
end
// both 'test_three's are out of scope
end
// 'test_two' both 'test_three's are out of scope
endfunction
General best practice is to always declare your variables at the top. I prefer adding empty space between variable declarations and operations a visual separator; makes reading and modifying a ascetically easier.
function void foo();
bit test_one;
bit test_two;
super.foo();
endfunction