Subject: RE: [sv-cc] Feedback on revision 0.8
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Fri Mar 28 2003 - 09:25:18 PST
John,
Good comments. Response embedded.
Thanks,
Doug
> -----Original Message-----
> From: Stickley, John
> Sent: Friday, March 28, 2003 8:56 AM
> To: Joao Geada; sv-cc@server.eda.org
> Subject: [sv-cc] Feedback on revision 0.8
>
>
> Joao,
>
> Some feedback on 0.8.
>
> -------------------------------------
> Section 1.2.1 title
>
> Did you mean to take out "layer" ? Seems like it should be in there.
> Same in second paragraph.
>
> -------------------------------------
> 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.
>
>
> -------------------------------------
> Page 34 2nd to last paragraph
>
> "an non-context function"
>
> S/B
>
> "a non-context function"
>
> Also, same paragraph,
>
> "Therefore, a call of non-context"
>
> S/B
>
> "Therefore, a call of a non-context"
>
>
> -------------------------------------
> 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.
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 :)
>
>
> -------------------------------------
> 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 ?
DOUG: Whoops - you are correct.
>
>
> -------------------------------------
> 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().
DOUG: Let's return 0 for success and non-zero for failure, -1 is fine.
This is consistent with many system API's in the world.
TRUE and FALSE should be reserved for boolean-returning functions,
such as isErrorDetected().
Thanks John.
<EOM>
>
> -------------------------------------
> B.1 Include Files
>
> The DPI context helper functions have not been updated to match
> what is in section A.8.3.
>
> -- johnS
>
>
> __
> ______ | \
> ______________________/ \__ / \
> \ 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 - 09:26:03 PST