Minutes
of the
This
is my list of attendees and voting status. Please submit corrections:
(aaaaaa________) Johny
Srouji (Intel) *
(aaa__aaa_aaaaa) Cliff
Cummings (Sunburst Design) *
(_a___aaaaaaaaa) David
Smith (Synopsys)
(aaaaaaaaaaaaaa)
(aaaaaaaaaaaa_a) Kevin
Cameron (NSC) *
(_a_aaaaaaaaa_a) Steven
Sharp (Cadence) *
(a___aaaaa_aaa_) Dennis
Brophy (Model Technology) *
(__a__a___aaaa) Tom Fitzpatrick (Co_Design)
(aa_aaaaaa____a) Gord Vreugdenhil (Synopsys) *
(aaaaaaaaa_____) Brad
Pierce (Synopsys) *
(aaaaaa_a____aa)
(aaa_aa_______a) Don
Mills (LCDM Engineering) *
(______aa__aa__) Mike
McNamara (Verisity)
(________aaaaaa) Stefen Boyd (Boyd Technology)
(___a_____aa___) Medi Mohtashemi (Synopsys)
(_________aa___) Paul
Graham (Cadence)
(___a_____aaaaa) Peter
Flake (Co_Design)
(_________aaaa_) Simon
Davidmann (Co_Design)
(_________aa__a) Heath
Chambers (HMC)
(__________aaa_) Dave
Kelf (Co_Design)
(_a_a_______aaa) Vasisilios Gerousis (Seimens)
(aaa_a_________) Dan
Jacobi (Intel) *
(___a__________)
Stuart Swan (Cadence)
(___a__________)
Adam Krolnick
(aaaa__________) David
Rich (Synopsys) *
(___a__________)
Yong Xiao (Synopsys)
(aa_a__________) Jay
Lawrence (Cadence) *
(a__a__________) Matt
Maidment (Intel)
(___a__________)
Wolfgang Keil (Synopsys)
(__a___________)
Alec F. Stanculescu (Fintronic)
*
indicates eligible to vote on consensus issues
Minutes
After these corrections, Karen
seconds. No opposed.
1.
Interface scheduling
2.
Interface Usage
3.
Modports
4.
Reference (opaque pointer) mechanism for use with C interface.
5.
Data alignment
The first three items
have been placed in a delayed status. SV-EC will need to review these at the
next meeting and make a decision as to what to do with them. For now they are
not part of 3.1.
Regarding data alignment,
it was agreed that its definition is not clear. The question raised was do we
have anyone who wants to champion the need for packed arrays of real numbers? No
actions were scheduled and we will wait for a champion. The issue is
whether real numbers can go into packed arrays. No further actions are required
from sv-ec at this stage.
On the Opaque Pointer mechanism, Karen
moves that Kevin is the main driver will take the ownership to be the champion
in the ec committee. Kevin will also figure out what
needs to be done.
2-state C data type,
usually an 8 bit signed integer (ASCII) or a short int
(Unicode).
The issue was
documented by Jay Lawrence as follows (the issues were documented with char
being an 8-bit (ASCII) or a 16-bit (Unicode) character):
3.1) Making char an 8-bit type makes byte
redundant.
3.2) If char is 8
bits, how does one specify a Unicode string literal?
3.3) If
the string type is defined as an array of char then the run-time will have to
provide two string implementations, an ascii and a unicode.
3.4) There
is no standard mechanism (in the language) that allows users to specify ascii or unicode.
3.5) Can one simulation
contain both unicode and ascii char's? If so how do users specify
which, and what are the conversion rules, if any? It seems that leaving
the unicode type unspecified closes the door on any
such implementation.
3.6) There's plenty of
legacy code in Verilog that assumes string literals are streams of 8-bit integers.The standard 2001 defines string literals as:
"A string is a
sequence of characters enclosed by double quotes ("") and contained
on a single line. Strings used as operands in expressions and assignments shall
be treated as unsigned integer constants represented by a sequence of 8-bit
ASCII values, with one 8-bit ASCII value representing one character."
3.7) In the SV-CC
committee, the C interface proposes
If these issues are not addressed, most vendors
are likely to provide char as an 8-bit type, which will de-facto standardize
char to be 8 bits.
A related issue is that
nowhere does it define the encoding except to refer to what seems to be UTF-16
(a character represented by 1 or 2 16 bit words). Most of the OpenSource community have adopted
UTF-8 (which can be from 1 to 3 bytes). This is done to provide something that
is compatible with ASCII in size but extensible to the full Unicode character set.
A possibility for handling this. Another option could
be to define char as 8 bits and wchar as UTF-16 or
UTF-8. Another option is we decide that Unicode is NOT
This topics was
summarized by Jay Lawrence. The question raised was whether we want to handle
Unicode as ASCII coding set.
Jay moved that all references to Unicode are
removed. Wording of char and byte will be identical in table 3-1.
The same remark was made
at the SV-BC meeting: as we have identical type definition with two new
keywords. This is very unfortunate but because the bc guidelines are not to remove anything we may have
to leave the System Verilog language like that. Karen will be checking if we
can override this rule for this case. We should know by next meeting.
The new proposed language
is: “2-stace C compatible data type, 8 bit signed integer”. Jay seconds. Decision passed.
Increment decrement proposal:
In Section 7.3:
REPLACE: SystemVerilog also includes the C incrementor
and decrementor operators ++i,
--i, i++ and i-- (provided there is no timing control). These can be
used in expressions without parentheses. These increment and decrement
operations behave as blocking assignments.
WITH: SystemVerilog also includes the C incrementor
and decrementor operators ++i,
--i, i++ and i-- (provided there is no timing control). These can be
used in expressions without parentheses. These increment or decrement
operations behave as blocking assignments.
<new paragraph>
The ordering of assignment operations relative to any other
operation within an expression is undefined.
An implementation may warn whenever a variable is both written and
read-or-written within an integral expression or in other contexts where an
implementation cannot guarantee order of evaluation. For example:
i
= 10;
j = i++ + i--;
è Our next meeting is