Subject: Re: [sv-cc] Date: Mon, 24 Mar 2003 13:01:02 -0500
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Tue Mar 25 2003 - 06:56:05 PST
Hi all,
I am sorry for being a little late on this thread, but I still struggle with my email after my sickness. It's a mess.
What really concerns me is that, even after reading most of the emails of this thread I have no idea how one function call can
identify its actual scope after this has been generated. Let me make a short, high-level example:
Lets assume we have three calls of the function foo() from the SV side:
...
a: foo()
...
b: foo()
...
c: foo()
...
As a result during the initialization the function foo() would be called three times and I would have to call
svGetUserDataIdForScope() during each call to get a new scope handle. When at a later point in time foo() is called again (let's
assume it is b: foo()) how do I know which instance of foo() is actually being called.
Did I completely misunderstood something here? I have the feeling my brain is still not recovered completely ...
Regards,
-Michael
"Stickley, John" wrote:
> Francoise,
>
> You're probably right. And it keeps the explanation simpler.
> The only reason I suggested it was because it was compatible
> with the existing usage and with my proposal that allows one
> to retain the "per-module instance" user data attachment.
>
> But you're right. If applications want to use it in this way
> they simply call svGetUserDataIdForScope() once and use the
> same returned ID for all their imported functions called from a
> module scope.
>
> And end-user applications can do so knowing that they won't
> conflict with ID's used by IP models that may themselves have
> discreetly made their own call to svGetUserDataIdForScope()
> to allocate their own IDs.
>
> I like it !
>
> So, I guess by not special casing ID=0 we keep things really
> simple and don't lose anything. Do you agree ?
>
> Just to clarify, another reason I had suggested the reserved
> ID=0 was as a possible way of handling something you said in
> your original proposal:
>
> Francoise Martinolle wrote:
> > If no ID is used, the svScope user-data is a single whole entity which is
> > shared by all functions.
>
> I guess what we're saying now is that at least one ID is *always*
> used but applications which don't need per-function user data
> association can just share the same one ID. So really there's no
> such thing as using "no ID" is that correct ?
>
> -- johnS
>
> Francoise Martinolle wrote:
> > John,
> >
> > I think that your comment in this paragraph brings up the problem that
> > different users using the same id may get the user-data of each other.
> >
> > Therefore we should recommended that always the user application (whether
> > it is an IP provider of a regular user), requests a unique id from DPI
> > by calling the new function.
> > We don't need to reserve the id 0 for module scope, if the user application
> > does not need different ids for all the functions, it just requests a
> > new id
> > and uses it for all its user data. Reserving 0 for module scope and IP
> > providers only is dangerous if you have 2 or more vendor ip instances
> >
> > in the same module scope.
> >
> >
> > This is the paragraph I am taling about in your write up.
> >
> > - While storage of user data for ID=0 can be combined with storage
> > for specific ID's, it is recommended that vendor supplied C
> > model IP always use allocated ID's and that only end-user
> > applications use ID=0.
> >
> > different
> >
>
> --
>
> This email may contain material that is confidential, privileged
> and/or attorney work product for the sole use of the intended
> recipient. Any review, reliance or distribution by others or
> forwarding without express permission is strictly prohibited.
> If you are not the intended recipient, please contact the sender
> and delete all copies.
> __
> ______ | \
> ______________________/ \__ / \
> \ H Dome ___/ |
> John Stickley E | a __ ___/ / \____
> Principal Engineer l | l | \ /
> Verification Solutions Group | f | \/ ____
> Mentor Graphics Corp. - MED C \ -- / /
> 17 E. Cedar Place a \ __/ / /
> Ramsey, NJ 07446 p | / ___/
> | / /
> mailto:John_Stickley@mentor.com \ /
> Phone: (201)818-2585 \ /
> ---------
--NOTE: The content of this message may contain personal views which are not neccessarily the views of Motorola, unless specifically stated.
___________________________________________________ | | _ | Michael Rohleder Tel: +49-89-92103-259 | _ / )| Software Technologist Fax: +49-89-92103-680 |( \ / / | Motorola, Semiconductor Products, System Design | \ \ _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_ (((\ \>|_/ > < \_|</ /))) (\\\\ \_/ / mailto:Michael.Rohleder@motorola.com \ \_/ ////) \ /_______________________________________________\ / \ _/ \_ / / / \ \
The information contained in this email has been classified as: Motorola General Business Information (x) Motorola Internal Use Only ( ) Motorola Confidential Proprietary ( )
*** This note may contain Motorola Confidential Proprietary or Motorola Internal Use Only Information and is intended to be reviewed by only the individual or organization named above. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination or copying of this email and its attachments, if any, or the information contained herein is prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system. Thank you! ***
This archive was generated by hypermail 2b28 : Tue Mar 25 2003 - 06:56:54 PST