Subject: [sv-ec] Action Items for Dec/16 meeting
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Mon Dec 16 2002 - 02:19:20 PST
MessageDear Committe Members,
My remaining action items for Monday's meeting are itemized below.
Arturo
2) Implication of allowing reg assignment to string.
Assignment of a reg to a string type will be allowed provided a SystemVerilog cast is used:
reg [15:0] twochar = "ab";
string s;
s = string'(twochar); // s now is "ab"
3) Removing unicode from char type.
This is definitely an issue for SV-BC to tackle. Recommendation is to send this request
to the basic committee and see what they resolve
I'll try to document the issues with vhar 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.4) 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.5) 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.6) 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.
4) Gudelines to use system task vs, method
Now that SystemVerilog has classes and method calling syntax (dot notation), it is a natural extension
to add method-like functionality to some built-in types.
Unlike system tasks, built-in methods do not need to be prefixed with a $ because:
a) There is no need for a special prefix $ to avoid collisions with user-defined identifiers
b) The $ allows redefining system tasks via PLI, and that's neither possible (PLI provides no such
mechanism for methods) nor desirable.
c) Method syntax allows extending the language without adding additional keywords or cluttering
the global name space. For example, the identifier size is still available for re-use and definition
by users anywhere in the language.
The guidelines appear to be pretty simple:
1) If a particular task i sjust a side-effect and operates on no specific data the it should be a $task
Examples: $random, $reset, $finish, $stop, ...
2) If a particular task applies to all data-types the it should be a $task
Examples: $display, $unsigned, $signed, ...
3) Conversely, if a particular task applies only to as specific data type then it is best to use a method:
Examples: associative_array.num , dynamic_array.size, and string.len
These are all similar concepts , but they are represent different things. A dynamic array
has a size, an associative array simply contains a given number of items, and a string
has a given length. While we could use $length for all of this, that would be less clear
and more cumbersome to have to add the dimension parameter to all tis one-dimensional
items.
4) If a particular function should be replaced by a PLI call the a $task should be used, otherwise a
method might be a better alternative.
Examples: $random -> users should be allowed to replace with their own
string.len -> users should not replace this (say $length)
4.1) Ability to leave parens off method calls
SystemVerilog should allow users to ommit the parenthesis in functions that takes no arguments.
The reasons for this are:
a) Less typing
b) User does not have to know whether it's a data access or a method call.
c) Optimizing compilers may inline simple function calls, and given that they have no arguments
their semantics would be identical to a data access.
d) Verilog has a precedent for this: system tasks and PLI tasks.
For example: $random( seed ); vs. $random;
This archive was generated by hypermail 2b28 : Mon Dec 16 2002 - 02:19:13 PST