SystemVerilog 2012 Has Even More ‘Class’

Blog Comments
1

While scouring the Web for blogs on verification, I came upon this post on Ankit Gopani's blog. He tries to shed some light on the various types of classes that SystemVerilog has. What is missing, however, is the interface class, a new construct brought into the language by the IEEE 1800-2012 standard.

This is a companion discussion topic for the original entry at https://verificationgentleman.netlify.app/2014/08/24/systemverilog-2012-has-even-more-class.html
2

Nice post! Thank you for introducing me to interface classes. Somehow I missed this in the new LRM… :slight_smile:

4

I found this section in the LRM interesting as well:

interface class IntfClass;
pure virtual function bit funcBase();
pure virtual function bit funcExt();
endclass
class BaseClass;
virtual function bit funcBase();
return (1);
endfunction
endclass
class ExtClass extends BaseClass implements IntfClass;
virtual function bit funcExt();
return (0);
endfunction
endclass
ExtClass fulfills its requirement to implement IntfClass by providing an implementation of funcExt
and by inheriting an implementation of funcBase from BaseClass.

This would allow you to write a library of ~implementations~ of an interface class. Then the implementation class can pull off the shelf which implementation it wants to use (or “extend” from)!

5

Thank you for the article. I came across one more class “process class” in SV, which is used to monitor the progress of threads generated using fork.

6

I wouldn’t call the ‘process’ class another type of class. It’s just a built in class, not a different class construct. Nevertheless, I’ll keep it in mind and maybe we’ll see a post on working with processes in the future.

7

Hi Tudor,

Thanks for reading my blog post “ASIC with Ankit: Class - The Classic Feature - Part II” and thanks for touching up on interface class. This is a nice post with useful and required information. Thanks for sharing !

Thanks,
ASIC With Ankit

8

Awesome post Tudor… This has great clarity on interface class…

9

Hi Tudor,
Nice post.

Quick question:
Can this abstract class be passed using config db from the module ?

10

I think you mean doing a uvm_config_db #(some_interface_class)::set(…), right? I’m pretty sure this should be possible.

11

Tudor,
I notice that the ‘driver’ class and ‘insurer’ class encapsulates the interface classes drivable_if and insurable interface respectively. Is this always needed? If so, could you please throw some more light as to why?

12

The don’t encapsulate the interfaces. They implement them.