Subject: RE: [sv-cc] Draft 3 of the LRM - errata + questions
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Mon Jan 19 2004 - 14:46:33 PST
David, Stu,
Here are some feedback comments on Draft 3 of the 3.1a LRM.
Regards,
Andrzej
-------
1. Simple errata:
In the second sentence of section 4.8 a phrase
"are the same as for array assignment"
occurs twice; the second occurence should be removed.
2. One of the examples at the end of 4.8 seems incorrect:
reg b[3:1][3:1]; // error: incompatible type
I believe that actually it is a correct actual argument.
The first paragraph of 4.8 says that
"The rules that govern array argument passing by value are the same as for
array assignment."
Formal argument type is: 'int a[3:1][3:1]'.
Since an assignment 'a=b;' is correct, b should be a correct actual
argument, too.
3. Rule 5 in 5.8 "Type compatibility": 'reg' vs. 'logic'.
Question:
are the types 'reg' and 'logic' and the derived types equivalent?
Both 'reg' and 'logic' are 4-state types.
Thus, according to the rule 5 in the definition of type equivalence in
section 5.8, the following two type should be equivalent:
typedef reg [7:0] TYPE_REG;
typedef logic [7:0] TYPE_LOGIC;
Both are packed arrays, all 4-state, all unsigned and both contain the same
number of total bits.
Am I misinterpreting this definition? Are these types really equivalent?
(I would have no problem with this.)
However, if the above types are equivalent, then one may expect that also plain
'reg' and 'logic' would be equivalent.
I failed to find any rule that would render such equivalence; definitely not
the rule 5, since a scalar of type reg/logic is neither a packed array (or is
it?), or a packed structure.
This definition raises another question: is a scalar equivalent to one bit
packed array of same type? (I guess not?)
For example: 'logic a;', 'logic b[0:0];'.
4. Section 19.6, import/export functions/tasks in interfaces.
Second paragraph of 19.6 uses a phrase "task or function defined in the module
does not exactly match that prototype [...]".
Prototype matching is not defined anywhere; does it require identical types
or only equivalent types? (cf. issue ofequivalence of 4-state packed arrays)
Does it require identical names of formal arguments?
SV-CC deliberately did not define rules for the equivalence of signatures
(or function prototypes, whatever terminology is preferred)
of import or export DPI functions (functions with the same cname must have
equivalent signatures) because we believed that DPI should obey general rules
to be defined for the core SystemVerilog. Such rules seem missing in LRM 3.1a
draft 3.
==============================================================================
Andrzej I. Litwiniuk, PhD Principal Engineer VCS R&D
Synopsys, Inc TEL: (508) 263-8056
377 Simarano Drive, Suite 300, FAX: (508) 263-8069
Marlboro, MA 01752, USA
==============================================================================
This archive was generated by hypermail 2b28 : Mon Jan 19 2004 - 14:51:35 PST