RE: [sv-bc] Which expressions can be condition of an if?

From: Rich, Dave <Dave_Rich_at_.....>
Date: Thu Oct 26 2006 - 08:38:18 PDT
This is a singular type.

> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
On
> Behalf Of Brad Pierce
> Sent: Thursday, October 26, 2006 8:16 AM
> To: sv-bc@server.eda.org
> Subject: [sv-bc] Which expressions can be condition of an if?
> 
> >The second problem I have that I need a generic name for all types
> whose data
> >can be used as a condition of an if statement.
> 
> Must the expression in an if condition be of an integral type?
> 
> -- Brad
> 
> -----Original Message-----
> From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
> Sent: Thursday, October 26, 2006 12:09 AM
> To: Rich, Dave; Brad Pierce; sv-ac@eda-stds.org
> Subject: RE: [sv-ac] Enhancements submitted
> 
> Hi Dave,
> 
> Unfortunately I found nothing in LRM which would explicitly state that
> type reference returns the most specialized type. Moreover, the type
> reference may be used for parameter declaration, so it should be known
> at the compile time and thus cannot be polymorphic. Although
properties
> and sequences are inlined at the elaboration time, it does not look
> natural to allow the compile-time polymorphism only.
> 
> The second problem I have that I need a generic name for all types
whose
> data can be used as a condition of an if statement.
> 
> Thanks,
> Dmitry
> 
> -----Original Message-----
> From: Rich, Dave [mailto:Dave_Rich@mentor.com]
> Sent: Thursday, October 26, 2006 8:54 AM
> To: Korchemny, Dmitry; Brad Pierce; sv-ac@server.eda-stds.org
> Subject: RE: [sv-ac] Enhancements submitted
> 
> Dmitry,
> 
> We have a similar issue with type matching of classes and their
derived
> sub-classes. (The issue is the sv-ec forgot to define it).
> 
> If you have
> 
> class animal;
> ...
> endclass
> class cat extends animal;
> ...
> endclass
> 
> All cats are animals, but not all animals are cats. You can create
> handles of different types and compare them
> 
> animal A;
> cat C;
> C = new();
> A = C;
> 
> if (A == C) ...
> // this is a comparison of two different types that have be cast into
a
> common type
> 
> You could do the same thing with Boolean -> sequence -> property. All
> Booleans are properties, but not all properties are Booleans.
> 
> So if you have an formal argument 'property p', then type(p) would
have
> to return the most specialized type it can for the actual argument p.
> 
> Dave
> 
> 
> > -----Original Message-----
> > From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
> > Sent: Wednesday, October 25, 2006 12:49 AM
> > To: Rich, Dave; Brad Pierce; sv-ac@server.eda-stds.org
> > Subject: RE: [sv-ac] Enhancements submitted
> >
> > Hi Dave,
> >
> > I like your idea, but it requires a completely new definition of
> > 'matching'. There are two points here:
> >
> > 1. Access to the actual data type. E.g., a formal argument of a
> property
> > may be of type 'property' (it does not exist in LRM yet, but there
is
> an
> > enhancement request #1549 by Lisa Piper to introduce types property
> and
> > sequence), while the actual argument may be 'logic'. If I understand
> > correctly, type(a) will return the type of the formal argument,
i.e.,
> > 'property'.
> >
> > If we want to introduce the notion of the actual data type, should
we
> > limit it to properties/sequences only or extend it also for tasks,
> > functions, modules, etc.?
> >
> > 2. We need a notion of cast compatibility, not just matching. This
> > relation is not symmetric.
> >
> > What do you think?
> >
> > Thanks,
> > Dmitry
> >
> > -----Original Message-----
> > From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org]
> On
> > Behalf Of Rich, Dave
> > Sent: Tuesday, October 24, 2006 11:39 PM
> > To: Brad Pierce; sv-ac@server.eda-stds.org
> > Subject: RE: [sv-ac] Enhancements submitted
> >
> > Brad,
> >
> > I forgot that we added that section, but that still does not prevent
> > defining a 'match' as I had originally suggested for these new types
> to
> > get the functionality that Dmitri wants.
> >
> > It certainly eliminates the need for $isreal and $istring and could
be
> 
> > extended to work for signed or packed.
> >
> > Dave
> >
> > > -----Original Message-----
> > > From: owner-sv-ac@server.eda.org
[mailto:owner-sv-ac@server.eda.org]
> > On
> > > Behalf Of Brad Pierce
> > > Sent: Tuesday, October 24, 2006 2:25 PM
> > > To: sv-ac@server.eda-stds.org
> > > Subject: RE: [sv-ac] Enhancements submitted
> > >
> > > Comparisons between type references don't use equivalence, but
> > matching
> > > --
> > >
> > >    "Two type references shall be considered equal in such
> comparisons
> > > if, and only if, the types to which they refer match (see 6.9.1)."
> > >
> > > -- Brad
> > >
> > > -----Original Message-----
> > > From: Rich, Dave [mailto:Dave_Rich@mentor.com]
> > > Sent: Tuesday, October 24, 2006 12:08 PM
> > > To: Korchemny, Dmitry; Brad Pierce; sv-ac@eda-stds.org
> > > Subject: RE: [sv-ac] Enhancements submitted
> > >
> > > Dmitry,
> > >
> > > Type equality rules use equivalence, not strict matching; so
type(q)
> 
> > > could be equivalent to both a property and a Boolean.
> > >
> > > Dave
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: owner-sv-ac@server.eda.org
> [mailto:owner-sv-ac@server.eda.org]
> > > On
> > > > Behalf Of Korchemny, Dmitry
> > > > Sent: Tuesday, October 24, 2006 10:40 AM
> > > > To: Rich, Dave; Brad Pierce; sv-ac@server.eda-stds.org
> > > > Subject: RE: [sv-ac] Enhancements submitted
> > > >
> > > > Hi Dave,
> > > >
> > > > Unfortunately we cannot. Consider the example from #1646
> > > >
> > > > property weak_until ( property p , property q ) ;
> > > > 	generate if ( $isboolean ( q ) )
> > > > 		! q [ *1 : $ ] |-> p ;
> > > > 	else
> > > > 		q or ( p and ( 1 ' b1 j=> weak_until ( p , q ) )
) ;
> > > > 	endgenerate
> > > > endproperty
> > > >
> > > > If we query the type of q, we'll get 'property'. We need to know
> > > whether
> > > > this is a combinatorial property, i.e., actually a Boolean
value.
> If
> > > it
> > > > is - then a more efficient implementation is possible, as shown
in
> > > this
> > > > example.
> > > >
> > > > I.e., I need to know not the actual type of an argument, but the
> > > ability
> > > > to reduce the actual argument type to a simpler type: sequence
to
> > > > Boolean and property to sequence or to Boolean.
> > > >
> > > > These query functions I suggest, are useful in properties only
in
> > > > conjunction with the generate constructs, therefore I had to
> > introduce
> > >
> > > > these two enhancements simultaneously.
> > > >
> > > > Thanks,
> > > > Dmitry
> > > >
> > > > P.S. The example I talked was missing from the initial version
of
> > the
> > > > file attached to #1646, but now I've uploaded the right version.
> > > >
> > > > -----Original Message-----
> > > > From: owner-sv-ac@server.eda.org
> [mailto:owner-sv-ac@server.eda.org]
> > > On
> > > > Behalf Of Rich, Dave
> > > > Sent: Tuesday, October 24, 2006 7:02 PM
> > > > To: Brad Pierce; sv-ac@server.eda-stds.org
> > > > Subject: RE: [sv-ac] Enhancements submitted
> > > >
> > > > SV already allows expressions like
> > > >
> > > > (type(expr) == real)
> > > >
> > > > These are evaluated at elaboration time and do not evaluate
their
> > > > operands other than to determine their type.
> > > >
> > > > Couldn't we do
> > > >
> > > > (type(expr) == sequence)
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: owner-sv-ac@server.eda.org
> > [mailto:owner-sv-ac@server.eda.org]
> > > > On
> > > > > Behalf Of Brad Pierce
> > > > > Sent: Tuesday, October 24, 2006 9:26 AM
> > > > > To: sv-ac@server.eda-stds.org
> > > > > Subject: Re: [sv-ac] Enhacements submitted
> > > > >
> > > > > Dmitry,
> > > > >
> > > > > Regarding the type query functions of 1647, a few questions --
> > > > >
> > > > >    1)  "is a Boolean expression, i.e., it may be used as a
> > condition
> > > > of
> > > > > a procedural if statement"  But any packed vector could be
used
> as
> > > > such
> > > > > a condition.
> > > > >
> > > > >    2)  Why can't these also be called on a data_type?
> > > > >
> > > > >    3)  Why only these few?  Why not, for example, $issigned,
as
> > > > > discussed in
> > > > >
> > > > >           http://www.eda-stds.org/sv-bc/hm/4866.html
> > > > >
> > > > >        or $isstring, $isreal, etc.
> > > > >
> > > > >    4)  What are the return types?
> > > > >
> > > > >    5)  Do these functions evaluate their arguments?
> > > > >
> > > > >    6)  Can they be called in a constant expression?
> > > > >
> > > > > -- Brad
> > > > >
> > > > >
> > > > > ________________________________
> > > > >
> > > > > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On
Behalf
> > Of
> > > > > Korchemny, Dmitry
> > > > > Sent: Tuesday, October 24, 2006 8:14 AM
> > > > > To: sv-ac@eda-stds.org
> > > > > Subject: [sv-ac] Enhacements submitted
> > > > >
> > > > >
> > > > >
> > > > > Hi all,
> > > > >
> > > > >
> > > > >
> > > > > I submitted three detailed proposals following my
presentations:
> > > > >
> > > > >
> > > > >
> > > > > 1646 - Generate constructs within properties and sequences
> > > > >
> > > > > 1647 - Type query functions
> > > > >
> > > > > 1648 - Default reset for assertions
> > > > >
> > > > >
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Dmitry
> > > > >
> > >
Received on Thu Oct 26 08:38:32 2006

This archive was generated by hypermail 2.1.8 : Thu Oct 26 2006 - 08:38:39 PDT