Subject: Voting on ISSUE 1.6 - My Ballot
From: Stickley, John (john_stickley@mentorg.com)
Date: Fri Nov 22 2002 - 15:50:44 PST
o Ballot
The ballot is due by Friday midnight (US Pacific). Please mark your
vote by 'Y' (Yes), 'N' (No) or 'A' (Abstain). Comments are welcome
but DO NOT INTER-PARSE YOUR COMMENT WITH THE BALLOT - add it at the
end. Please cut-paste the following in your reply.
----------------------- Ballot --------------------------------------
(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. N *
b. N *
c. Y
(5)
a. Y
b. Y
(6)
a. Y
b. A *
c. Y
(7) Y
(8) Y
(9) Y
(10)
a. Y
b. Y
c. Y
(11) a. Y
b. Y
c. Y
d. Y
(12) Y
(13) a. Y
b. Y
(14) Y
(15) NO VOTE ON THIS ITEM - withdrawn.
(16) Y
(17) Y
----------------------- Ballot --------------------------------------
Comments:
-------------------------------
Item 4a:
I agree with Kevin that this may be hard to verify since an SV
compiler may have little control over what C code does and what acces modes
are valid from what C functions. How does the checking code know from
what disqualified C functions access is being attempted ?
My take is to not care if VPI/PLI access is done from C functions or not.
It seems to me that if optimization is wanted a global mechinism similar
to the current Verilog +access+rw option is adequate. Trying to do
it on a function by function basis is difficult and adds unecessary
complexity to implementations.
-------------------------------
Item 6b:
I'm abstaining on this. It seems that if we require the extern
to preceed it's use, it lessens the need for more compiler passes
and can help encourage simpler, more efficient compiler implementations.
But I don't feel that strongly.
This archive was generated by hypermail 2b28 : Fri Nov 22 2002 - 15:54:36 PST