Subject: Re: SV-CC Proposal revision 7
From: Kevin Cameron (Kevin.Cameron@nsc.com)
Date: Tue Dec 10 2002 - 09:08:13 PST
"Stickley, John" wrote:
> Kevin,
>
> Kevin Cameron wrote:
> > Comments:
> >
> > 1. I notice that you have "queuable" applying to external functions, I think that will require multi-threading
> > to allow multiple call-stacks (which is why I limited it to exports.). Also, there appears to be no way
> > to check for completion in either direction, or (since it implies multi-thredaded behavior) what the
> > MT restricytions are.
>
> What I had in mind for queues is something more basic. It is that
> that the function arguments themselves are data that gets placed
> on a queue and read off some time later by the other end.
> It seems that there should be a way of doing this without even
> needing call stacks. However, we may be getting into tricky
> stuff with queueble that will take focus away from the basic function
> call interface that we're trying to achieve. I wonder if I should
> back off on this.
You can make an external call do anything you want - there is
no real need to mark it queueable.
> >
> > 2. The scoping is asymmetric. You should probably allow different C names for
> module scope and
> > $root.
>
> I did mean to convey this. Can you point me to where I left that out ?
>
> >
> > 3. Your examples won't work without some 'extern "C"' decls. being added.
>
> Do you mean that they won't work because the declarations aren't there
> or that they require "C" linkage ?
They require C linkage but your code was C++.
> I did not show extern decls on the C side just for brevity. It is implied
> that they need to be there and, in fact the compiler can generate headers
> for them that can be included as a convenience to the user.
I'd rather not mandate that the SV compilers generate headers.
> ....
> >
> > 4. Using vpi_get_user_data is likely to be significantly more inefficient
> than allocating space with
> > malloc and remembering it in the context.
>
> I don't agree. If, in its internal implementation, all that vpi_get_user_data()
> does is downcast the VPI handle and return a data member in the resulting
> structure, that is actually pretty efficient.
The VPI handle passed is not likely to be directly castable int something useful,
there will probably be a couple of calls involved, and maybe a hash look-up.
Kev.
> -- johnS
>
> >
> > Kev.
> >
> > --
> > National Semiconductor, Tel: (408) 721 3251
> > 2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090
> >
> >
> >
>
> --
>
> 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 \ /
> ---------
-- 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 : Tue Dec 10 2002 - 09:09:14 PST