Subject: Re: ISSUE:DirectC:How to find C/C++ code ???
From: Michael Rohleder (Michael.Rohleder@motorola.com)
Date: Thu Nov 07 2002 - 06:58:00 PST
I think I need to clarify a little bit what I mean here:
* It would be good to define a standard method how the files/libraries containing the C/C++ code are found in the file system and
how they are to be included (switch/variable/whatever). Something like: put it into your LD_LIBRARY_PATH/LPATH or a standard switch
that provides a list of directories or ... Otherwise we would end up in the same desaster as with PLI
OMI (IEEE-1499) has a clever method here (one bootstrap file that tells where to find the rest). But I have no preference here at
all.
* As Andrzej pointed out, it might be needed to identify relationsships between the C/C++ objects and the functions defined in SV.
I am not so sure here, but if this is the case, a naming convention might also be useful. Also what happens in case of name clashes
within the C/C++ objects?
* I am not sure whether we need to associate the .c/.cc/.cpp files with the .o/.a/.so ones
Regards,
-Michael
More comments interspersed.
Andrzej Litwiniuk wrote:
> > This is actually more a question than an issue. Do we need to define how C/C++ code is being found/linked?
> >
> > -Michael
> > n:Rohleder;Michael
> > tel;fax:++49-89-92103-680
> > tel;work:++49-89-92103-259
> > org:Motorola Semiconductor Products Sector;System Design Methodology
>
> 1) Same question may be asked for PLI or VPI code.
> IMO it should be left to a particular tool how to specify where to look
> for C/C++ code, which C/C++ compiler to use or with which libraries to link.
Yes, our problems with PLI are the reason for this issue. Former versions required to recompile/link Verilog every time the C code
changed. All vendors have meanwhile implemented their own methodology to include PLI C code into Verilog, there are some tiny, but
still ugly differences and this capability was not available from the beginning. When you need to support multiple simulators in a
flow things can really get nasty here; we wrote our own loader for shared libraries due to this reason some years ago...
> 2) Library modules may use external C/C++ code.
> Here a library module source code will actually consist of two parts:
> its SV part and C/C++ part.
> The C/C++ component of a library module may have a form of a source C/C++
> code or of an object file, or be a part of a binary library.
>
> Hence some means of associating .c/.cc/.o/.a files with a SV library module
> should be provided.
Yes, but more.
> Perhaps the simple file naming convention will do?
> The C component of a library module will have the same name (though
> with different extension like .c, .cc, .h, .hh, o, .a) as a library module
> source file and should be in the same directory (with the exception of
> standard C/C++ libraries).
> For example, if 'library/foo.v' contains SV source of a library module,
> than files 'library/foo.*' [with appropriate extensions] are considered
> to be related to that module.
>
> Andrzej
This archive was generated by hypermail 2b28 : Thu Nov 07 2002 - 06:59:00 PST