Re: Object Code vs. Source Code compatibility


Subject: Re: Object Code vs. Source Code compatibility
From: Bassam Tabbara (bassam@novas.com)
Date: Tue Sep 03 2002 - 15:42:03 PDT


Hi All,

So far it seems we have been focused on the "technical" aspects, what
about the "feasability" of each approach ... ? Let me offer an opinion
(as I brainstorm) on this and open the floor.

Feasibility metrics: a) maintenance, b) competition (on better
implementation), c) ???

a) Do we -really- have a way to maintain revisions etc... if we go the
object oriented way ? What's the thinking here ? Who will do that, a
single company? the body ? As Mike said, in the case of Novas, Verisity,
etc... we -own- our libraries. We can optimize, improve, add/change
(implementation) things, as we wish.. and re-release, can the body do
this ?

c) For -competition- amongst (SV) simulator vendors, are we really going
to enforce an implementation ? Or really just a "spec" of what something
must do and the interface i.e. source-code compatible. Different
simulators will have different implementations (based on different
primitive routines etc...)....

** I think if we -restrict- the DFLI API and focus on a primitive set of
things (no room for much competition) this can be done. I think PLI was
not done this way (object level) because PLI is too "high level" (I mean
too much dependence on primitive simulator routines for example), lots
of room for people (simulator companies for example) to work on and
improve implementation... I assume we are only focused here on DFLI (no
assertion/coverage !!) and simple interface mechanism, for that purpose
I think if we can resolve the issue of maintenance, then competition
aspect would not play a role...

-Bassam.

Michael McNamara wrote:
>
> As the original positor of the position that System Verilog's external
> language interface should be object code compatible, let me weigh in
> here:
>
> 0) First, no one uses 'just the simulator'. While it is the case that
> many end user companies staff may never write a line of PLI, these
> folks indeed use PLI extensively: This is how waveform tools, coverage
> tools, timing tools, memory tools, power tools, assertion tools and
> formal tools hook to their environment.
>
> 1) A huge advanatge of object code compatibility is the posibility of
> reducing the number of commercial libraries. You do mention the issue
> of 5 platforms & 5 simulators needing 25 different binaries; where as
> if we had object code compatibility, we'd need only 5. You describe
> this in the context of end users, who of course could be presumed to
> have the source for their PLI; but need to also consider the add on
> market.
>
> 2) You talk about the existing world of IEEE 1364 Verilog not being
> object code compatible. While clearly there are bugs in vendors
> implementations, or perhaps we could call them misinterpretations of
> the 1364 standard; however as evidence of the reality of existing
> object code compatibility, Verisity releases just one library routine
> to hook SureCov to any of NC Verilog, VCS, ModelTech, Fintronics,
> (Frontline when it was still being sold), and Aldec. (likely others
> that I don't even know about, as the user does the link, without
> needing to talk to us). So the current state is not as broken as you
> suggest.
>
> 3) Taking 1 & 2 together, this provides the user, and the small/other
> simulator vendor, a huge win. If New Simulator Vendor had to convince
> Verisity, Novas, 0-In, Sequence, et cetera to do a custom build of
> each of their libraries for New Simulator, on each platform, there
> would be a huge barrier to entry that ultimately would hurt the
> customer. Today an end user can evaluate a simulator from a different
> vendor, and use the libraries they already have for their add on
> tools, as well as their own custome PLI libraries, without change.
> This level playing field is what made the tug of war between VCS and
> NC Sim to great for the industry, and for the customer: Ease of apples
> to apples comparison allowed simulator vendors that leap frog their
> competition to collect reward for their effort, and incentive for the
> frog leaped to leap the frog suddenly ahead of it.
>
> 4) If in truth there are issues like the 'acc_error_flag'
> redefinition, we the standards body must fulfill our obligation to
> mandate today, at the outset of this effort System Verilog, that all
> vendors must implement to our API. Because some vendor did it wrong
> in the past, or will likely do it wrong going forward isn't a reason
> we should give up pushing for a decent, useful standard.
>
> 5) C++: I do not claim to be an expert here, so please do not hesitate
> to gleefully point out my gross misunderstandings.... That said, my
> understanding is that the fact is that the C++ vendors (or perhaps the
> language itself??) have traditionally never supported building a C++
> library in a compiler vendor independent way. However all C++
> compilers do allow one to link to standard platform C libraries, like
> libX11.a, and so on. To my mind the best service we can provide is to
> require that the System Verilog Interface API be a C based interface,
> and then we do support all C++ compilers, and all C compilers, with a
> single library.
>
> This has the effect that it (may not be/ will not be) possible for a
> company like Denali to provide a vendor library that is implemented in
> C++ that will be C++ compiler independent. This, if true, does not in
> my mind make it reasonable for us to require that we force this
> terrible inconvenience on those creating vendor libraries in C.
>
> -mac
>
> Michael Rohleder writes:
> > Hi all,
> >
> > there is an action item with me to drive the already started
> > discussion about 'Object Code vs. Source Code compatibility'. Until
> > now I was unable to fulfill it, for various reasons (nothing but
> > bad excuses), so I am trying to do my dues now:
> >
> > (A) what is meant by 'object code compatibility' and 'source code compatibility'?
> > * Object code compatibility permits to integrate compiled
> > objects using the SystemVerilog API (to be developed)
> > within all applications providing such an API. The same
> > compiled object can be used within all applications; there
> > is no need to recompile the original source code.
> > * Source code compatibility permits to integrate any code
> > using the SystemVerilog API (to be developed) within all
> > applications providing such an API, but will usually
> > require a compilation of the source code using the header
> > files of the corresponding simulator.
> >
> > (B) why is this so important?
> > * Some members of SV-CC believe that the need for object code
> > compatibility can result in excluding C++ from the
> > implementation languages for the SystemVerilog
> > API('s). Although this might be the case, I would strongly
> > suggest to start with the _real_ questions: - Do we really
> > need object code compatibility or would source code
> > compatibility sufficient? - Under the assumption we need
> > object code compatibility, what are the implications of it?
> > - What problems would exclude C++ from being a usable
> > language for the API? - Why is PLI also not object code
> > compatible, although it is just C? So, instead of already
> > making (implicit) decisions during the discussion, let's
> > try to understand the whole problem space. Then we can make
> > informed decisions. I don't want to rule out C++ or get
> > into a 'language war' between C or C++; so please stop any
> > discussion in this direction. Instead let's talk about the
> > problems and their implications; probably there are also
> > solutions.
> >
> > -- O.K. let's start now. These are my two cents:
> >
> > a) Why do I as an user of such an API believe that 'object code compatibility' is so important?
> >
> > - We have to support more than 5 Verilog simulators
> > (VL-XL,NC,ModelSim,VCS,Emulation). Having to #ifdef code
> > to take care of the (minimal, but still existing) semantic
> > differences between those simulators is the last thing a
> > model developer wants to do.
> > - Usually there are at least 3 different versions of a model
> > (one for debugging reasons, one with maximum amount of
> > checks, one with no checks for maximum performance)
> > - We have to support 5+ platforms (Solaris, HP-UX, Linux, AIX,
> > Windows)
> > --> In case of object code compatibility this results in the
> > need to provide 15 different models; in case of source code
> > compatibility we would need at least 75 different
> > models. Each new simulator requires 15 more models
> > --> When there are additional compiler dependencies you can
> > nearly double the amount of models needed
> > (SparcCompiler+GCC, HPCompiler+GCC, VisualC++/GCC, ...)
> > --> I will not talk about additional needs & models caused by
> > incompatibilities between versions of the same simulator...
> > Of course this is an 'idealistic' case. We do not necessarily
> > need to support all models on all simulators on all
> > platforms. But in some cases this is the current reality!
> >
> > b) What are the implications, when we assume object code compatibility is needed?
> > - we need a clear and inambigous method to integrate the
> > object code into the simulation; this includes loading of
> > functions, interpretation of data values, and other aspects.
> > - the defined API must have a clearly defined execution
> > semantic, with no room for interpretation - the integration
> > method must be simulator AND compiler independent
> >
> > d) [Done before c) for discussion reasons] Why is PLI not object code compatible?
> > That's simple (from a general point of view) but also a rather complicated answer:
> > - General point of view: Verilog does not have clearly defined
> > integration semantics that require object code
> > compatibility. Therefore nobody has ever seen the need for
> > this ...
> > - Complicated answer: there is a lot of nitty gritty details
> > that prohibit object code compatibility. One example: One of
> > the commercial Verilog simulators redefines the variable
> > acc_error_flag not to be a global object, but to be the return
> > value of a function ... This is done by a #define. The
> > resulting object code is of course slightly different from the
> > object code of others ...
> >
> > c) As a matter of fact, some of the above problems in b) would exclude C++ from the languages of
> > choice for the API:
> > - C++ does not have clearly defined integration mechanisms; as a result these are differing from
> > compiler/linker to compiler/linker
> > - The C++ compiler performs a step called 'name mangling' that is needed to distinguish functions
> > having the same name, but a different signature (e.g.: to distinguish the function
> > 'int MyFunc(double)' from 'int MyFunc(int)'). The generated names are not standardized
> > and may therefore differ between compilers and platforms.
> > - Processing of global C++ objects is not defined and therefore different between compilers
> > and/or versions.
> > I think these are important problems, that would soon require some technical solution, but I
> > believe there are also some problems in other languages we should also take care of. If we
> > think by just choosing C instead of C++ we solve this problem, we better start discussing now.
> >
> > Hope this is sufficient dynamite to ignite some discussions.
> >
> > Best regards,
> > Michael
> >
> > ___________________________________________________
> > | |
> > _ | Michael Rohleder Tel: +49-89-92103-259 | _
> > / )| Software Technologist Fax: +49-89-92103-680 |( \
> > / / | Motorola, Semiconductor Products, ASA Methodology | \ \
> > _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_
> > (((\ \>|_/ > < \_|</ /)))
> > (\\\\ \_/ / mailto:Michael.Rohleder@motorola.com \ \_/ ////)
> > \ /_______________________________________________\ /
> > \ _/ \_ /
> > / / \ \
> >
> >
> >

-- 
Dr. Bassam Tabbara
Technical Manager, R&D

Novas Software, Inc. bassam@novas.com (408) 467-7893



This archive was generated by hypermail 2b28 : Tue Sep 03 2002 - 15:44:09 PDT