Subject: Re: [sv-cc] Date: Mon, 24 Mar 2003 13:01:02 -0500
From: Stickley, John (john_stickley@mentorg.com)
Date: Tue Mar 25 2003 - 08:10:03 PST
Michael,
First, the intention of svGetUserDataIdForScope() is that it is
called only once during initialization and the ID is stored
and reused later.
Then, on each call of foo() - when svGetUserData() is called
to get the instance specific user data the user must pass
the combination of the current module scope and the ID
as follows:
MyCModel *me = (MyCModel *)svGetUserData( svGetScope(), ID );
But, this usage is somewhat confusing to the user which
is what my "oops" e-mail alluded to. Tricks have to be played
to store this ID statically for any given function or set
of functions with which it is used. For that reason, in a discussion
I had with Francoise last night, we both agreed that it might
be better to follow the VPI model of associating a context
with a function or task instance rather than a module
instance. (See vpi_get_user_data() in the 1364 LRM).
Second, if, in your example, you're assuming there are 3 calls
to foo() from the same module instance (which is not quite clear
if that's what you intend to show) it is important to remember
that, from a context point of view all 3 of these call share
the same context. We've already discussed this at length: the
context of a function is the scope of declaration not the scope of
the call. I think we generally reached concensus on this as it
is the same in pure Verilog or SystemVerilog.
But, if your example intended to show foo() being called
from 3 different instances of the module containing its
declaration then, indeed this would be 3 distinct contexts.
On the C side they would be distinguished by what svGetScope()
returns.
-- johnS
Michael Rohleder wrote:
> 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 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 \ / ---------
This archive was generated by hypermail 2b28 : Tue Mar 25 2003 - 08:11:06 PST