Subject: RE: [sv-ec] Chapter 11 feedback
From: David W. Smith (david.smith@synopsys.com)
Date: Fri Feb 07 2003 - 11:02:57 PST
Hi Neil,
You may want to take a look at CH-102 which is the definition of a new type
with SV called "handle". Its use is for the passing of opaque handles
through the C interface and it has been defined by the SV-CC.
There is a relation between these two items and a table similar to what you
propose might help.
Thanks for the other comments. We will cover on Monday.
Regards
David
-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Neil
Korpusik
Sent: Friday, February 07, 2003 10:52 AM
To: sv-ec@eda.org
Subject: [sv-ec] Chapter 11 feedback
Comments on SV LRM 3.1 Draft 2
Chapter 11.
Handles
- There needs to be a more thorough description of what a handle is.
Section 11.23 has the best description but it is inadequate for an LRM.
I have written up such a description for an internal Sun document. I
have included that write-up here for your consideration. Feel free to
correct this write-up if it is in error. This is the level of detail
that I believe should be provided.
System Verilog objects are referenced using a "handle". There are some
differences between a C pointer and a System Verilog handle. C
pointers
give programmers a lot of latitude in how a pointer may be used. The
rules governing the usage of System Verilog handles are much more
restrictive. A C pointer may be incremented for example, but a System
Verilog handle may not.
C pointer SV handle Operation
--------- -----------
---------------------------------------------
Allowed Not allowed Arithmetic operations (such as
incrementing)
Allowed Not allowed For arbitrary data types
Error Not allowed Dereference when null
Allowed Limited Casting
Allowed Not allowed Assignment to an address of a data type
No Yes Unreferenced objects are garbage collected
Undefined null Default value
(C++) Allowed For classes
Section 11.1
- Delete the first two sentences of this chapter, starting with
"System Verilog 3.0..."
Section 11.8
- The examples and the text appear to be inconsistent in their usage
of variable names. There is a mixture of the use of "fileId" and
"semId".
I assume that all 3 should be fileId.
Section 11.9
- In the example: endfunction and endclass should both be in bold.
Section 11.10
- Page 77, 3rd paragraph that begins with "This statement has new
executing
twice, thus creating two objects". The example being referred to is
p2 = new p1;
This doesn't sound right. Doesn't this just create the p2 handle, which
is then initialized to a shallow copy of what the p1 handle refers to?
Section 11.13
- The first paragraph of this section reads:
"The super keyword is used from within a derived class to refer to
properties of the parent class. It is necessary to use super when the
property of the derived class has been overridden and cannot be
accessed
directly."
Is is the property of the parent class that is now hidden. The following
re-write of the second sentence is suggested instead:
"It is necessary to use super to access the parent class properties when
the property of the derived class has been overridden."
Section 11.14
- First sentence of first paragraph. Add the word "a" as shown below:
"It is always legal to assign a subclass variable..."
^^^
- The word "scalar" is used in several places. Based on the discussions
for section 3.14 these should all be changed to the word "singular".
- There are task and function forms of this subroutine. The last two
paragraphs on page 79 refer to both of them as functions. The text
of both paragraphs need to be cleaned up to not imply that there are
two forms of the same function.
- Second to last paragraph on page 79, states that a fatal error will
occur. See the new text from EC-CH28 that should go here.
- First paragraph, page 80, last sentence says, "Otherwise, it sets the
destination handle to null and returns 0.". The text from EC-CH29 goes
here instead.
Section 11.16
- The summary at the end of this section should be completely removed.
This type of stuff belongs in a tutorial.
Section 11.18
- First paragraph, page 82, second sentence reads: "Since the base class
doesn't need to instantiate the base class, it can be declared to be
abstract...".
This needs to be re-worded. Something like the following is suggested:
"Since the base class is not intended to be instantiated, it can be
made abstract by specifying the class to be virtual."
Section 11.20
- Delete the first paragraph.
- First sentence of second paragraph reads: "To make this practical, it is
best to move long method definitions.." The following is suggested in
place of this: "It is convenient to be able to move method
definitions..."
- The keyword public is shown. Do we really need this keyword? I suggest
that we get rid of the keyword public. None of the examples in the
document use it. The default is for class properties to be "public" do
we really need to reserve this keyword so that we can explicitly state
that we really want something to be public?
Section 11.22
- The first line of the example at the bottom of page 84 has a font
problem.
Section 11.23
- Delete the first sentence of the first paragraph.
- Throughout this section there are references to System Verilog 3.1,
can't we just say System Verilog and drop all the 3.1 references?
Section 11.24
- First example uses fork/join, the "join none" should be "join_none".
Note: Feedback on chapter 12 will be forth-coming (perhaps not until after
I get back from a lunch meeting).
Neil
This archive was generated by hypermail 2b28 : Fri Feb 07 2003 - 11:04:03 PST