[sv-cc] Corrections to my previous errata + new errata

I think that what I suggested for note 1 is slightly incorrect.
Instead of : If the vpiTypedef is TRUE, then the vpiTypedefAlias shall
return a non null handle which represents a handle to the aliased typedef.
Ex:
typedef enum bit [0:2] {red, yellow, blue} primary_colors;
typdef primary_colors colors;"

change Note 1 to:

if the vpiTypedef is TRUE and the typedef creates an alias of another
typedef, then the vpiTypedefAlias shall return a non null handle which
represents the handle to the aliased typedef.
Ex:
typedef enum bit [0:2] {red, yellow, blue} primary_colors;
typdef primary_colors colors;

If "h1" is a handle to the typespec colors, its vpiType shall return a
vpiEnumTypespec,
the vpiTypedef property shall be true, the vpiName property shall return
"colors", the vpiTypedefAlias shall return a handle "h2" to the typespec
"primary_colors" of vpiType vpiEnumTypespec.
The vpiTypedef property shall be false for h2 and its vpiTypedefAlias shall
return null.

I have a new errata for the same diagram Section 31.12 Typespec.
The iteration on ranges from the voidTypespec should instead be from the
arrayTypespec.

Reagrding the question why I think it would be useful to know if a typespec
is a builtin type is because you would be able to do the distinction
between the "time" Verilog type and an alias of time without requiring to
get the name of the type.

Ex:
typedef time history;

history my_var;

The vpiTypespec applied to a handle of the variable my_var would return a
vpiTimeTypespec.
vpiIPredefined would return FALSE as it is a user defined alias of the time
type. However it just behaves the same as the time type in terms of getting
the value of my_var.

Often this property could be used to determine whether or not you want to
traverse the type further: typically for user defined complex types you
want to traverse the type further.

It is okay if you decide not to add this property as there are some work
arounds.

Francoise
        '

>>Additionnally here are 2 new erratas and a question related to errata #2.
>>Errata #1:
>>--------------
>>Section 31.12 Typespec
>>Note 1 is incorrect:
>>there is not typeSpec to typespec relationship. There is a
>>vpiTypedefAlias relationship
>>There is no vpiTypedefType property. There is instead a vpiTypedef property.
>>I believe that the correct wording should be"
>>
>>If the vpiTypedef is TRUE, then the vpiTypedefAlias shall return a non
>>null handle which represents a handle to the aliased typedef.
>>Ex:
>>typedef enum bit [0:2] {red, yellow, blue} primary_colors;
>>typdef primary_colors colors;
>>
>>If "h1" is a handle to the typespec colors, its vpiType shall return a
>>vpiEnumTypespec,
>>the vpiTypedef property shall be true, the vpiName property shall return
>>"colors", the vpiTypedefAlias shall return a handle "h2" to the typespec
>>"colors" of vpiType vpiEnumTypespec.
>>The vpiTypedef property shall be false for h2 and its vpiTypedefAlias
>>shall return null.
>>
>>
>>
>>
>>
>>Errata #2:
>>--------------
>>We need to have another note specifying that a type is defined as an
>>alias of another type, it inherits the vpiType of this other type.
>>Ex:
>>typedef time my_time;
>>
>>my_time t;
>>
>>The vpiTypespec of the variable named "t" shall return a handle h1 to the
>>typespec "my_time" which vpiType shall be a vpiTimeTypespec.
>>The vpiTypedefAlias applied to handle h1 shall return a typespec handle
>>h2 to the predefined type "time".
>>
>>Question:
>>I am wondering if we shouldn't add a property vpiPredef to determine if a
>>typespec is a predefined type: real, time, realtime, integer, logic,
>>bit... are all predefined Verilog or systemVerilog types. This would
>>allow to differentiate from user define aliases of predefined types
>>without having to get their names.
>>
>>Francoise
>> '
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>At 09:21 AM 4/13/2004 +0300, Srouji, Johny wrote:
>>
>>>We shall work on the Errata list including proposed resolutions that
>>>will go along w/ the LRM to IEEE. We have less than one month (for the
>>>May 21st deadline)
>>>
>>>-----Original Message-----
>>>From: Francoise Martinolle [mailto:fm@cadence.com]
>>>Sent: Monday, April 12, 2004 7:02 PM
>>>To: Srouji, Johny
>>>Cc: sv-bc@eda.org
>>>Subject: Re: [sv-bc] our next tele-call meeting
>>>
>>>What are we going to do during these meetings?
>>>
>>>Francoise
>>> '
>>>At 11:12 AM 4/12/2004 +0300, you wrote:
>>>
>>>
>>>
>>>
>>>
>>>Hi All,
>>>
>>>We shall resume our sv-bc tele-call meetings in two weeks. Please mark
>>>your calendars that our next meeting is scheduled for Monday, April the 26th.
>>>
>>>Thanks,
>>>
>>>--- Johny.
Received on Fri Apr 16 11:16:27 2004