Subject: Re: Alternative to SvccBindSVcallee/r
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Tue Nov 12 2002 - 15:20:54 PST
Johnny, Kevin,
How would this kind of proposal work for calls
heading in the other direction, e.g. C-calling-SV?
Thanks and regards,
Doug
Amouroux, John wrote:
> Kevin,
>
> This is interesting. I've been thinking of something along these lines
> too. An extension to your idea could be to define a whole structure
> that gets passed in instead of a separate pli handle and context
> pointer. Then the vendors could put in other useful data at
> compile-time as well (run-time would be too slow).
>
> Something like:
>
> typedef struct directc_context_struct
> {
> int context_version /* = 1, to allow for version
> changes */
> pli_handle pli; /* the pli instance handle */
> char *file_name; /* source file name if HDL caller */
> int line_number; /* source line number */
> void *user_context; /* our beloved user-context pointer */
> } directc_context;
>
> I really don't know if this extra info is useful. My thought is that
> the line number info may be a way to differentiate the places where the
> directc function is called more than once from the same block, as well
> as allow vendors to emit better error messages. But the nicest thing
> about passing a structure is that we can add or change context info
> without requiring the users to change their call site code.
>
> However, the biggest problem I see with this is that if the vendor needs
> to do some elaboration-time initialization to set up the user context
> data, these calls will happen too late, maybe even if they occur within
> an initial block. A complicated way around this would be to always call
> each and every function instance with a special flag at elab-time to
> allow this pre-simulation context set-up.
>
> Another smaller issue is that the C code writer will still have to write
> some type of mapping/hash functions if they want to share one function
> entry point across numerous blocks and still do some instance-specific
> specializations.
>
> My worry is that by the time we do all this, John S's straightforward
> svcBindCallee(r) scheme may actually end up being simpler.
>
> Let's see what the others have to say.
>
> -- John A.
>
> P.S.
> lst_data needs to be static...
>
> -----Original Message-----
> From: Kevin Cameron x3251 [mailto:Kevin.Cameron@nsc.com]
> Sent: Tuesday, November 12, 2002 10:40 AM
> To: sv-cc@server.eda.org
> Subject: Alternative to SvccBindSVcallee/r
>
> [I don't think this got to the reflector last time I sent it.]
>
> To avoid using a seperate "bind" call, functions requiring context
> can be called as -
>
> <user func name>(<instance handle>,void **c_context,....)
>
> The instance handle can be a PLI handle for call-backs, and c_context
> points at a pointer location in the simulator which is initially zero
> - the user can fill it if desired on the first call for future calls
> (avoids hash-lookup).
>
> e.g.
>
> SV:
> extern "C" context int uf(int);
>
> int x;
>
> always@(clock) x=uf(x);
>
> C:
> int uf(handle ip,void **p_cntxt,int data)
> {
> int *lst_data,
> new_num;
>
> if (!(lst_data = *(int **)p_cntxt)) {
> /* first call only */
> if(!(*p_cntxt = calloc(1,sizeof int)) {
> reportError(ip,"C:uf","Out of memory");
> return -1;
> }
> }
>
> new_num = random_num(*lst_data);
>
> *lst_data = new_num;
>
> return new_num;
> }
>
>
> If you were calling a SystemC class (non-virtual) method it can
> use the ip handle to locate the right "this" on the first call
> and save it in *p_cntxt.
>
> Regards,
> Kev.
>
This archive was generated by hypermail 2b28 : Tue Nov 12 2002 - 15:21:23 PST