[sv-ec] RE: Mantis 3531 - use of null in constant expressions

There are places other than parameter values where the LRM calls for constant expressions. For example, 6.20.6 specifies that if a const class handle has an initializer that calls new(), the arguments shall be constant expressions. There is no reason for this requirement, but it is there. Earlier, 6.20.6 specified that initializers on const variables can be set to expressions of a variety of things, and it isn't clear whether this includes null (though I would assume it does, since it mentions literals and "other constants", one of which should apply). As another example, 7.2.2 specifies that default values for individual members of a struct shall be constant expressions.

Also note that null could be an operand of an expression whose result type isn't a handle. For example, it could be used in a compare that controls a conditional operator. Or as argument to a constant function, which might sometimes be called as a normal function and passed a handle, but when called as a constant function would have to be passed null.

From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Mark Hartoog
Sent: Thursday, August 18, 2011 6:00 PM
To: sv-ec@eda.org
Subject: [sv-ec] Mantis 3531 - use of null in constant expressions

I was asked to come up with a proposal for 3531. The mantis says:

"There are a number of constant expression situations where 'null' would be useful, and clearly the value is constant. Based on some past discussions in committee, it seems that the members have assumed that 'null' is legal in constant expressions. The LRM should be modified accordingly."

I'm sort of at a loss to come up with constant expression situations where 'null' in a constant expression is actually useful. This is a list of the situations I can think of where it seems to be allowed in the current LRM.

The value null can be used for: class handles, chandles, events, and virtual interface. It can also be used as a special argument to randomize call (section 18.11.1) and perhaps some usages in covergroups or constraints, but I don't think that is relevant.

Class handles.

There appears to be nothing in the LRM to prevent one from declaring a parameter of class type.

class C;
   static function int foo(input int a, b);
      return a+b;
   endfunction
endclass

parameter C p = null;

There really isn't much that you can do with this parameter. The value 'null' would seem to be the only value you could assign to it. You could not access static data members in a constant expression with it, even constant static data members, because those are variables that cannot be accessed during elaboration. You might be able to call static function members in a constant expression, if they otherwise met all the requirements of constant functions (13.4.3), but these functions could not access any static data members either. You don't need a parameter to call these functions. You can call them directly with <className>:: <functionName>. For example C::foo(1,2) in the above example.

I really don't see where allowing parameters of type class adds anything useful to the language except confusion.

Chandles

The LRM appears to allow this:

parameter chandle p = null;

It would seem that 'null' is the only value that could be assigned to this parameter, since DPI function calls are not allowed in constant functions (13.4.3). While allowing this is mostly harmless, it does not add anything to the language except confusion.

Events

Again the LRM appears to allow:

parameter event p = null;

The problem is that events don't make sense in the context of constant expressions. The value 'null' would appear to be the only value you could assign to this parameter and there is nothing useful you could do with the parameter. I don't think this adds anything to the language.

virtual interfaces

Again the LRM appears to allow:

interface intf();
endinterface

parameter virtual interface p = null;

It would appear to me that:

intf i1();

parameter virtual intf p1 = i1;

would be illegal, since instance references are illegal in a constant expression. If somebody wants to make an argument that this should be legal, then what could you do with this parameter? I suppose you could pass an instance down the hierarchy using parameters like this and then assign the parameter to some virtual interface variable. I don't think the current LRM allows that, but virtual interface parameters might make some sense if the LRM was changed to allow it. To me the value of a virtual interface handle is not a well defined concept until the simulation starts. As the LRM stands now, I think 'null' is the only value allowed and the parameter is not actually useful for anything.

These are the only places I can think of where 'null' would be legal in a constant expression. I don't think any of them adds anything useful to the language except more ways for users to get confused. I think we would be better off to make these data types illegal for parameters, so users don't waste their time trying to figure out how to use them. There are some other data types like covergroups that do not make any sense for parameters also.

Can somebody tell me what are the constant expression situations where 'null' would be useful and adds something to the language?

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.