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

>If a tool needs to have an attribute or some other manner of specifying
tighter
>checking, I would suggest talking to the vendor(s).

But then why define standards?  

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?

   2)  Why 'protected'?  Why not 'matches'?

   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
              
-- Brad

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Gordon Vreugdenhil
Sent: Wednesday, May 09, 2007 7:02 AM
To: Bresticker, Shalom
Cc: sv-ac@eda.org; sv-bc@eda.org; sv-ec@eda.org
Subject: Re: [sv-ec] Mantis 1804 (Enhancement) : Add abiltiy to require
equiv types for typed formal args



Bresticker, Shalom wrote:
> I think the idea is to be able to do this in a specific place in the 
> code, not globally.

I understand that.  I still think that this belongs in the tool side
since the only justification for it is tighter error checking.
If a tool needs to have an attribute or some other manner of specifying
tighter checking, I would suggest talking to the vendor(s).

Along the same lines, the committees have consistently declined to add
required support for assignment range checking, etc. into the LRM.

Gord.


> Shalom
> 
>> -----Original Message-----
>> From: Gordon Vreugdenhil [mailto:gordonv@model.com]
>> Sent: Wednesday, May 09, 2007 4:50 PM
>> To: sv-ac@server.eda.org
>> Cc: Bresticker, Shalom; sv-bc@server.eda.org; sv-ec@server.eda.org
>> Subject: Re: [sv-ec] Mantis 1804 (Enhancement) : Add abiltiy to 
>> require equiv types for typed formal args
>>
>> My initial inclination is that this should be a tool specific lint 
>> feature.  There is no end to features that could be used to tighten 
>> up semantics for debug purposes and I think that in most cases such 
>> features end up adding additional cross-functional interactions that 
>> render the language more complex to describe consistently in the LRM.
>>
>> Gord
>>
>>
>> Bresticker, Shalom wrote:
>>> Hi,
>>>
>>> FYI.
>>>
>>> Mantis 1804 (Enhancement) was filed under SV-AC:
>>>
>>> Add abiltiy to require equiv types for typed formal args
>>>
>>> It is desired to have a type qualifier, protected, that will require

>>> that actual args have an equivalent type as the formal argument 
>>> declaration.
>>>
>>> It is also desired that this qualifier can apply to the 
>>> property/sequence as a whole or to the individual arguments.
>>>
>>> Strict typing makes debug much easier but is inconsistent with
>> function
>>> and task default argument passing. The mechanism defined in this 
>>> proposal could potentially be extended to tasks and functions.
>>>
>>> There is no proposal yet.
>>>
>>> Shalom
>>>
>>>
>>>
>>> --
>>> This message has been scanned for viruses and dangerous content by 
>>> *MailScanner* <http://www.mailscanner.info/>,
>> and is
>>> believed to be clean.
>> --
>> --------------------------------------------------------------------
>> Gordon Vreugdenhil                                503-685-0808
>> Model Technology (Mentor Graphics)                gordonv@model.com

--
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


-- 
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.