Status Update regarding the following items which were assigned to the SV-EC from SV-BC.

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.

The 4th item needs to have a little more requirement definition as to what is needed but may be able to meet with the existing "pass-by-reference" style mechanism.

SV-EC thinks that 5th item did not seem to be an enhancement request but an issue that should be resolved in SV-BC.

SV-BC members: we need to send a clearer definition of what we require for opaque pointers and explain whether the data alignment issue has landed there. On packed arrays, we need to explain whether there is a reason to have packed arrays of real and where does this requirement come from?

Conclusions:

Issues with Unicode

David Smith thinks the following issue needs to be handled by SV-BC but impacts both SV-EC and SV-CC. Here is Arturo Salz's description of it. This is based on the entry in Table 3-1 of both the 3.0 LRM and the 3.1 LRM Draft1 describing the char type:

    2-state C data type, usually an 8 bit signed integer (ASCII) or a short int (Unicode).

I'll try to document the issues 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 support of the string type as a C "char *", but that will break when Unicode is being used.

If these issues are not addressed, most vendors are likely to provide char as an 8-bit type, which will de-facto standradize 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 supported.

SV-BC members: we need to address this.