[sv-bc] 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.