Subject: RE: Object Code vs. Source Code compatibility
From: Michael McNamara (mac@verisity.com)
Date: Tue Sep 03 2002 - 14:21:30 PDT
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 \ \_/ ////)
> \ /_______________________________________________\ /
> \ _/ \_ /
> / / \ \
>
>
>
This archive was generated by hypermail 2b28 : Tue Sep 03 2002 - 14:23:37 PDT