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

<forwarding bounced email from john.havlicek>

-------- Original Message --------
Subject: Re: [sv-ac] RE: [sv-ec] Mantis 1804 (Enhancement) : Add abiltiy to require equiv types for typed formal args
From: John Havlicek <john.havlicek@freescale.com>
Reply-To: john.havlicek@freescale.com

Hi Dave:

My apologies for the delay in responding.

Optional formal argument types for sequences and properties were
added in Mantis 0196.

J.H.

> X-Authentication-Warning: server.eda-stds.org: majordom set sender to owner-sv-ac@eda.org using -f
> X-MimeOLE: Produced By Microsoft Exchange V6.5
> Content-class: urn:content-classes:message
> Date: Thu, 10 May 2007 16:04:10 -0700
> X-MS-Has-Attach: 
> X-MS-TNEF-Correlator: 
> Thread-Topic: [sv-ac] RE: [sv-ec] Mantis 1804 (Enhancement) : Add abiltiy to require equiv types for typed formal args
> Thread-Index: AceTNl2zhK7lpYUVS/q6N6ZB94ZXGwAE+xNg
> From: "Rich, Dave" <Dave_Rich@mentor.com>
> Cc: <sv-ac@eda.org>, <sv-bc@eda.org>, <sv-ec@eda.org>
> X-OriginalArrivalTime: 10 May 2007 23:04:21.0512 (UTC) FILETIME=[8B7EA880:01C79357]
> X-eda.org-MailScanner: Found to be clean, Found to be clean
> X-Spam-Status: No, No
> X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda-stds.org id l4AN4adP000984
> Sender: owner-sv-ac@eda.org
> X-eda.org-MailScanner-Information: Please contact the ISP for more information
> X-eda.org-MailScanner-From: owner-sv-ac@server.eda.org
> 
> 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.