Subject: Re: [sv-cc] Feedback on revision 0.8
From: Stickley, John (john_stickley@mentorg.com)
Date: Fri Mar 28 2003 - 09:58:49 PST
Thanks Andrzej.
Doug asked me to provide suggested alternate wording for the
paragraph below. I've attempted to do so.
Andrzej Litwiniuk wrote:
> Thanks John for your feedback.
>
>
> The following items had been also caught by Doug and have been corrected
> already:
>
> > -------------------------------------
> > Section 1.2.1 title
> > Did you mean to take out "layer" ? Seems like it should be in there.
> > Same in second paragraph.
> > -------------------------------------
> > Page 34 2nd to last paragraph
> > "an non-context function" --> "a non-context function"
> > "Therefore, a call of non-context --> "Therefore, a call of a
> non-context"
> > -------------------------------------
> > B.1 Include Files
> > The DPI context helper functions have not been updated to match
> > what is in section A.8.3.
> > -------------------------------------
>
>
> These needs to be taken care of:
>
> > -------------------------------------
> > Section 1.3
> >
> > I did not see anything about our decision to allow reserved
> > names as cnames so long as they are escaped.
> >
> > One of the examples should show it also.
> >
> > -------------------------------------
> > A.6.1 end of 1st paragraph
> >
> > "multidimensional" S/B "multi-dimentional
> >
> > -------------------------------------
> > A.8.3 6th paragraph
> >
> > "Note that it is never possible to share user data storage across
> > different contexts. For example, if a Verilog module 'm' declares a
> > context imported function 'f', and 'm' is instantiated more than
> once
> > in the SystemVerilog design, then 'f' will execute under different
> > values of svScope. No such executing instances of 'f' can share
> > user data with each other, at least not using the system-provided
> > user data storage area accessible via svPutUserData(). "
> >
> > Doug, I know this was what you recently added.
> >
> > I'm not sure we need to say this. If a user really wanted to do this
> > they could call svPutUserData() passing the same user data pointer
> > across different contexts. True it cannot be used with the same
> > key/scope. but the user data itself can be re-used. I don't really think
> > this paragraph is necessary. It's probably just going to add confusion
> > for no good reason. Or perhaps it needs to be re-stated with something
> > to the effect of what I've said here.
Warmke, Doug wrote:
>
> DOUG: I do want to state this somehow.
> IMO, the "user data" is the actual pointer stored in the implementation.
> I think you are viewing "user data" as what is pointed at.
> It is that pointer that can't be shared by models running in different
> scopes.
> We should state that in this area, somehow. Please re-word as you see fit,
> I'm by no means in love with my rushed wording of yesterday :)
johnS:
How about this:
"A user wanting to share a data area across multiple contexts
must do so by allocating the common data area then storing the
pointer to it individually for each of the contexts in question via
multpile calls to svPutUserData(). This is because, although a
common user key can be used, the data must be associated with
the individual scopes (denoted by svScope) of those contexts."
> >
> > -------------------------------------
> > A.8.3 comments for svGetUserData()
> >
> > The comments say "... , 0 upon success"
> >
> > Don't we mean to say it returns a non-NULL valid
> > user data pointer upon success ?
> >
> > -------------------------------------
> > A.8.3 comments for svGetCallerInfo()
> >
> > Please don't use "TRUE" and "FALSE" to describe what is
> > returned for an 'int' type. That assumes that these are defined
> > somewhere. Just use "non-zero" for success, 0 for failure or
> > "0" for success, "-1" for failure to be consistent with
> > what you said for svPutUserData().
> > -------------------------------------
> >
> > -- johnS
>
>
> Regards,
> Andrzej
>
--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 : Fri Mar 28 2003 - 10:01:34 PST