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
> > >
>