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

<forwarding bounced email from Doron Bustan>

-------- Original Message --------
Subject: Re: [sv-ac] RE: [sv-ec] Mantis 1804 (Enhancement) : Add abiltiy to require equiv types for typed formal args
Date: Thu, 10 May 2007 14:05:57 -0500
From: Doron Bustan <dbustan@freescale.com>
To: Brad Pierce <Brad.Pierce@synopsys.com>
CC: sv-ac@eda.org, sv-bc@eda.org, sv-ec@eda.org

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.