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

As to ports, strictly speaking, we don't need a change.
You'll notice that ports also do not appear in the diagram
for Interfaces.  What we've done instead is to add
"instance" to the object model diagram for "Ports",
and that automatically takes care of interfaces, programs,
and now checkers.

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.