Re: [sv-bc] Keywords

According to

   http://www.eda.org/svdb/bug_view_page.php?bug_id=0000051

"Although an integer type with a predefined width n is not a packed array,
it matches (see Section 6.8.1), and can be selected from as if it were, a
packed array type with a single [n-1:0] dimension."

And according to E.6.4,

"Note that input mode arguments of
type byte unsigned and shortint unsigned are not equivalent to bit[7:0]
or bit[15:0], respectively, since the former are passed as C types
unsigned char and unsigned short and the latter are passed as C
unsigned int (i.e., svBitVec32)."

-- Brad

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]On Behalf Of Kevin
Cameron
Sent: Tuesday, April 26, 2005 2:20 PM
To: sv-bc@eda.org
Cc: pgraham@cadence.com
Subject: Re: [sv-bc] Keywords


Paul Graham wrote:
Nor is there any reason to recognize "module" as a keyword in a module.
But for the sake of uniformity, it is sacrificed.


Well there is, if you allow nested modules.


When they do, perhaps one lesson to learn from the "config" experience
should be to give words a decent english spelling, e.g., "configure" or


Nobody's complaining about 'endgenerate'.  But keywords like
'bit' and 'byte' will be a problem for some existing designs.

Paul

bit and byte don't have to be considered keywords at all: they can be
redefined as (optional) pre-defined types (typedefs from something less
likely to clash - http://www.eda.org/sv-bc/hm/0838.html).

logic is a similar problem for existing Verilog-AMS users who want to
migrate into SystemVerilog-AMS.

Note: this is in the Issue List, but is marked closed -

 http://www.eda.org/sv-bc/display_3.1a_issue.cgi?issue_num=38

- IMO it shouldn't be marked closed until there is actually an approved
alternative solution, and it's not clear to me how exactly namespaces would
fix the problem.

Kev.