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

<forwarding bounced email from Mirek.Forczek@aldec.com.pl>

-------- Original Message --------
Date: Thu, 09 Sep 2010 10:17:25 +0200
From: Mirek Forczek <Mirek.Forczek@aldec.com.pl>
To: Arturo Salz <Arturo.Salz@synopsys.com>
CC: Steven Sharp <sharp@cadence.com>,
         "daniel.mlynek@aldec.com.pl" <daniel.mlynek@aldec.com.pl>,
         "sv-ec@eda.org" <sv-ec@eda.org>
Subject: Re: [sv-ec] are constraints virtual like?

   Hi,

Please consider the following:

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

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

      task t;
        super.con1.constraint_mode(0);
        this.con1.constraint_mode(1);

        $display(super.con1.constraint_mode());
        $display(this.con1.constraint_mode());
      endtask
endclass

what will be displayed from the D::t task ?
does the super.con1 refer to C::con1 or D::con1 effectively ?
is the C::con1 and D::con1 constraint_mode status storage distinct or is
it the same ?

Regards,
Mirek

On 2010-09-09 04:09, Arturo Salz wrote:
> 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.