Subject: Re: DirectC: C layer - abstract vs direct
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Wed Dec 11 2002 - 10:57:21 PST
Kevin,
We already discussed abstract vs. direct at length
and we took a poll on the issue. Recall, proposal c)
carried the vote at the face-to-face. In essence,
that proposal says we should use direct access techniques
wherever possible, and only resort to abstract access
when strictly necessary. In addition, there should be
no redundancy of access (i.e. user can choose between
abstract and direct styles).
Andrzej's proposal is totally in line with proposal c).
Let's stay focused on the unresolved issues we have
on our plate.
***
IMO runtime type checking is a feature of secondary
importance. Simplicity of use and consistency with
established mixed language use models is primary.
The established Verilog/VHDL use models don't do
strong type checking and sometimes users can mess up.
However, if they read the manual and do simple experiments,
they quickly catch on and get their code working. I do
not agree that these issues are hard to debug.
In addition, the inter-language function call boundary
is not something that changes much after initial
verification setup. Once it is working, it stays
working forever.
Regards,
Doug
Kevin Cameron wrote:
> In my mind an abstract interface is one that uses an opaque handle as a reference to
> some object and lets you apply methods to it. In C++ fully abstract interfaces are
> implemented with virtual functions, in C it's ususlly:
>
> <ret data> = <method>(<handle>{,<args});
>
> - which is more-or-less the approach taken with PLI/VPI. It is not usually necessary
> to implement all methods for all objects. Calling an unsupported method usually just
> gets you a bad return value.
>
> Andrzej's proposal is not an abstract interface, it is a direct interface - i.e. the SV
> simulator provides a pointer to it's memory, and the user gets to write into it. Since
> SV can't perform array bounds checks on that interface it is error prone and is likely
> to lead to hard-to-debug crashes. Also, since in many cases the SV simulator's internal
> representation of the data is not likely to match the structure defined for C, the
> simulator has to create a copy of the data and pass a reference to that - which will
> be virtual copy-in/copy-out, and may be considerably slower than an abstract interface
> if only small parts of the structure are being accessed. There has been no official
> agreement that C type structures in SV actually layout the same as for C yet, I don't
> see there ever being agreement on SV types laying out the same.
>
> Kev.
>
> --
> 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 : Wed Dec 11 2002 - 10:59:11 PST