Subject: [sv-cc] FW: Comments on VPI Extensions to SystemVerilog, December 19,2003 version
From: Ghassan Khoory (Ghassan.Khoory@synopsys.com)
Date: Tue Jan 13 2004 - 06:24:11 PST
-----Original Message-----
From: Stuart Sutherland [mailto:stuart@sutherland-hdl.com]
Sent: Tuesday, January 13, 2004 4:49 AM
To: sv-cc@eda.org
Cc: david.smith@synopsys.COM; Ghassan.Khoory@synopsys.COM
Subject: Comments on VPI Extensions to SystemVerilog, December 19,2003
version
All,
I am impressed with the great job the CC committee has done! The proposed
enhancements to the VPI diagrams are well organized and thought out. I do
have a few "nits" that are mostly minor corrections, though a couple of my
observations may require a little more work.
I'm sorry to not have provided this feedback sooner, but I did not receive
the request to review the proposal until late last week, when I was
inundated with getting the 3.1a draft 3 competed.
Stu
-------------
General comments (affects several diagrams)
- The "clocking domain" object should be renamed to "clocking block". This
was a global change made in draft 3 of the 3.1a LRM.
- There is an inconsistency in the object name for modports. Some times it
is "mod port" (two words) which would require a constant called vpiModPort
(with a capital p). Other times it is "modport" (one word) which would
require a constant called vpiModport (lowercase P). Since the SV keyword is
one, I suggest the object name should also be one word.
- There is an inconsistency in the object name for reference objects. Some
times it is "ref obj" (two words) which would require a constant called
vpiRefObj (with a capital O). Other times it is "refobj" (one word) which
would require a constant called vpiRefobj (lowercase o). I suggest the
object name should also be two words.
Instances Diagram
- The "default lifetime" property may not be necessary. I think the ability
to declare modules, interfaces and programs and "automatic" has been removed
in draft 3 of 3.1a.
Program Diagram
- How does one access declarations and processes within a program?
Module Diagram
- "reg" and "reg array" objects are missing. I did not compare this diagram
to 1364-2001 to see if any other objects might be missing. That comparison
needs to be done.
Interface TF Decl Diagram
- The "access type" property lists what I assume are 4 return values for
"vpiAccessType". These return values should be in the form of a note,
rather than listed under the property.
- The 4 types of tasks/functions listed are vpiExport, vpiImport,
vpiForkJoin and vpiExtern. What does vpiAccessType return if a task or
function is not declared as any of these?
- The note references vpi_iterate(vpiTaskFunc), but there is no "task func"
object in the diagram.
Modport Ports Diagram
- The object "modportport" should be "modport port". The space is required
in order to have a constant name of "vpiModportPort", as is used in note 1
of the Ports diagram.
- The object "refobj" should be "ref obj". The space is required in order
to have a constant name of "vpiRefObj", as is used in note 5 of the Ports
diagram.
- Notes 1 and 2 reference "Highcomm" (with m's). This should be "high conn"
or "vpiHighConn".
Ref Obj Diagram
- As noted in the general comments, above, there is inconsistency in the use
of "refobj" and ref obj", and their corresponding constants.
- There appears to be two access methods to go from "ref obj" to the second
"ports", "vpiLowConn" and "vpiPortInst". These two methods should be split
apart, with each going to a separate "ports" object. This is just like it
is already split between vpiHighConn and vpiLowConn.
- The unnamed class contains "reg" in a dotted enclosure. If the dotted
enclosure is correct, then the object name should be "regs" (plural). If
the "reg" name is correct, then the enclosure should be solid.
- The unnamed class contains "variable" in a dotted enclosure. This object
name should be "variables" (plural).
- The text describing the example, and comments within the example, should
bold all constant names.
- The example comments use equal signs, which makes it look like the comment
is describing an assignment statement. For example "vpiHighConn = vpiRegObj
...". I suggest "=" be replaced with the word "is".
Variable Diagram
- The object "short int var" should be "shortint var". The SV keyword is
"shortint" without a space.
- The object "long int var" should be "longint var". The SV keyword is
"longint" without a space.
- The object "short real var" should be "shortreal var". The SV keyword is
"shortreal" without a space.
- The objects "logic var" and "bit var" do not belong in this diagram.
These objects have the same access methods and properties as "reg", which is
quite different than variables. In fact, the logic type is a synonym for
the reg type. It does not make sense to treat logic and reg differently.
It would be very simple to just duplicate the regs diagram twice, once for a
"logics" class and once for a "bits" class. It would also be possible to
make a single diagram that contains "reg", "reg bit", "logic", "logic bit"
"bit" and "bit bit". This would take more work, but should be possible to
do in a clean and readable manner. Note that correcting this diagram will
affect other diagrams that reference either "variables" or "regs" objects.
- I don't like to think of myself as stupid, but I cannot make heads or
tails out of the "variables" class object. There appears to be another name
for the same class at the bottom of the class. Nor do the diagonal access
methods for vpiBit and vpiParent going between the two names for the same
class make any sense. This diagram is somewhat non-conventional from all
other diagrams. It needs to be redrawn using the VPI diagram conventions.
- What data types are the properties "vpiMultiPacArray" and
"vpiConstantVariable"?
- For the properties "vpiPacArray" and "vpiMultiPacArray", it would be more
readable and consistent with VPI naming conventions to spell out "Packed".
- The structure diagram has a property "vpiPacked". Could this same
constant be used for the "packed array" boolean property (instead of
"vpiPacArray")?
- The "randomization type" property has "can be vpiRand, vpiRandC,
vpiNotRand". This should be moved to a note, rather than listed with the
properties.
- The constant "vpiRandC" should be "vpiRandc", since the keyword is
"randc", without a capital C.
- Notes 11 and 12 say "...adds a property..."? This does not make sense to
me. I suspect the intent is to say "...returns the constant...".
- Note 13 has a spurious ":" at the beginning of the sentence.
Typedef Diagram
- Should the "field" object be in bold text?
- There is text in the properties listed under the typdef object that should
be moved to the notes section.
- There seems to be properties "array", "signed" and "name" under the
typedef object, but there are no constants for these properties, and no data
types.
- Under the "field" object, there seems to be the property "name", which is
access with the constant vpiTypeDefType. This makes no sense to me. I
suspect something is missing in the list of properties.
Class Object Definition
- Note 2 should change the weak wording "Should not call..." to "It shall be
an error to call...".
Class Variables diagram
- The access method listed to go from "class var" to "variables" (plural) is
"vpiVariable" (singular). Is this intentional? If the correct access
method is "vpiVariables", then it should not be listed in the diagram
because it is the same as the object name.
- The access method "vpiClassDefn" should not be listed in the diagram
because it is the same as the object name.
- The property "Class type" should be "class type" (not capitalized).
- There seems to be 3 different constants to access the same property "class
type". Each constant should be listed as a different property. Is the
intent here that "vpiMailbox" and "vpiSemaphore" are not properties, but
rather return values for "vpiClassType"? If return values, then they should
be listed in a note, rather than under the properties. If return values,
what does "vpiClassType" return if the class is neither a mailbox nor a
semaphore? If "vpiMailbox" and "vpiSemaphore" are properties, what integer
value do they return?
- The property "access type" also has several constant names listed. Are
some of these constants supposed to be return values for "vpiAccessType"?
If so, move them to a note. If all these constants are different
properties, they should be listed under individual names, and the integer
return value for each property needs to be defined.
- Note 1 refers to "vpiWaiting/Process". This should be "vpiWaitingProcess"
(no slash).
- Enum, Enum Constant Diagram
- The name of the object "enum const" is not consistent with the LRM. But
then, the LRM is not consistent, either. The LRM refers to the values
within an enumeration list as either "names" or "labels". I am hoping that
a consistent convention will be chosen for draft 4. The object name in the
PLI diagram should be consistent with what these objects are called in the
LRM.
Named Events Diagram
- The word "new" should be removed from the note.
- The "namedEvent" at the end of the note should be "named event".
Task, Function Declaration Diagram
- What is the return type for the "vpiAccess" method? If an integer, then a
note is needed explaining the return values.
- Note 2 references the constants "vpiInterfaceTask" and
"vpiInterfaceFunction". Are these objects? If so, they are not in the
diagram. Are they properties? If so, how are they accessed.
- Note 3 begins with "For function where return type is a user-defined
type...". This does not make sense to me. I suspect the intent is "For
functions where vpiFuncType is vpi???...". I'm not sure what constants
vpiFuncType returns, so I'm not sure what the constant is for "user-defined
type".
- Note 4 ends with "...even for simple returns". What is a simple return?
Can this clause be deleted from the note?
Alias Statement Diagram
- Should the vpiLhs method be one-to-many? If one-to-one, as shown, how can
the example result in three aliases with the same right-hand side for all
three?
Frames Diagram
- The access method "vpiThread" should not be listed because it is the same
as the object name.
Threads Diagram
- The method constants "vpiFrame" and "vpiThread" (in two places) should not
be listed, since they are the same as the object name being accessed.
Property Spec Diagram
- The double arrows going to the 'variables" object should not be stretched
apart.
- The property "definition location" should have a "->" preceding it.
- The Note has "You cannot get...". This should be changed to "It is not
possible to get...".
Property Expression Diagram
- The "Sequence" class should be "sequence" (lower case). "sequence" should
also be in bold text, as this is the definition of this class.
- I don't understand text above the sequence class that begins with "Note
that the sequence bubble...". Why is this text there?
Sequence Declaration Diagram
- The property names should begin with "->".
Sequence Spec Diagram
- The full class definition of "Sequence" is a duplicate definition.
"sequence" should be in a single small oval (a reference to the definition
that is in some other diagram).
Actual Arg Expr Diagram
- The property names should begin with "->".
Sequence Expr Diagram
- The property "operation type" should begin with "->".
- The text under the "sequence expr" class should be moved to a note. The
operator names and tokens should be listed using their constant names.
Instances Diagram
- The property names should begin with "->".
- There are a number of objects that are in the wrong type of enclosures.
For example, "variables" should be a dotted enclosure.
- The object "taskfunc" should be "task func".
Atomic Statement Diagram
- There is no diagram to define the reference to a "do-while" object. Also,
a dash is not a legal character in C constant names. The object name should
be "do while".
- Where are the increment/decrement operators and all the new assignment
operators covered?
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
503-692-0898
This archive was generated by hypermail 2b28 : Tue Jan 13 2004 - 06:25:24 PST