Subject: Re: [sv-cc] FW: Comments on VPI Extensions to SystemVerilog, December 19,2003 version
From: Francoise Martinolle (fm@cadence.com)
Date: Tue Jan 13 2004 - 07:38:18 PST
Correction on the comments from Stuart on the default lifetime:
Declaring a default lifetime for variables declared in task, functions and
procedural blocks has not been removed. Default is static and can be
changed to automatic by putting the automatic keyword
on the module, interface or program.
The LRM changes consisted in moving the description of the default lifetime
from section 10.4 to section 5.5 which is a more genral section because
variables can now be declared in procedural blocks. So there is still a
default lifetime for module, interface and programs.
See ERR 63 and LRM 118.
Francoise
'
At 09:24 AM 1/13/2004 -0500, Ghassan Khoory wrote:
>-----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 - 07:39:19 PST