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

<forwarding bounced email from daniel.mlynek@aldec.com.pl>

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

   The issue becomes even more important when combined with object
copying - here is another version of the case:

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

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

      task t;
          C c;

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

          c = new this;

          $display(c.con1.constraint_mode());
          c.randomize();

      endtask

endclass

what will be displayed from D::t task and how c.randomize() will work ?

Regards,
Mirek

On 2010-09-09 10:17, Mirek Forczek wrote:
> 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.