Subject: Re: More on ISSUE 1.7: direct access is a must
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Fri Nov 22 2002 - 16:08:41 PST
> From owner-sv-cc@server.eda.org Fri Nov 22 14:22:17 2002
> From: "Andrzej Litwiniuk" <Andrzej.Litwiniuk@synopsys.com>
> Subject: Re: More on ISSUE 1.7: direct access is a must
> To: doug_warmke@mentorg.com
> cc: Michael.Rohleder@motorola.com, sv-cc@server.eda.org
>
> Hi all,
>
> > There are actually a few approaches available to us.
> > Before digging in and fleshing out details, I think
> > the group needs to vote on the general philosophy
> > to be followed. Once that is done, we can spend
> > time on detailed specification. If we don't agree
> > on this early, we will waste time on email and
> > in meetings.
>
>
> Absolutely agree.
>
> Please consider the following two observations:
>
> 1) if standard C functions are to be directly callable from SV
> (cf. the requirements!) then some form of direct access is a must.
> At least some primitive types (int, pointer, string, ...) should
> be supported with direct access mode.
>
> 2) once the standard is defined, vendors may come up with their
> open or proprietary versions of libraries for the abstract access
> mode.
>
> Note that the C layer of the interface is transparent to SV.
> --------------------------------------------------
I don't like the sound of that. The C code needs to be portable across
simulators. I think we should have a stab at defining it.
> Hence the vendors will have the freedom and flexibility of defining
> their own versions of the C layer, or their own implementation of
> the collection of functions agreed upon as a part of the interface.
> Different implementations of the same function (with respect to
> arguments and result) may actually differ in performance, safety,
> performed checks, etc.
>
> Actually, even if we decide to completely reject abstract access,
> vendors still will be able to provide it! It's just a matter of
> modifying the SV compiler; other tools nor SV programmers won't
> even notice it! (If they don't use the alternative version, of course.)
>
> My point here is that it's not that important, how we define the C
> layer now.
> Anyway, the C layer of DirectC interface is likely going to be
> a separate document, an appendix to the core SV definition.
> This also buys us some time.
Since people are embarking on writing new SV simulators now I think it
is important to have a good idea how this stuff is going to work so that
people can implement it efficiently rather than retro-fitting it later.
> The only thing that has to be defined =now= and may not be postponed
> is the syntactical support for different access modes, if we decide
> to use a mixed model.
> I mean here things like 'extern' or 'extern "C"' or 'extern "A"'
> or whatever syntactical means may be used to specify the access mode.
> (The problem can be avoided by all-or-none approach, where
> the access mode is specified by compiler's flags, but this approach
> seems less convenient that the one usde in VCS DirectC.)
I think "C" vs "A" should probably not be defined in the SV language, and
should be handled at the code linking level or by compiler flags as you
suggest. It could be pulled back into the language at a later date.
Note: the dynamic call binding mechanism in the document I sent out
earlier provides a "capabilities" mechanism which could be used to
indicate support for different levels of abstract access.
Kev.
>
>
> Andrzej
>
>
>
> > Here are the possible approaches I can see:
> >
> >
> > 1) Use system currently in place in DirectC.
> > i.e. both abstract and direct are redundant
> > with each other. Both are available to user,
> > the user decides which to use.
> >
> >
> > 2) Use abstract mode all the time.
> > All access is done through API functions.
> > Different #define or -D could be used to
> > specify an optimization level.
> >
> > 3) Use combination of direct and abstract modes,
> > but with no redundancy. In this approach,
> > almost all access is done in Direct mode.
> > There are some items which must be done using
> > abstract programming interface calls:
> > 1) Determining # of array dimensions
> > 2) Determining bounds of each dimension
> > 3) Equating enum ordinals to ASCII strings (optional)
> > 4) Maybe more that I can't think of right now
>
>
This archive was generated by hypermail 2b28 : Fri Nov 22 2002 - 16:09:09 PST