Changes between Version 3 and Version 4 of DsxDocumentation


Ignore:
Timestamp:
Jan 27, 2008, 7:10:37 PM (17 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • DsxDocumentation

    v3 v4  
    33[[PageOutline]]
    44
    5 == A) Goals ==
     5== A) Goals and general principles ==
    66
    77DSX stands for ''Design Space eXplorer''. It helps the system designer to map a multi-threaded software application
    88on a multi-processor hardware architecture (MP-SoC) modeled with the SoCLib components.
    99
    10 It supports the hardware software codesign approach, and allows the designer to define successively :
    11  * the hardware architecture : number of processors, number of memory banks, peripherals, etc.
    12  * the software application structure : Task & Communication Graph
     10It supports the hardware software codesign approach, allowing the designer to define successively :
     11 * the hardware architecture : number of processors, number of memory banks, etc.
     12 * the software application structure : number of tasks and communication channels
    1313 * the mapping of the software objects on the hardware components
    1414
    … …  
    2525both the performances and the power consumption.
    2626
    27 == B) General Principles ==
    28 
    2927The general principles are the following:
    3028 * The coarse grain parallelism is
    … …  
    3230 *
    3331 * [https://www-asim.lip6.fr/trac/mutekh Mutek] : OS kernel for embedded MPSoCs
    34 
    35 === B1)  System Resources Layer ===
    36 
    37 We want to map the multi-threaded software application on several hardware platforms,
    38 without any modification of the task code. One important platform is a POSIX compliant
    39 workstation, as we want to validate the multi-threaded software application on a
    40 workstation before starting the mapping on the MPSoC architecture.
    41 
    42 DSX defines a '''system Ressource Layer''' API (SRL), that is an abstraction of the synchronization
    43 and communication services provided by the various target platforms. The SRL API helps
    44 the programmer to distinguish the embedded application code from the system code used for
    45 inter-tasks communications and synchronizations.
    46 
    47 Three  platforms are supported :
    48  * Any Linux (or Unix)  workstation  supporting the POSIX threads,
    49  * MP-SoC architecture using the MUTEK/D operation system,
    50  * MP-SoC architecture using the MUTEK/S operating system,
    51 
    52 MUTEK/D is an embedded, POSIX compliant, distributed,  operating system for MP-SoCs,
    53 while MUTEK/S is an optimized version: the performances are improved, and the memory
    54 footprint is reduced, at the cost of loosing the POSIX compatibility.
    55 
    56 === B2)  DSX/L language ===
    5732
    5833DSX/L is a language based on PYTHON, that allows the system designer to describe :
    … …  
    6540code that will be uploaded in the MP-Soc embedded memory.
    6641
    67 == C)  Describing the software application ==
     42== B)  System Resources Layer ==
    6843
    69 == D)  Describing the hardware architecture ==
     44We want to map the multi-threaded software application on several hardware platforms,
     45without any modification of the task code. One important platform is a POSIX compliant
     46workstation, as we want to validate the multi-threaded software application on a
     47workstation before starting the mapping on the MPSoC architecture.
     48
     49DSX defines a '''system Ressource Layer''' API (SRL), that is an abstraction of the synchronization
     50and communication services provided by the various target platforms. The SRL API helps
     51the C programmer to distinguish the embedded application code from the system code used for
     52inter-tasks communications and synchronizations.
     53
     54 * Communications : blocking & non-blocking Read & Write access to a MWMR channel
     55{{{
     56void srl_mwmr_read( srl_mwmr_t, void * , size_t ) ;
     57void srl_mwmr_write( srl_mwmr_t, void * , size_t ) ;
     58
     59size_t srl_mwmr_try_read( srl_mwmr_t, void * , size_t ) ;
     60size_t srl_mwmr_try_write( srl_mwmr_t, void * , size_t ) ;
     61
     62void srl_mwmr_flush( srl_mwmr_t ) ;
     63}}}
     64 * Synchronization barrier
     65{{{
     66void srl_barrier_wait( srl_barrier_t ) ;
     67}}}
     68 * taking and releasing a lock
     69{{{
     70srl_loock_lock( srl_lock_t ) ;
     71srl_lock_unlock( srl_lock_t ) ;
     72}}}
     73* accessing a shared memory space (address and size)
     74{{{
     75void* srl_memspace_addr( srl_memspace_t ) ;
     76size_t srl_memspace_size( srl_memspace_t ) ;
     77}}}
     78
     79Three  platforms are presently supported :
     80 * Any Linux (or Unix)  workstation  supporting the POSIX threads,
     81 * MP-SoC architecture using the MUTEK/D operation system,
     82 * MP-SoC architecture using the MUTEK/S operating system,
     83
     84MUTEK/D is an embedded, POSIX compliant, distributed,  operating system for MP-SoCs,
     85while MUTEK/S is an optimized version: the performances are improved, and the memory
     86footprint is reduced, at the cost of loosing the POSIX compatibility.
     87
     88== C)  Defining the software application ==
     89
     90== D)  Defining the hardware architecture ==
    7091
    7192== E)  Mapping the software on the hardware ==