RE: [sv-ac] RE: [sv-ec] Mantis 1804 (Enhancement) : Add abiltiy to require equiv types for typed formal args

Hi,

 Some time ago I suggested to define a partial order on types based on
type compatibility. This could be used together with elaboration-time
assertions to enforce type-checking rules the designer of a property /
sequence wishes to have, by just pacing such checks in the property /
sequence. It would require that "sequence" and "property" be considered
as a type.
assert (type(arg) <= sequence) else $error("invlaid type for arg");

ed 

> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On 
> Behalf Of Rich, Dave
> Sent: Thursday, May 10, 2007 7:04 PM
> To: Doron Bustan; Brad Pierce
> Cc: sv-ac@eda.org; sv-bc@eda.org; sv-ec@eda.org
> Subject: RE: [sv-ac] RE: [sv-ec] Mantis 1804 (Enhancement) : 
> Add abiltiy to require equiv types for typed formal args
> 
> Doran,
> 
> Can you point me to the proposal that added formal argument types to
> seq/props?
> 
> It's seems that sv-ac is doing a reversal from the completely un-typed
> arguments of 1800-2005 to the strongly typed arguments. Are there good
> reasons for having both? Are there new requirements or are there just
> different committee members? Degree of type checking is more a
> philosophical issue than technical.
> 
> It might be possible to use ref arguments for stronger type checking
> arguments. We use ref arguments for modules, which are not in a
> procedural context. We loose the direction, but we could easily add
> const ref for that purpose.
> 
> Dave
> 
> 
> 
> > -----Original Message-----
> > From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org]
> On
> > Behalf Of Doron Bustan
> > Sent: Thursday, May 10, 2007 12:06 PM
> > To: Brad Pierce
> > Cc: sv-ac@server.eda.org; sv-bc@server.eda.org; sv-ec@server.eda.org
> > Subject: Re: [sv-ac] RE: [sv-ec] Mantis 1804 (Enhancement) : Add
> abiltiy
> > to require equiv types for typed formal args
> > 
> > Hi Brad and all,
> > 
> > first , let me apology to the sv-bc, sv-ec people. On our sv-ac
> meeting
> > I got an action item to update you on this proposal. I 
> guess I wasn't
> > fast enough.
> > 
> > Two general comments:
> > 
> > 1. In general, we imagine that the protected "mode" will be used
> mostly
> >    in libraries, where the user who instantiates them, does not care
> about
> >    their implementation.
> > 
> > 2. This proposal is part of an effort to define arguments passing in
> SVA.
> >      Since SVA is not a procedural language, "passing by reference"
> and
> >      "passing by value", do not fit. There is an existing draft that
> >      defines arguments passing in SVA at  mantis 1549.
> > 
> > 
> > Now for Brad comments:
> > 
> > 
> > > On the other hand, if one wants strong typing for bit 
> vectors, can't
> one
> > > already use enum types? -- for example,
> > >
> > >    typedef enum logic [N-1:0] {T_dummy} T;
> > >
> > > Three questions about the proposal --
> > >
> > >    1)  Why just equivalence?  Why not matching?
> > >
> > we think that even in protected mode, it should be legal to pass
> > actual arguments as bit-select (with no defined type), or different
> > range than formal
> > argument, which have equivalent types.
> > 
> > For example, if R is of type logic [8:1], we think that
> > R should be allowed yo pass to formal argument of type logic [0:7],
> and
> > R[6:5] should
> > be allowed to pass to formal argument of type logic [1:0].
> > 
> > >    2)  Why 'protected'?  Why not 'matches'?
> > >
> > Since we do not want match type, 'matches' is confusing.
> > 
> > >    3)  Why not instead add a shorthand syntax to declare 
> a strongly
> > > typed bit vector data type in terms of enums as above, but leaving
> the
> > > dummy label anonymous?
> > >
> > > Regarding 3, we should also add a general way to declare 
> enum types
> > > without creating labels, for example,
> > >
> > >              enum logic [3:0] {[0:P-1]} T;
> > >
> > > The following is (and should continue to be) illegal, because the
> ranges
> > > for enum labels must use literals
> > >
> > >              enum logic [$clog2(P)-1:0] {label[0:P-1]} T;
> > >
> > > But if the labels were anonymous, that restriction would be
> unnecessary,
> > > and parameters and genvar iterates would be OK in such ranges.  A
> > > label-free enum type would still be usable with enum methods and,
> for a
> > > default encoding, even with casting syntax --
> > >
> > >      case (e)
> > >        T'(0): ...;
> > >        T'(1): ...;
> > >         ...
> > >      endcase
> > >
> > >
> > For several reasons:
> > 
> > 1. It will not allow compound protected types like struct.
> > 
> > 2. we want equivalent types.
> > 
> > 3. even if the writer of the instance of the property will bother to
> > define a special type
> >     using enum, it is not likely that the user who instantiate the
> > property will do that because,
> >     it will make the code very long.
> > 
> > regards
> > 
> > Doron
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > --
> > This message has been scanned for viruses and
> > dangerous content by MailScanner, and is
> > believed to be clean.
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> 
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.