Subject: Re: feedback for Kevin C proposal
From: Kevin Cameron (Kevin.Cameron@nsc.com)
Date: Mon Dec 09 2002 - 13:08:27 PST
"Stickley, John" wrote:
> Kevin,
>
> After reading your latest proposal and thinking more about
> it, it occurs to me why I don't think we should have dynamic binding
> support at all for SV-to-C calls. The reason is that all of the stuff
> you've outlined in your proposal, is conceptually similar to the
> existing VPI, ACC, and TF interfaces for user defined system tasks.
> In fact, in cases where dynamic binding is required, it is probably
> just better to use the existing interfaces. There are not a lot of
> differences between the information that is provided in your svcContext
> struct and information accessible via the VPI. Dynamically bound functions
> as you've proposed them are essentially the equivalent of a calltf
> function.
It's supposed to be as efficient as possible, the information used on every
call is stored in the context to avoid using heavy-handed VPI/ACC/TF
calls each time, and the dynamic binding allows that data to be set up
during call binding instead of on each call.
> With static binding we provide a very simple, API-less use model to
> the user:
Simple is not necessarily good, it doesn't address direct binding of C++
or dynamic loading of shared code which I and others at the face-to-face
are keen to have.
>
> Define a C function
> Call it from SV.
>
> OR
>
> Define an SV function.
> Call it from C.
>
> Anything beyond that should be deferred to existing mechanisms supported
> by the VPI.
That would insufficient enhancement to make it worthwhile re-engineering our
existing code.
> One other thing that I wanted to mention is that the danger of dynamic
> binding is that there is no good way to verify that the function profile
> of the provided function is correct. With static binding it is possible
> for the SV compiler to create a header file that the user can use to
> get natural type checking of the function arguments. With dynamic binding,
> this is not the case. It was not clear to me from your proposal how this
> is addressed.
The dynamic binding supports argument checking because the binding function
is passed all the individual argument (and return) types; it can use those to
construct the appropriate C-mangled name for the function call and then locate
it in the statically or dynamically linked libraries.
The code for doing that is not very complex, and I'd be happy to donate a g++
version.
C binding ignores argument types in all cases, there is no way to solve it with
your simpler approach. Making the SV compiler/simulator generate C++
prototypes makes your proposal somewhat less "simple" and only works
if you have the C/C++ source available to compile.
BTW, National's IA design-verification tools do dynamic loading of .so files
from C++ with PLI to Verilog. But currently the dynamic loader has to use
a seperate file to list the .so libraries because it can't tell which are actually
going to be used - the dynamic binding proposal solves that problem since
there will be binding calls for each routine actually used.
Kev.
> -- 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 \ /
> ---------
-- National Semiconductor, Tel: (408) 721 3251 2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090
This archive was generated by hypermail 2b28 : Mon Dec 09 2002 - 13:08:34 PST