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

Non-member submission http://www.eda-stds.org/sv-ac/hm/3949.html

-----Original Message-----
From: Doron Bustan 
Sent: Thursday, May 10, 2007 12:06 PM

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.