RE: [sv-cc] Feedback/issues re. #2182 (VPI Checkers proposal)

Jim- Thanks for the additional comments.

As noted, we agree that "checker" and "checker array" do not need appear
in *both* places (the *specific* instance diagrams- 36.4, 36.5, 36.8-
and the general "instance" diagram- 36.9), but I think it is more
semantically informative to leave them in the *specific* diagrams for
checkers, programs, etc, IFF they can't be instantiated in *any*
instance type.  I.e. if there are any restrictions on where they can be
instantiated, I think it best to leave them in the specific diagrams
rather than the instance one.

As to the ports issue, I agree that the ports diagram (36.13) does
address the transition from instances, so I'll retract that item in my
note.  And- now that programs are explicitly allowed to have ports,
there is no need to semantically distinguish instance types for this
reason, it appears.

Two other items of feedback:

1) I do not find "prop formal decl" (mentioned in the "checker" diagram)
anywhere in the VPI model.  Did you mean "property decl" (i.e. in
36.45), or is this a new object being defined here ?

2) I'm concerned about "checker" being qualified as an "atomic stmt",
while at the same time being qualified as a design "instance" (or
instantiation).  I understand what I believe is the motivation (= the
procedural checker instance (?)), but this breaks a lot of semantic
conventions.  E.g. to distinguish an invocation of a task/function- also
an "atomic stmt"- vs. a definition, we have "tf call" vs. "task" or
"function".  We should discuss a possible way to distinguish this case
similarly (hence my earlier suggestion of a possible "checker
instance").

Regards,
Chuck

-----Original Message-----
From: Jim Vellenga 
Sent: Tuesday, July 15, 2008 10:30 AM
To: Chuck Berking; erik.seligman@intel.com
Cc: sv-cc@eda.org
Subject: RE: [sv-cc] Feedback/issues re. #2182 (VPI Checkers proposal)

I agree with Chuck's 1)a) suggestion.  It's not necessary to have the
checker and checker array appear in the diagrams for modules,
interfaces, or programs since they already appear in the instance
diagram.  They are like programs and program arrays in that respect.
And by putting them in the other three diagrams, you add unnecessary
relations to "vpiInterface" and "vpiProgram".

Similarly, since a "checker" is now an "instance", it's not even
necessary to put "checker" and "checker array" in the "checker" diagram,
just as we do not currently have "program" and "program array" in the
"program" diagram.

Regards,
Jim Vellenga

--------------------------------------------------------- 
James H. Vellenga                            978-262-6381 
Software Architect                     (FAX) 978-262-6636 
Cadence Design Systems, Inc.         vellenga@cadence.com 
270 Billerica Rd
Chelmsford, MA 01824-4179
"We all work with partial information." 
----------------------------------------------------------  

]-----Original Message-----
]From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On ]Behalf Of
Chuck Berking
]Sent: Monday, July 14, 2008 6:43 PM
]To: erik.seligman@intel.com
]Cc: sv-cc@eda.org
]Subject: [sv-cc] Feedback/issues re. #2182 (VPI Checkers proposal) ]
]Erik-
]Here is a brief summary of my feedback on #2182 to date:
]
]1) Checker Instances vs. Declarations
]
]   In VPI there is no substantive distinction drawn between an instance
]   of a design unit vs. its definition.  Usually the VPI data model
]context
]   allows this to be easy to resolve: a vpiModule iteration on another
]   vpiModule yields its topmost inner instances of its internal
]hierarchy,
]   while a vpiModule 1-1 transition gives you the immediate "parent"
]module,
]   i.e. implying this one is an instance within that one.  
]Checker units
]   can be both defined within other design units, and/or instantiated
]within
]   them.  How can we tell the difference ?
]
]   I noted, for example, that your 36.9a (new Checker section) includes
]   "checker"s and "checker arrays" as I would expect, but then 
]the 36.9b
]   section (new "Instance" section) also includes these under "instance
]items".
]   Which do we get when we iterate on these ?  How do we tell the
]difference ?
]
]   I suggest the following:
]   a) Removing one or the other references to ("checker"s and "checker
]array"s)
]      [ Are they more like "program"s- which appear only in "instance
]item"s, or
]        the other unit types, which appear in their definition diagrams
]? ]
]   b) I recommend a property to allow telling the difference between a
]checker
]      definition vs. an instance of one, OR, a distinct object (e.g.
]vpiCheckerInstance).
]      [ I have not thought through the implications of adding a new
]object type,
]        but if we consider "source decompilation" a VPI canonical
]application,
]        we need something to distinguish these, IMHO, since the
]semantics are
]        significantly different according to #1900. ]
]
]2) Access to Ports from Checker
]
]   Diagram 36.9a needs an iteration arrow added for "port"s (also, it
]appears
]   that 1800/D6 allows "program" objects to have ports as well, for
]which they
]   are also missing!).
]
]   Correct me if I have misunderstood concepts here, but I find it very
]confusing
]   to consider that checkers can have different semantic behaviors
](across ports),
]   depending on their context (i.e. "static checkers" vs. "procedural
]checkers").
]   In procedural context, they behave like functions (i.e. ports become
]arguments),
]   and static contexts, they behave like module instances (continuously
]assigned).
]
]3) Names for new objects
]
]   I would like SV-CC to consider whether the names chosen that contain
]only "Check"
]   rather than "Checker" are OK.  I think "Check" is perhaps a bit too
]generic, and
]   does not necessarily associate directly with "checker"s.
]
]Regards,
]Chuck Berking
]
]--
]This message has been scanned for viruses and ]dangerous content by
MailScanner, and is ]believed to be clean.
]
]
]

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.