RE: [sv-ec] are constraints virtual like?

<forwarding bounced email from danielm@aldec.com>

-------- Original Message --------
From: "Daniel Mlynek" <danielm@aldec.com>
To: "'Arturo Salz'" <Arturo.Salz@synopsys.com>,
         "'Steven Sharp'" <sharp@cadence.com>, <daniel.mlynek@aldec.com.pl>,
         <sv-ec@eda.org>
Subject: RE: [sv-ec] are constraints virtual like?
Date: Thu, 9 Sep 2010 08:37:32 +0200

Thanks for the answers.

I see that this is rather controversial and unclear.

I like Steven's reasoning more (it is closer to current LRM text). In my
example constraint mode is called on member select so it cannot behave
virtually. It should turn off the constraint from base class. That is true
that it will be NOOP for randomize call but if you read constrain mode with
constraints_mode function you will see which one is turned off.

Interesting case is also when constraint mode is called on a handle
(c.constraint_mode). LRM does not say that this function is virtual why we
should think that it is? It would be over-interpretation

IMHO those both cases should be explicitly adressed by LRM. I've registered
mantis on that:
http://www.verilog.org/mantis/view.php?id=3201

DANiel

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Arturo
Salz
Sent: Thursday, September 09, 2010 4:09 AM
To: Steven Sharp; daniel.mlynek@aldec.com.pl; sv-ec@eda.org
Subject: RE: [sv-ec] are constraints virtual like?

Steven,

I understood the question and I believe my previous answer is correct.
Here's the reasoning.

It is true that the LRM doesn't explicitly say that constraint_mode is
virtual, but, that is the only semantic model that makes sense given that
constrains are virtual (or virtual like). I also understand that a member
select is not virtual, except that in this case what resembles a member
select is being applied to a virtual object (the constraint). What little
the LRM says does hint at constraint_mode being virtual-like:

The constraint_identifier is the name of the constraint block to which the
operation is applied. The constraint name can be the name of any constraint
block in the class hierarchy. If no constraint name is specified (only
allowed when called as a task), the operation is applied to all constraints
within the specified object.

The second sentence says "The constraint name can be the name of any
constraint block in the class hierarchy." It doesn't say any constraint in
the class, but in the class hierarchy, which was intended to mean the names
of virtually overridden constraints - albeit I concede that the language
could be much improved.

Finally, the reason I say that the only semantic model that makes sense is
for constraint_mode to be virtual is because in order to be meaningful it
has to apply to the (only) constraint that exists in the object since the
base constraint have already been overridden. Consider Daniel's example:

class C;
     rand int a;
     constraint con1{a==0;}
endclass

class D extends C;
     constraint con1{a==10;}
endclass

D d = new;
C C = d;

c.con1.constraint_mode(0);

If c.con1.constraint_mode applies to C::con1, the above is a noop since that
constraint has been overridden, hence, D::con1 would still be active, and
a==10 would be the only solution.

        Arturo

-----Original Message-----
From: Steven Sharp [mailto:sharp@cadence.com]
Sent: Wednesday, September 08, 2010 5:41 PM
To: daniel.mlynek@aldec.com.pl; sv-ec@eda.org; Arturo.Salz@synopsys.COM
Subject: RE: [sv-ec] are constraints virtual like?

Arturo,

I agree that constraints act as if they were virtual when used by a
randomize call. This works because randomize() is virtual, and the
constraints are accessed by randomize(). Since randomize() is virtual, you
will call the one for the actual object type. And that randomize() will
access the constraints that are visible in that object type.

But Daniel's question was actually about calling constraint_mode. It does
not appear to me that this will act in a virtual fashion.

First of all, the LRM does not say that constraint_mode is virtual.
Note that it explicitly states that randomize() is a virtual method, and the
pseudo-prototype for randomize() has the virtual qualifier.
It does not state that constraint_mode is virtual, and the pseudo- prototype
for constraint_mode does not have the virtual qualifier.

Second, I don't think that it would matter if the LRM made constraint_mode
virtual anyway, given the syntax and the conceptual model. The syntax is
handle.constraint.constraint_mode(). Conceptually, a member select is
applied to the handle to select a constraint, and then the constraint_mode
method is called on that. By the time the method is called, a particular
constraint has been selected using the member select, which will use the
type of the class handle, not the class object. Once that particular
constraint has been selected, you are committed, before the method is
called.

The form where constraint_mode is called on the entire object, with the
syntax handle.constraint_mode(), could be treated as virtual. In that case
the method is being called directly on the class handle. So you could have
that affect the constraints in the actual object type. But then this would
be inconsistent with the other form. It would be confusing if calling
handle.constraint_mode() were not equivalent to calling
handle.constraint.constraint_mode() for each constraint in the object.

To get a virtual mechanism for constraint_mode(), you would need to have the
member select of the constraint itself be virtual, so that the constraint
was selected based on the actual object type, before the method was called.
There is nothing in the LRM to indicate that this is the case.

The situation is similar for rand_mode(). You have the syntax
handle.variable.rand_mode(). Again, this is a member select followed by a
built-in method call. So the variable has already been selected based on
the handle type, before the method is called. For member selects that
select a property, we definitely know that the select is not virtual.

So I think the answer to Daniel's question is that constraints are not
virtual. When they are accessed from randomize(), which is virtual, it
doesn't matter that they aren't virtual. You get the same behavior anyway.
But when they are accessed with a member select from a handle, so that you
can then apply the constraint_mode() method to them, you do not get virtual
behavior.

You can create a virtual mechanism by writing your own virtual methods, one
for each constraint, which calls constraint_mode() on that constraint.

Steven Sharp | Architect | Cadence

P: 508.459.1436 M: 774.535.4149 www.cadence.com

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.