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

And while on the subject of the distinctions between modules and other
design elements, a question came up in the last Champions' meeting about
the proposal for Mantis 742.

On page 7 of the proposal, there is an arc labelled vpiParameter between
module and scope on one side and parameters on the other. The question
is why modules are singled out? Why not programs, for example?

Thanks,
Shalom

> -----Original Message-----
> From: owner-sv-cc@server.eda.org 
> [mailto:owner-sv-cc@server.eda.org] On Behalf Of Bresticker, Shalom
> Sent: Tuesday, July 15, 2008 6:49 AM
> To: Chuck Berking; Seligman, Erik
> Cc: sv-cc@server.eda.org
> Subject: RE: [sv-cc] Feedback/issues re. #2182 (VPI Checkers proposal)
> 
> Chuck,
> 
> Forgive me for my limited VPI understanding.
> 
> In #1, with nested modules, a module can also be both defined 
> within another module and instantiated within it. What is the 
> difference?
> 
> And regarding programs, they can also be top-level, 
> implicitly instantiated entities, like modules? Again, what 
> is the difference between them and modules?
> 
> Thanks,
> Shalom
> 
> > -----Original Message-----
> > From: owner-sv-cc@server.eda.org
> > [mailto:owner-sv-cc@server.eda.org] On Behalf Of Chuck Berking
> > Sent: Tuesday, July 15, 2008 1:43 AM
> > To: Seligman, Erik
> > Cc: sv-cc@server.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.
> > 
> > 
> > 
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential 
> material for the sole use of the intended recipient(s). Any 
> review or distribution by others is strictly prohibited. If 
> you are not the intended recipient, please contact the sender 
> and delete all copies.
> 
> 
> --
> This message has been scanned for viruses and dangerous 
> content by MailScanner, and is believed to be clean.
> 
> 
> 
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


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