The simulator of PLAN is to analyze transactions of a simulation trace obtained with the DIPLODOCUS simulator.
The first step is to create a DIPLODOCUS mapping. Once the mapping
model has been checked against syntax errors , it
is possible to generate a C++ code
that represents the mapping
model. If you are using a model in TTool, then the code is generated by
default in TTool/simulators/c++2 for models. If your model has been made
in a project, then the code is generated into the “c++_code”
subdirectory of your project.
The second step is to compile the code. You can directly do it from TTool with the code generation window, second tab. Another option is to open a terminal, and to enter the following command:
$ make
The third tab of the simulation code generation window provides several options to start the simulator, e.g. either running simulation until completion or running the server in interactive mode. For the latter, the simulator is started in server mode, and TTool connects via sockets to the server in order to remotely drive the simulation.
Use the graphical interface, or the command line interface of the simulator to generate a trace in XML format. From the graphical interface, look for a tab named “save trace”, enter a file name and clock on the <bXML icon.
The XML trace you have generated at previous step should be listed in the left tree, section “Simulation traces”. Make a right click on the trace and select “Latency analysis”. You should be asked the name of the mapping from which the simulation was done. Select it.
A new window should open.
PLAN is based on the classification of transactions between two operators “oa” and “ab”.
In the “study Latency between” section, select “oa” (on the left) and “oa” (on the right), see the Figure below. Listed operators are the ones that have been selected with a right-click on an operator, then “check latency checkpoint measurement”.
Once two operators have been selected, click on the top button “Compute latency”. A table displays the start time of the first transaction of “oa” and the end time of the first transaction of “ob”.
Click on the line of the table obtained at previous step. Then, select the top button “Precise analysis”. a new window should open. The top part of the window lists mandatory transactions. The middle part lists non mandatory transactions. The lowest part of the window uses a table to display the classification set of transactions: mandatory, non-mandatory causing contentions, or non-mandatory causing no direct contention.
Classifying transactions relies on the identification of paths between operators used to generate the simulation trace. This dependency graph can be displayed by selecting “Show Directed Graph”, top left button.