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

I don't know why modules were singled out, but that has
been the case since IEEE Std 1364-2001.  That's before
I was active in this particular standards effort.

It may be that, at that time, someone noticed that all
the other "parameter" types could only be associated
with modules, and not with scopes in general, and so
added the arrow to "module" for consistency.

It seems a bit odd, since, at least according to the
formal syntax of IEEE Std 1364-2001, it looks like
a parameter could also have been a "generate item".
But perhaps the PTF and BTF were not fully synchronized
back in those days.

At any rate, we now have a number of places in the
object model where we have retained stray relations to
modules for backward compatibility.  You can look at
"36.16 Variable" in Draft 6, for example.  There's
no particular reason, other than backward compatibility,
why the arrow should be there for "module", and no
particular reason, other than the avoidance of unnecessary
clutter, why one couldn't add relations to "program",
"interface", "package", "gen scope", "task func", "class defn",
"class typespec", "class obj", and so on.

So overall, given the balance between simplicity and
backward compatibility, I'd prefer to leave the diagrams
for 742 the way they are.

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 Bresticker, Shalom
]Sent: Tuesday, July 15, 2008 2:49 AM
]To: Chuck Berking; erik.seligman@intel.com
]Cc: sv-cc@eda.org
]Subject: 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.
]
]
]

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