What is “special” about SystemVerilog’s new - constructor

During one of our recent VSV training sessions, a smart attendee asked few interesting questions about SystemVerilog’s new constructor. Questions like:

1. Is it similar to other functions in Verilog/SV?

2. Is it virtual?

3. What is the return type of the same?

4. How does inheritance work for new ?

So here is a blog entry that delves into the “details”.

First of all – it is a function – so it can only have non-time consuming stuff (BTW, a task can be invoked via fork..join_none from within a function).

It is NOT a virtual function. It is illegal to declare it “virtual”.

On the return “type” – it is different from other functions – it is very “adaptive in nature” – i.e. it returns what the LHS requires. i.e. it returns an object of the type of the handle that appears on the LHS. Hence there is NO return type declared for this special function.

Things get very interesting/special when a new class is derived from a base class. With any other System Verilog function/task, you have 3 options while doing inheritance:

1. Override base class behavior
2. Add//append to base class behavior
3. Prepend to base class behavior

For those who are familiar with E, IEEE 1647 language, it is equivalent to

1. is only (override)
2. is also (append)
3. is first (prepend)

However when it comes to this special new function – it always an “append behavior” (“is also” – as in E/Specman): Let’s look at some code & results;

Consider the code below:

Since only a derived object is constructed and there is no call to super.new explicitly one might expect only the message from derived class’s new.

But see what Questa (www.mentor.com/questa) does:

So that’s one “special” behavior of new. i.e. whether or not you call the base class’s constructor – it always gets called implicitly.

To prove this point and to see if we can play some “tricks” with it, here is a small variant code below;

In the above code we just added an argument called “id” to the base class constructor. In the derived we decided to “forget” about it. If it was a “virtual” function, as per the semantics, this would be illegal – i.e. the function prototype/signature must remain same across inheritance. However the re-definition of new in derived class is just fine. However, there is still an error: recall that the base’s new is always called – now the “id” argument is NOT provided for the implicit call to new. So what does our friendly compiler Questa say for this? See below;

 

 

So the error message is clear enough as to how it can be fixed. Below is a possible fix:

 

Now, as a last experiment for this blog, why do we claim only is also is allowed for new ? What if I try other way? See the result below:

 

Here is what LRM IEEE 1800-2009 has to say for this:

When using the super within new, super.new shall be the first statement executed in the constructor. This
is because the superclass shall be initialized before the current class and, if the user code does not provide an
initialization, the compiler shall insert a call to super.new automatically.

 

So hopefully you are convinced that the simple looking function new  is indeed “special” function in SystemVerilog.

Happy new-ing :-)

TeamCVC

www.cvcblr.com/blog