Subject: Re: DirectC: C layer - abstract vs direct
From: Francoise Martinolle (fm@cadence.com)
Date: Wed Dec 11 2002 - 15:32:02 PST
I agree with Kevin's replies. My previous email will describe my concerns
regarding the C
layer proposal.
Francoise
'
At 01:55 PM 12/11/2002 -0800, Kevin Cameron x3251 wrote:
> > 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 - 15:46:09 PST