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.