wiki:SoclibCc/DesignGuide

Version 11 (modified by Nicolas Pouillon, 14 years ago) (diff)

--

SoCLib's compilation helper

What do we want ?

We want a tool which can build a complete virtual prototype (aka SystemC simulator) from:

  • a topcell provided by user
  • a list of parametrable components, and their parameters

Therefore we need the following features:

  • Component indexation in the library tree
  • Parametrization of source files
  • Build of all these files

We also want to be able to compile all these with different SystemC implementation and different compilation modes (debug, release, profiling, …) without having to change build files.

As virtual prototypes may be huge but users always use the same parameters, we would like the following additional features:

  • Parallel compilation
  • Object caching (ccache could be an option)

As we speak about C++, parametrization of source files uses templated code.

Why ?

Reworded, we need:

  • Different SystemC backends (SystemC-OSCI, SystemCASS, SoCView) each of them is a different implementation of the same LRM, and yields incompatible objects
  • Metadata-based component definition, including used source files. Components are not necessarily implemented in an unique file, but may be scattered through different files, metadata does the glue.
  • Templated classes. The usual way of using templated code is to put all code in .h, having template code emitted at use in main C++ file.
    This is good for small utilities, but SystemC modules may be more than 1000 lines-long, and more that 40 of them may be used in a topcell. This may yield a single translation unit with more than 50000 lines of code, heavily templated. This implies some usage issues (compiler getting out of memory, unreasonnable compile times).
    Therefore we need two features:
    • Separate implementation: Put template class definition and implementation in two separate files. Compile them separately.
      This implies template code must be explicitely instanciated with some template class Foo<parameters>; code. It has to be done automatically.
    • Object reuse: Once modules built separately, we can put objects in a global repository and use the in a cached way.
  • Different build modes (debugging, profiling release, others ??)

Why not reuse existing tools ?

There is no build tool known out there which does object caching and template instantiation at the same time. Even if current build tools may be enhanced to do the job, this is not an easy task. Moreover, resulting code would be a kludge. This is all about flexibility, and user-input readability.

This could be seen as reimplementing make, or even SCons, and this is not totally wrong. But we added other features:

  • Template instantiation
  • Separate source enumeration
  • Object caching

Soclib-cc has been implemented as a make wrapper before, it was not usable:

  • generated Makefiles were unreadable (all templates parameters in the middle, …)
  • it did not work so well (make interprets : a special way, and escaping is nearly unusable)
  • the code generator was a big ugly piece of software
  • we still had to do .sd file indexation.

Compilation flow

The resulting compilation flow is as follows:

Design

Usage

Soclib-cc may be used three ways:

  • As a compiler wrapper. It will just be a CXX wrapper, handling compilation or linkage on demand. This can be useful for external Makefile integration. (the -c option)
  • As a component compiler (the -1 option)
  • As a complete platform compiler. From an ad-hoc platform definition (wrappers can be written to accept other formats), the complete simulator will be compiled. (the -p option)

Try running soclib-cc -h.

Attachments (4)

Download all attachments as: .zip