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.