>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:16:30 2006
This archive was generated by hypermail 2.1.8 : Thu Oct 26 2006 - 08:17:07 PDT