Subject: vote on the 17 items
From: Francoise Martinolle (fm@cadence.com)
Date: Fri Nov 22 2002 - 20:44:07 PST
To: fm, sv-cc@eda.org
From: Francoise Martinolle <fm@cadence.com>
Subject: Vote on Andrzej's 17 items
Stuart and I discussed and reviewed the 17 items. We both vote the same on these
issues. I added some comments on each point at the end of this email.
Some of them explain the reasons for why we are voting NO or Yes with condition
on some items and we hope that these will be taken in consideration by the CC committee.
(0)
a. Y
b. Y
c. Y
d. Y
(1)
a. Y
b. Y
c. Y
(2)
a. Y
b. Y
(3)
(i) Y
(ii) Y
(iii) Y
(iv) Y
(4)
a. Y
b. N
c. N
(5)
a. N
b. N
(6)
a. N
b. Y
c. Y
(7) Y
(8) N
(9) Y
(10)
a. Y
b. Y
c. Y
(11)
a. Y
b. Y
c. Y
d. Y
(12)
a. N
(13)
a. Y
b. Y
(14)
(i) Y
(ii) Y
(iii) Y
(15) NO VOTE ON THIS ITEM - withdrawn.
(16) N
(17) Y
0c) If this means that these details will explicitly be in the spec then the vote is yes.
4b) Don't blur the line between DirectC and VPI. If you want abstract access, use VPI, if you want direct access use DirectC. If you mix the two, you will not get the performance benefits of direct access. We don't like the "specially declared function" to tell that it can
use VPI or access objects outside of the function parameters. The directC interface should
state that if such a function attempts to do this, the behaviour is unspecified by the standard.
4b) This is completely undetectable but a model should be termed "erroneously" if it attempts to do it.
5a) Restricting to the same function name is over-restrictive. Allowing for
a library name/function name pair is going to be required to
support shared libraries. Using a string attribute on the function declaration could
be used to that effect. If no attribute is provided, then the C name should default to the
same SV name.
Formal argument names should not be optional, even though they
really don't mean anything. Their syntax should match SV functions as closely as possible.
6a) This has contradictory statements: only "allowed in $root" and "alternatively may be allowed inside any scope".
We would like to be allowed in any scope as a module may want to refer to a C function and the analysis of this module may need to know that there is going to be an external
dependency to a C function. Also, xf's in modules will be useful to allow OOMR references to a task that is in 'C'.
6c) The whole requirement should only be:"Regular SV name resolving rules apply to xf"
8) Additional optional syntax will be necessary to optionally map to a shared library or alternative 'C' name.
11) 4-State and enums value will have to be added to the minimum list. The directC should
be able to take parameters of the normal Verilog data type system (4 state types reg, integers).
Note that if we don't add the 4 state in the minimum list, then they still can be passed to 2 state formal value parameters by coercing the value to 2 states. The C side will only see
0 and 1 ( can't see X and Z) and can pass back a 2 state value which can be coerced back to
a 4 state value on the SV side.
12) This is an issue that is really for the enhancement committee to add an object with the semantic restrictions proposed for pointer and string. If it is added to the language then we agree that it should be passed 'C'.
13b) The layout of how it appears on the 'C' side must be specified.
16) Unsized arrays are new types that need to be added by the enhancement committee and then they can be used in the 'C' interface. We agree that they are useful.
17) Generally agree with this limitation on the return type as it may simplify the implementation but might want to reword as "any data type that can be returned by host 'C' compiler". For instance on a 64-bit machine, this is overly restrictive.
This archive was generated by hypermail 2b28 : Fri Nov 22 2002 - 20:44:44 PST