Subject: RE: [sv-ec] Email Vote 4
From: David W. Smith (david.smith@synopsys.com)
Date: Mon Feb 24 2003 - 13:30:00 PST
Francoise
For CH-103 I checked what Stu actually put in the LRM. It does not include
the (non-packed array) so I have modified CH-103 to match. I will count this
as approved.
For CH-10. You are definitely correct on the realtoa taking a real type. I
too am confiused about the use of integer vs int on the string routines
(both in Appendex C and in Chapter 3). I will look into it and get back with
either a reason or a fix.
Regards
David
David W. Smith
Synopsys Scientist
Synopsys, Inc.
Synopsys Technology Park
2025 NW Cornelius Pass Road
Hillsboro, OR 97124
Voice: 503.547.6467
Main: 503.547.6000
FAX: 503.547.6906
Email: david.smith@synopsys.com
<http://www.synopsys.com/> http://www.synopsys.com
-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Francoise Martinolle
Sent: Monday, February 24, 2003 12:14 PM
To: fm@ctdy075.cadence.com; sv-ec@eda.org
Subject: Re: [sv-ec] Email Vote 4
At 06:29 PM 2/21/2003 -0800, David W. Smith wrote:
Greetings,
The week before DVCon and the reflector is quite....
Just a reminder that there is an active vote being held as indicated below.
I have received two (2) responses. Not a quorom. This is my friendly
reminder to one and all that your vote counts. You have all registered, now
is the time to be counted. Have a good weekend.
Regards
David
The following are the list of changes that need approval. Please consider
each and vote on them.
__yes _X_no 1. Approve CH-10
Why are all the task and functions using the "integer" verilog type rather
than the "int" type?
The integer verilog type holds 4 state values. I think these string methods
ought to work
on int types rather than integer. The purpose of these methods is to provide
the dual functionality which already exists with C strings, correct?
If not, it would be appropriate to detail the conversion which is executed
and
describe what does a X and Z converts to?
realtoa should take real type argument
__yes _X_no 2. Approve CH-102
Would like Cpointer name instead of handle.
Would like to be able to have a C compatible struct contain a Cpointer type
fields, otherwise you cannot construct a C list using the C interface and
pass it back to Verilog.
We should not allow to have packed structs and packed unions contain
Cpointer member fields.
__yes _X_no 3. Approve CH-103
I dont think that the following sentence is correct:
"SystemVerilog allows a subroutine declaration to specify a default value
for each singular (non-packed-array) argument."
because singular does not just mean non-packed array.
If you remove "(non packed array)" I will approve.
_X_yes __no 4. Approve CH-104
I dont understand the row: "for arbitrary data type" in the table of
differences between a C pointer, a handle and a object handle. Does this
mean you can have void * C pointers but no generic SV object or SV handle?
_X_yes __no 5. Approve CH-106
_X_yes _X_no 6. Approve CH-107
_X_yes __no 7. Approve CH-108
Voting on these items will close on Tuesday 25 February 2003. Same voting
rules as last time.
All of these changes (with the exception of CH-108) have been incorporated
into draft 3 even though they have not been approved. We can still make any
corrections required.
I expect that some of these will not pass since there are some significant
changes in response to the action items. I am doing this to prune done the
list of items to the ones that we need to discuss to help focus our time in
meetings. This does include all of the feedback from Chapters 11 and 12 that
were made into changes.
This archive was generated by hypermail 2b28 : Mon Feb 24 2003 - 13:30:55 PST