Changes between Version 5 and Version 6 of DsxDocumentation

Timestamp:

Jan 27, 2008, 9:31:23 PM (17 years ago)

Author:

alain

Comment:

--

DsxDocumentation

@@ -26 +26 @@
  * Each task in the TCG can be implemented as a ''software task'' (software running on an embedded processor), or can be implemented as an ''hardware task'', (running as a dedicated hardware coprocessor).
  * DSX allows the programmer to use unprotected shared memory spaces, but the prefered inter-tasks communication mechanism use the MWMR middleware. The MWMR (Multi-Writer, Multi-Reader) channels, are implemented as software FIFOs and can be shared by ''software tasks'', and by ''hardware tasks.
-* DSX provides classical synchronization mechanisms such as barriers and locks, but inter-task synchronisation is mainly done through the data availability in the MWMR channels.
+ * DSX provides classical synchronization mechanisms such as barriers and locks, but inter-task synchronisation is mainly done through the data availability in the MWMR channels.
  * The target hardware architecture is a shared memory multi-processor system on chip (MP-SoC) using the SoCLib library of IP cores. But - in order to validate the multi-threaded software application - DSX is able to generate an executable binary code for a standard POSIX workstation.
  * DSX supports the POSIX compliant [https://www-asim.lip6.fr/trac/mutekh Mutek]  OS kernel for embedded MPSoCs
@@ -83 +83 @@
 == C)  Defining the software application ==
 
+This chapter describes the DSX/L constructs used to define the Task & Communication Graph structure.
+The TCG is a bipartite graph: the two types of nodes are the tasks and the communication channels.
+The following figure describes the TCG corresponding to an MJPEG decoder application. The two TG & RAMDAC tasks will be implemented as hardware coprocessors : the TG component implements a wire-less receiver, and the RAMDAC component is a graphic display controller. The 5 other tasks can be implemented as ''software tasks'' or  
+as ''hardware tasks''. In this example, all MWMR communication channels have one single producer, and one
+single consumer, which is frequent for stream oriented multi-media applications.
+
+=== C1) Task Model definition ===
+
+As a software application can instanciate several instances of the same task, we must distinguish the task, and the task model. A task model defines the code associated to the task, and the task interface (corresponding to the system resources used by the task : MWMR communications channels, synchronization barriers, locks, and memspaces).
+{{{
+Task_model = Task( 'model_name',
+                    infifos = [ 'inport_name', ... ] ,
+                    outfifos = [ 'outport_name', ... ] ,
+                    locks = [ 'lock_name', ... ] ,
+                    barriers = [ 'barrier_name', ... ] ,
+                    memspaces = [ 'memspace_name', ... ] ,
+                    signals = [ 'signal_name', ... ] ,
+                    impls = [ SwTask( 'func', stack_size = 1024 , sources = [ 'func.c' ] )
+}}}   
+I a task does not use a given type of resource, the corresponding parameter can be skipped.
+
+=== C2) MWMR communication channel definition ===
+
+=== C3) Synchronization barrier definition ===
+
+=== C4) Synchronization lock definition ===
+
+=== C5) Signal definition ===
+
+=== C6) Task instanciation ===
 == D)  Defining the hardware architecture ==