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

Chuck, on the other hand, I don't see the rationale for
creating a separate "vpiCheckerInstance" type.  We don't
do it for modules, interfaces, or programs, even though
each can have multiple instances.  It seems to be enough
to have vpiDef* properties for the definition part.  In
what way are checkers different?

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.