sc2c is a tool within SCE for code generation and hardware-dependent software generation. From a model defined in an SIR file, it generates targeted C code as well as build and configuration files for cross compilation. It uses a SW database to create target binaries including all support code and (if selected) RTOS for execution on target platform or ISS. Furthermore, sc2c can either integrate an ISS into the design for binary validation, or reintegrate the generated (and potentially modified) target code into the design (VP) for fast validation. Please see the COMMANDS section for generation and integration commands.
A SIR file is a binary file containing
the SpecC Internal Representation of a design.
In its default behavior,
sc2c
reads the SIR file specified with
design
and generates C source code for all behaviors starting with the
RootBehavior.
It writes the C source code into a
RootBehavior.c
.c
and a
RootBehavior.h
.h
file. The output file names can be changed with the
-c
and
-h
option respectivly.
When done
sc2c
reintegrates the generated C code into the design and
writes back the modified
design
into an SIR file named C_design.sir, unless overwritten by the -o option.
On successful completion, the exit value 0 is returned. In case of errors, an error code with a diagnostic message is written to standard error and the program execution is aborted with the exit value 10. In case of an error, no output is produced.
specifies the design to work with; if no -i or -o options are specified, the suffix '.sir' will be appended to this name in order to obtain the SIR file to read. For the SIR file to write the design name is prefixed with 'C_ and suffixed with '.sir';
<generation> = {|c|C|b}
(empty) do not generate anything
generate source code (.c, .h)
generate complete source code and build (.c, .h, Makefile)
generate build info only (Makefile)
<integration> = {|v|i {<ISSWrapper>}}
(empty) do not integrate anything
integrate source code (.c, .h) into virtual platform
switch SW PE to ISS-based model using ISSWrapper
-c output C fileexplixitly specifies the output C file name; (default
<basePath>/<basePath>.c
, see
-b basePath
option)
-ddo not keep the original top level S/W behavior; Default keep top level S/W behavior;
-h output H fileexplixitly specifies the output header file name; (default <basePath>/<basePath>.c , see -b <basePath> option) Note that both the C file name and the H file name may include a directory as well. However, it is expected that both files are placed into the same directory otherwise the reintegrating the C code will fail;
-i input filespecifies the name of the input file explicitly; (default design.sir ); The name '-' can be used to specify reading from standard input;
-nsuppress creation of new log information when generating the output SIR file (default: update log information); see also section ANNOTATIONS below;
-o output filespecifies the name of the output file explicitly; the name '-' can be used to specify writing to standard output; (default C_design.sir )
-ppure C code; If defined, the generated C code will only contain the target code NOT the simulation code for reintegration (eliminates the #ifdef jungle);
-t toplevel
mandatory parameter that defines the name of the top level behavior from which to start the software generation;
-u userHFileplaces user include statement into the generated C code in the form of "#include <userHFile>".
-u userHFile
may appear multiple times;
-venables verbosity mode; all actions performed are logged to standard error;
-xno relation with tool scos (assumes no RTOS model);
-mexplicitly set processor name (e.g. arm7tdmi) to reference into DB, (default: read from PE_SW_MODEL annotation);
-gexplicitly set cross-compiler name (e.g. gcc-arm-coff) to reference into DB, (default: read from PE_SW_MODEL annotation, first target platform for SW without OS, second platform for SW with OS);
-rexplicitly set osname (e.g. ucos-ii) to reference into DB, (default: read from PE_SW_MODEL annotation, first target platform for SW without OS, second platform for SW with OS);
-bspecifies base path where the source and Makefile files will be generated explicitly (default: directory name of C output file name if specified, otherwise CPU );
-Dspecifies path to sce database (default:$(SPECC)/share/sce/db)
The following SpecC annotations are recognized by sc2c:
list of strings that will be added to the generated makefile for target compilation;
list of strings that will be added to the generated makefile for target linking;
list of strings defining files to be included. Each string will result in a
#include statement in the generated code. The output location depends on
annotation location: Annotations at HAL are reflected in platform_hal.h,
top level annotations (at OS shell) in platform_os.h. Finally, annotations at
any SW behavior are reflected in the
output H file
(see
-h
option). Note, for each of the three
categories, duplicate entries are eliminated;
list of tuples. Each tuple is a {<key>,<value>} pair (<key> and <value> are strings) describing a #define to be generated in the target header file. Output location is identical to _C_INCLUDES . If multiple tuples use the same <key>, only the first found tuple is generated;
list of strings describing a set of #undef statements that will be generated target header file. Output location is identical to _C_INCLUDES ;
add link option to the reintegrated C code for the os model;
contains the log information of the SIR file; this global annotation is created and maintained automatically by the SpecC compiler and the SpecC tool set and can be used to determine the origin and the operations performed on the design model; _SCE_LOG is a composite annotation consisting of a list of log entries, ordered by time of creation; each log entry consists of a time stamp, command line, source file, version info, and an optional comment;
name of the design top level behavior;
connectivity list of all PEs in the design, also describes connectivity within a hierachical PE, read for detecting hierarchical software PEs;
execution priority of a behavior that will be implemented as a task in software;
find the name of the bus functional model, which contains the software PE;
find the name of the Hardware Abstraction Layer shell, which contains the software RootBehavior ;
name of the interrupt handler associated with a signal that is used as an interrupt. Used for interrupt recognition and mapping;
name of PE specific os handshake channel;
method name of interrupt handler of an behavior implementing an interrupt handler;
start method name for interrupt handler. Used for recognizing an interrupt handler;
detect the root behavior that contains the root of the simulated os (as defined by scos);
annotation at OS shell defining SW component in the target database;
For the reintegrated C code static, priority and first come first serve scheduling is supported. The target code generation supports priority scheduling only. Piped execution is not supported, such behaviors have to be serialized first. Compilation for the target platform requires a cross compiler and a populated database.