Changes between Version 8 and Version 9 of DsxDocumentation

Timestamp:

Jan 28, 2008, 12:30:39 PM (17 years ago)

Author:

alain

Comment:

--

DsxDocumentation

@@ -25 +25 @@
  * The software tasks are supposed to be written in C or C++, but - for portability reasons - the tasks must use an abstract '''System Resource Layer (SRL)''' API to access the communication and synchronizations resources. 
  * 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 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)communication  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.
  * 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.
@@ -83 +83 @@
 == C)  Defining the software application ==
 
-This chapter describes the DSX/L syntax used to define the Task & Communication Graph structure.
+This section describes the DSX/L syntax 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.
 
@@ -165 +165 @@
 In the mapping section of the DSX/L program, the lock can be explicitely placed in the memory space. 
 
-=== C6) Signal definition ===
-
-The DSX signals are used to signal a special event that is not synchronized with the data. The signal is transmitted
-to all registered tasks. The tasks are interrupted to execute the corresponding signal handler. Signals are mainlly
-used to implement soft real time constraints, a task can receive a signal, but cannot send a signal.
-{{{
-My_Signal = Signal( 'signal_name' )
-}}}
-There is nothing to place in the mapping section.
-
-=== C7) Task instanciation ===
+=== C6) Task instanciation ===
 
 A task is an instance of a task model. The constructor arguments are the task name ''task_name'', the task model
-''Task_Model'' (created by the TaskModel() function), a list of resources (MWMR channels, synchronization barriers,
-locks or memspaces), and the list of the signals that can be received by the task . DSX performs type checking between the port name and the associated resource.
+''Task_Model'' (created by the TaskModel() function), and a list of resources (MWMR channels, synchronization barriers, locks or memspaces), that must be associated to the task ports. DSX performs type checking between the port name and the associated resource.
 {{{
 My_Task = Task( 'task_name',
                          Task_Model ,
-                         { 'port_name' : My_Channel, 'barrier_name' : My_Barrier, ... } ,
-                         { 'signal_name : My_Signal, ... } )
+                         portmap = { 'port_name' : My_Channel, 'barrier_name' : My_Barrier, ... } )
 }}}
 In the mapping section of the DSX/L program, 4 software objects must be placed :
@@ -192 +180 @@
  1. ''run'' : processor running the task
 
-A task that has real time constraints must be instanciated by a special constructor. 
-There is two extra arguments : ''cond_activate'' is the signal definig the activation condition, and ''cond_deadline''
-is the signal defining the dead_line condition. 
-{{{
-My_Rt_Task = RtTask( 'task_name',
-                         Task_Model ,
-                         { 'port_name' : My_Channel, 'barrier_name' : My_Barrier, ... } ,
-                         { 'signal_name : My_Signal, ... } ,
-                         cond_activate ,
-                         cond_deadline )
+=== C8) TCG definition ===
+
+The Task and Communication Graph must be defined :  
+{{{
+My_Tcg = Tcg( 
+             Task(  'task_name1, 
+                     Task_Model1, 
+                     portmap = { ’in’:input, ’out’:output } ), 
+             Task(  'task2', 
+                     Task_Model2, 
+                     portmap = { ’in’:input2, ’out’:output2 } ) 
+              ... )
 }}}
 
 == D)  Defining the hardware architecture ==
 
+This section describes the DSX/L syntax used to define the MP-SoC hardware architecture,
+using the hardware components defined in the SoCLib library.
+
+=== D1) SoCLib components definition ===
+
+In the present version of DSX, each hardware component must be described by a PYTHON
+class that defines the component interface, and the component parameters. The instance
+name is mandatory, but all other parameters have default values and can be skipped: 
+{{{
+# creation of a MIPS R3000 processor core
+MY_proc0 = Mips( 'proc0' )
+
+# creation of a generic cache
+}}}
+
+=== D2) Connecting the components ===
+
+=== D3) Address space segmentation ===
+
+=== D4) Hardware architecture definition ===
+
+=== D5) Mapping table ===
+
+=== D6) Generic platforms ===
+
 == E)  Mapping the software on the hardware ==
 
+This section describes the DSX/L syntax used to map the software objects on the hardware architecture.
+
+=== E1) Mapper declaration ===
+
+=== E2) Mapper definition === 
+
 == F)  Code generation ==