[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.