| 1 | '''Virtual Machine Documentation''' |
| 2 | |
| 3 | The virtual machine runs under Ubuntu and allows out-of-the-box generation and co-simulation of virtual prototypes. |
| 4 | |
| 5 | '''Login''' |
| 6 | |
| 7 | The user name is TTool, the password is ttoolVM. |
| 8 | |
| 9 | '''Pre-installed Software''' |
| 10 | |
| 11 | SystemC, SystemC AMS as well as cross-compilers for MIPS32 and PowerPC are pre-installed |
| 12 | (cross-compiler installation can be fastidious and time-consuming) |
| 13 | |
| 14 | '''Documentation''' |
| 15 | |
| 16 | TTool_AMS_Doc.pdf: the main documentation (as available online) |
| 17 | |
| 18 | == Directories == |
| 19 | |
| 20 | (see chapter 1.1) |
| 21 | '''bin''' contains systemc-env.sh configure the paths for SystemC and SystemC AMS |
| 22 | '''cxtools''' contains the binutils |
| 23 | '''include''' contains some necessary include files |
| 24 | systemc-ams.2.1 SystemC AMS installation |
| 25 | '''TTool''' is the TTool directory |
| 26 | '''tmp''' is a temporary repository for soclib compilation files |
| 27 | |
| 28 | |
| 29 | == Startup == |
| 30 | |
| 31 | The first time, or after any modifications to the TTool source code, the following two commands must be executed: |
| 32 | make ttool |
| 33 | make install |
| 34 | |
| 35 | Starting TTool : ./ttool.exe |
| 36 | |
| 37 | ttool.exe must contain the -experimental option to allow AMS features (default) |
| 38 | |
| 39 | Follow the procedure described in the main documentation. |
| 40 | |
| 41 | |
| 42 | == Running the examples == |
| 43 | |
| 44 | TTool/modeling/SystemC-AMS contains a number of examples. There are three kinds of models : |
| 45 | SystemC AMS only, SystemC AMS combined with software running on SoCLib MPSoC, and ELN. |
| 46 | |
| 47 | 1) If the model does not contain any SoCLib components (also called ''standalone'' SystemC AMS): |
| 48 | scheduling and code generation phase in the SystemC AMS panel only. |
| 49 | |
| 50 | In the SystemC AMS panel, click on the gear at the right of the panel's toolbar. |
| 51 | |
| 52 | 1.1) Validation and code generation |
| 53 | |
| 54 | Validation tab: calculate a valid schedule or warn if delays must be inserted |
| 55 | Generate code: generates SystemC AMS code from the SystemC AMS model |
| 56 | |
| 57 | 1.2) Compilation under SystemC AMS |
| 58 | |
| 59 | Files are written in TTool/SysCAMSGenerationCode, where they can be compiled and executed. |
| 60 | |
| 61 | A Makefile is generated, as well as two directories containing the code: generated_CPP and generated_H. |
| 62 | To compile, type make. If tracing is activated, a .dat file is generated which can be viewed with gaw (gtk analog |
| 63 | wave viewer: to download http://www.rvq.fr/linux/gaw.php) |
| 64 | |
| 65 | 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 |
| 66 | and Deployment Diagrams), it is |
| 67 | destined for co-simulation. SystemC AMS simulation is combined with full-system simulation with cross-compiled software, using |
| 68 | the MutekH micro kernel on a generic SoCLib platform. |
| 69 | |
| 70 | 2.1) proceed as in 1.1 |
| 71 | |
| 72 | 2.2) Generation of software application code (from AVATAR model) |
| 73 | |
| 74 | Go to the Avatar Deployment Panel. |
| 75 | 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. |
| 76 | |
| 77 | 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 |
| 78 | allows code generation. Press start button. |
| 79 | |
| 80 | 2.3) Co-simulation in the virtual machine: |
| 81 | |
| 82 | In the TTool/MPSoC directory, a specific Makefile (Makefile.forsoclib) can be configured for MIPS32 or PowerPC cross-compilation. |
| 83 | You first have to cross-compile the application code (Posix tasks) using "make compilesoclib", then the SocLib platform using "make runsoclib". |
| 84 | The cross-compiled application is loaded into the memory of the SoCLib RAM, and the SoCLib topcell instanciates the GPIO interface and |
| 85 | starts the simulation. |
| 86 | |
| 87 | summary of make options : |
| 88 | |
| 89 | make updateruntime (normally not needed - only for changes to the runtime) |
| 90 | make compilesoclib (cross-compilation for target machine) |
| 91 | make runsoclib (compiles the SoCLib platform and the SystemC AMS clusters) |
| 92 | make allsoclib: updates runtime, compiles, and runs, virtual prototype |
| 93 | |
| 94 | |
| 95 | 3) Most examples use the TDF and DE MoC. |
| 96 | Some (pre-experimental) use the ELN MoC. For the moment ELN can be combined with |
| 97 | TDF but not with SoCLib. Files and a Makefile are generated in TTool/ELNGenerationCode. |
| 98 | |
| 99 | |
| 100 | |