Version 3 (modified by 5 years ago) (diff) | ,
---|
Virtual Machine Documentation
The virtual machine runs under Ubuntu and allows out-of-the-box generation and co-simulation of virtual prototypes.
Login
The user name is TTool, the password is ttoolVM.
Pre-installed Software
SystemC, SystemC AMS as well as cross-compilers for MIPS32 and PowerPC are pre-installed (cross-compiler installation can be fastidious and time-consuming)
Documentation
TTool_AMS_Doc.pdf: the main documentation (as available online)
Directories
(see chapter 1.1) bin contains systemc-env.sh configure the paths for SystemC and SystemC AMS cxtools contains the binutils include contains some necessary include files systemc-ams.2.1 SystemC AMS installation TTool is the TTool directory tmp is a temporary repository for soclib compilation files
Startup
The first time, or after any modifications to the TTool source code, the following two commands must be executed: make ttool make install
Starting TTool : ./ttool.exe
ttool.exe must contain the -experimental option to allow AMS features (default)
Follow the procedure described in the main documentation.
Running the examples
TTool/modeling/SystemC-AMS contains a number of examples. There are three kinds of models : SystemC AMS only, SystemC AMS combined with software running on SoCLib MPSoC, and ELN.
0) source ~/bin/systemc-env.h to set up the environment
1) If the model does not contain any SoCLib components (also called standalone SystemC AMS):
scheduling and code generation phase in the SystemC AMS panel only.
In the SystemC AMS panel, click on the gear at the right of the panel's toolbar.
1.1) Validation and code generation
Validation tab: calculate a valid schedule or warn if delays must be inserted Generate code: generates SystemC AMS code from the SystemC AMS model
1.2) Compilation under SystemC AMS
Files are written in TTool/SysCAMSGenerationCode, where they can be compiled and executed.
A Makefile is generated, as well as two directories containing the code: generated_CPP and generated_H. To compile, type make. If tracing is activated, a .dat file is generated which can be viewed with gaw (gtk analog wave viewer: to download http://www.rvq.fr/linux/gaw.php)
2) If the model contains software running on a SoCLib platform (there is a GPIO component present in the SystemC AMS model and Svatar Block, state machine and Deployment Diagrams), it is destined for co-simulation. SystemC AMS simulation is combined with full-system simulation with cross-compiled software, using the MutekH micro kernel on a generic SoCLib platform.
2.1) proceed as in 1.1
2.2) Generation of software application code (from AVATAR model)
Go to the Avatar Deployment Panel. Click on the Syntax Analysis icon in the main toolbar. The Avatar model is read in and syntax analysis of the block and state machine diagrams is performed.
Then, click on the gear rightmost in the Avatar Deployment panel's toolbar. (You might have to enlarge the TTool window in the Virtual Machine). The leftmost tab allows code generation. Press start button.
2.3) Co-simulation in the virtual machine:
In the TTool/MPSoC directory, a specific Makefile (Makefile.forsoclib) can be configured for MIPS32 or PowerPC cross-compilation. You first have to cross-compile the application code (Posix tasks) using "make compilesoclib", then the SocLib? platform using "make runsoclib". The cross-compiled application is loaded into the memory of the SoCLib RAM, and the SoCLib topcell instanciates the GPIO interface and starts the simulation.
summary of make options :
make updateruntime (normally not needed - only for changes to the runtime) make compilesoclib (cross-compilation for target machine) make runsoclib (compiles the SoCLib platform and the SystemC AMS clusters) make allsoclib: updates runtime, compiles, and runs, virtual prototype
3) Most examples use the TDF and DE MoC. Some (pre-experimental) use the ELN MoC. For the moment ELN can be combined with TDF but not with SoCLib..