Subject: Re: DirectC: C layer - abstract vs direct
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Wed Dec 11 2002 - 13:55:19 PST
> From: "Warmke, Doug" <doug_warmke@mentorg.com>
>
> Kevin Cameron x3251 wrote:
> >>From doug_warmke@mentorg.com Wed Dec 11 10:55:22 2002
> >>
> >>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, a direct mechanism is nice-to-have but this one is
> > going to be really expensive to implement and won't give
> > any speed advantage.
>
> Disagreed.
There is an implicit assumption in the proposal that the SV
simulator holds structured data in a contiguous form in memory
such that it's order is similar to what C would do - just the
representation of 4-state and multi-dimensional addressing is
not known.
I do not agree with that assumption.
> >
> > E.g. if you declare a large array with 4-state fields and
> > the SV simulator decides to split the value and "control"
> > data into seperate structures then patching it together
> > into a single structure for a call, and breaking it up
> > again is not cheap.
> >
> > Joao already said that he found three different internal
> > representations of logic types in the Synopsys simulators.
> >
> > In fact, Andrzej's proposal says: let's not bother with
> > abstract access, just go direct. It's not option (c).
>
> Also disagree. I feel it is option (c).
> There are abstract methods where necessary,
> and not elsewhere.
Since you can't know the internal structure of the SV simulators
data for 4-state data, general direct access is not possible.
> >
> >
> >>IMO runtime type checking is a feature of secondary
> >>importance. Simplicity of use and consistency with
> >>established mixed language use models is primary.
> >>
> >
> >
> > It's not simple to use if it's easy to break, IMO the SV
> > interface should be minimally vulnerable to bad programming.
> >
>
> It is not easy to break if you follow the rules.
I often think I'm following the rules for C (and I've been
using it since 1985) and it still breaks regularly for me.
Nobody I know writes perfect code.
SV is for hardware designers I'd rather not let them
get bogged down trying to find C bugs.
Kev.
> Also, I mis-typed something below and I apologize.
> I meant to say it is consistent with established
> mixed language use models (meaning Verilog and VHDL
> mixed together in a design hierarchy). Users
> have accepted the use model for language mixing that
> is already available in industrial simulators, and I
> would like to continue in that vein with our work.
>
> >
> >>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.
> >
> >
> > VHDL does bounds checking (as well as strong type checking).
> >
> > The current mix we have of Verilog an C++ is extremely difficult
> > to debug. The same issues will exist with using SV in conjunction
> > with SystemC.
> >
> > Memory misuse bugs are often extremely difficult to track down.
> >
> >
> >>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.
> >
> >
> > If users adopt our DirectC interface and use more SystemC in
> > their design flows then there will be a lot more use for
> > this interface than for existing PLI.
>
> True - however the point remains that users don't often make
> changes at the language boundaries of their designs. They
> set up their configuration once, and then uses it extensively
> for lots of verification tests.
>
> 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
> >>>
> >>>
> >>
> >>
> >
>
>
----- End Included Message -----
This archive was generated by hypermail 2b28 : Wed Dec 11 2002 - 13:55:57 PST