Subject: Re: Object Code vs. Source Code compatibility
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Tue Sep 03 2002 - 13:59:40 PDT
> From: "Michael Rohleder" <michael.rohleder@motorola.com>
>
> 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:
I've added some comments.
> (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.
And/Or:?
* Object code compatibility:
SV and foreign language code can be compiled seperately and linked together when needed to
create new circuits - the source code does not need recompiled.
* Source code compatibility:
SV and foreign language code need to be recompiled for a new circuit so that internal
interfaces can be built. The source code does not need to be edited.
> (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 75different 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!
Anybody for Java ? :-) (need an expert - anyone from Sun reading this?)
The GNU C++ (g++) is effectively an open standard that works on all the platforms and is free.
I think that reduces the scale of the problem.
> 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
There are a few types of API to consider -
a) Cross-calling using pass-by-value.
b) Cross-calling using pass-by-reference - the references being handles
(just a variation of (a) really).
c) Cross-calling using pass-by-reference - the references being pointers
to objects in memory (changes can be made subsequently to simulator
data without the simulator knowing).
PLI works at level (b), (c) is preferable for performance but requires that the
user code understands the structure of the data in the simulator - which only
really makes sense for user-defined types (SV not Verilog).
> 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 ...
I think we could insist that PLI be object code compatible for SV simulators.
> 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.
Could use GNU/g++ as the standard for linking/name-mangling. I suggested an alterntive
solution for name-mangling a while back:
http://www.eda.org/sv-cc/hm/0005.html
> - Processing of global C++ objects is not defined and therefore different between compilers
> and/or versions.
Not much we can do about that one - user problem.
> 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.
Definitely fissionable material :-)
Here's some more -
I would like to move to C++ because it is easier to write "polymorphic" code in C++, i.e. I can
write a chunk of code that interacts with one model and then reuse that code fairly easily with
a different model. The particular thing I have in mind is to have a tasks for modules and
interfaces available as (virtual) methods of a "module class" instance so that code like
this works efficiently:
C++:
...
mod1 mod1_r("top.mod1"); // constructor - creates reference to SV module instance
mod1_r.bus_write(0x2000,0xff); // call module's bus_write task
...
SV:
module mod1;
task bus_write(input addr,input data);
...
endtask
...
This would require that the SV compiler generate a header file defining a 'mod1' class and its
methods which the C++ can include for source level compatibility and/or a standard mapping so
the users can create the headers for themselves with compatibility at the object code level.
If I want to use a non-SV version of mod1 I can use a different header-file/class-definition, or
if the class definition uses "virtual" functions the code can be compatible with both SV and other
versions at the same time (for a slight performance penalty).
This functionality would be particularly useful for extending SV interfaces to bridge into C/C++.
If the SV compiler is producing the header file it could add methods for accessing other objects
in the module (functions, variables, regs etc.) - that lets you do API (c) above more safely.
Other module class methods could be added to support traversing the design hierarchy.
For object code compatibility across different C++ compilers the SV compiler would have to
generate different versions of the module class interface.
Note: in a mixed simulator environment (multiple kernels) the object oriented (virtual function)
approach means each module instance has it's own methods and there is no clash between one
kernel's implementation and another's as there would be with C if the kernels need different PLI
implementations.
Regards,
Kev.
> 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:07:55 PDT