Documentation for the GenoM3 fiacre/pocolibs template

Using and running the template

The fiacre/pocolibs GenoM3 template is invoked with:

genom3 fiacre/pocolibs <module(s).gen>

It will create a fiacre-pocolibs subdirectory containing a number of files.

cd fiacre-pocolibs
autoreconf -vif
./configure --prefix=${HOME}/work

Note that for the configure to succeed, you need first to define the HIPPO_DIST environment variable. Put this variables (tune the values for your installation) in your .bashrc file.

export HIPPO_DIST=${HOME}/work/hippo-2.6.5

The fiacre/pocolibs template takes different arguments to synthesize the most adapted hippo runtime model.

genom3 fiacre/pocolibs -h

FIACRE (Hippo) Pocolibs-based component generation.

This template generates GenoM components that can links with hippo, the FIACRE engine, using the pocolibs

Supported options:
  -C, --directory dir	output files in dir
  -p, --preserve	do not overwrite existing files
  -P, --patch patchfile	the patch to apply to the model (e.g. to add monitors).
  -M, --port_mapping port_mapping_file	use this file as a dict for mapping in port in out port (compin_portin compout_portout)
  -w, --wcet wcetfile	use the file as a dict with the wcet value
  -W, --wcet_exec		worst case execution (wait wcet before sync)
  -n, --exp_name name	use this name as a "multi component" experimentl
  -s, --slow <freq>		specify the slow down factor as a frequency (1 tick of the engine = 1/freq).
  -h. --help		print usage summary (this text)

Let’s explain the various fiacre/pocolibs specific arguments:

  • -P, --patch patchfile The patchfile will be applied (as a patch) to the synthesized model by genom3. This can be usefull if you want to augment your model with monitors, and code to manage them.

  • -M, --port_mapping port_mapping_file Ports in GenoM3 are specified as in or out in the .gen file. In any regular experiment, the connect_port request is used to connect in port to out port at runtime. For these connection to be taken into account in the synthesize model, one can specify the mapping in a file as a tcl dict to map in port to out port with the syntaz: component-name-in_port-name_in component-name-out_port-name-out. Note that GenoM3 multiple ports are not supported. This is used to check port possible uninitialized access…​ If a codel is using a port as in or inout before one has use it as out, this is suspicious.

  • -w, --wcet wcetfile Use the content of wcetfile as a tcl dict with the wcet value for each codel of the experiment. The wcet value is given in second.

  • -W, --wcet_exec worst case execution of codel. If this option ispresent, the Fiacre model consider that codel execution takes exactly the wcet value i.e. [wcet,wcet], insteaad of [0,wcet].

  • -n, --exp_name name use this name as a "multi component" experiment. When including more than one genom3 component, it is often good to have a name for the whole experiment/model.

  • -s, --slow Specify the slow down factor as a frequency (1 time unit = 1/frequency). Fiacre and TINA only use integer (no float), so time values must be given as int. For this, wcet and period are multiply by this number. -s 1000 means that the model will be synthesized with time values in milliseconds. If you have a wcet of 0.025 seconds, it will become 25 in the model. Similarly, a task with aperiod of 20 Hz (50 ms), witll have a cycle of [50,50]. In the case of synthesis for an hippo executable, this will also define the value of the hippo tick (in nano seconds). For example, if you define -s 10000000 (10 KHz), the tick value of hippo will be 100000 nano seconds.

The fiacre-pocolibs directory contains all the synthesized files. The fiacre subdirectory contains the fiacre model as well as some conpagion .c and .h files. The src directory contains mostly pocolibs files (from the pocolibs/server template) which have been modified to suit the fiacre template. Even if most of the control algorithms of the pocolibs/server template have been faithfully reprogrammed in Fiacre (control tasks, execution tasks, timers, services and request management, activity automata, calling codels, etc), there are still a number of processing which is handled as in the pocolibs/server template. In particular:

  • the pocolibs mbox remains the same, but this has the advantage that from a client POV, there is no distinction between the fiacre/pocolibs and the pocolibs/server version.

  • the port access API remains the same. Again this allow for a seamless integration between pure pocolibs components and fiacre/pocolibs ones.

  • the arguments of the services (in and out) and the associated encoding/decoding is the same (this is in fact handled by the pocolibs middleware rqst callback).

Limitations of the fiacre/pocolibs template.

  • As mentioned above, the multiple ports are implemented but are not fully modeled. Considering that multiple ports are created at runtime, it is difficult to model them before hand.

  • remote and connect_services are not supported at all (but they are hardly used in any experiment that we know).