Changes between Version 13 and Version 14 of DsxDocumentation


Ignore:
Timestamp:
Jan 29, 2008, 12:22:51 PM (17 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DsxDocumentation

    v13 v14  
    2626 * 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).
    2727 * 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''.
    28  * 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.
    29  * 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.
    30  * DSX supports the POSIX compliant [https://www-asim.lip6.fr/trac/mutekh Mutek]  OS kernel for embedded MPSoCs
    31  * Finally, DSX defines the DSX/L language, based on PYTHON, that allows the system designer to describe in a single file the Task & Communication Graph (TCG), the MP-SoC hardware architecture, and various mapping of the TCG on the MP-Soc architecture.
     28 * 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.
     29 * 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.
     30 * DSX supports the '''POSIX''' compliant [https://www-asim.lip6.fr/trac/mutekh Mutek]  OS kernel for embedded MPSoCs
     31 * Finally, DSX defines the '''DSX/L''' language, based on PYTHON, that allows the system designer to describe in a single file the Task & Communication Graph (TCG), the MP-SoC hardware architecture, and various mapping of the TCG on the MP-Soc architecture.
    3232
    3333The DSX/L script execution generates the binary code executable on the workstation, the
     
    3838
    3939We want to map the multi-threaded software application on several hardware platforms,
    40 without any modification of the task code. One important platform is a POSIX compliant
     40without any modification of the task code. One platform is a POSIX compliant
    4141workstation, as we want to validate the multi-threaded software application on a
    4242workstation before starting the mapping on the MPSoC architecture.
    4343
    44 DSX defines a '''system Ressource Layer''' API (SRL), that is an abstraction of the synchronization
    45 and communication services provided by the various target platforms. The SRL API helps
     44DSX defines a '''system Ressource Layer''' API , that is an abstraction of the synchronization
     45and communication services provided by the various target platforms. The SrlApi helps
    4646the C programmer to distinguish the embedded application code from the system code used for
    4747inter-tasks communications and synchronizations.
    4848
    49  * Communications : blocking & non-blocking Read & Write access to a MWMR channel
    50 {{{
    51 void srl_mwmr_read( srl_mwmr_t, void * , size_t ) ;
    52 void srl_mwmr_write( srl_mwmr_t, void * , size_t ) ;
    53 
    54 size_t srl_mwmr_try_read( srl_mwmr_t, void * , size_t ) ;
    55 size_t srl_mwmr_try_write( srl_mwmr_t, void * , size_t ) ;
    56 
    57 void srl_mwmr_flush( srl_mwmr_t ) ;
    58 }}}
     49 * blocking Read & Write access to a MWMR channel
     50    * '''srl_mwmr_read( )'''
     51    * '''srl_mwmr_write( )'''
     52 * non blocking Read & Write access to a MWMR channel
     53    * '''srl_mwmr_try_read( )'''
     54    * '''srl_mwmr_try_write( )'''
     55 * flush a MWMR channel
     56    * '''srl_mwmr_flush( )'''
    5957 * Synchronization barrier
    60 {{{
    61 void srl_barrier_wait( srl_barrier_t ) ;
    62 }}}
     58    * '''srl_barrier_wait( )'''
    6359 * taking and releasing a lock
    64 {{{
    65 srl_loock_lock( srl_lock_t ) ;
    66 srl_lock_unlock( srl_lock_t ) ;
    67 }}}
     60    * '''srl_loock_lock( )'''
     61    * '''srl_lock_unlock( )'''
    6862 * accessing a shared memory space (address and size)
    69 {{{
    70 void* srl_memspace_addr( srl_memspace_t ) ;
    71 size_t srl_memspace_size( srl_memspace_t ) ;
    72 }}}
     63    * '''srl_memspace_addr( )'''
     64    * '''srl_memspace_size( )'''
    7365
    7466Three  platforms are presently supported :
     
    8779
    8880As an example, the following figure describes the TCG corresponding to an MJPEG decoder application.
     81
     82[[Image(MjpegCourse:mjpeg.png)]]
     83
    8984The two TG & RAMDAC tasks will be implemented as hardware coprocessors : the TG component implements a wire-less receiver for the MJPEG stream, and the RAMDAC component is a graphic display controller.
    9085The 5 other tasks can be implemented as ''software tasks'' or  as ''hardware tasks''. In this particular example,
     
    149144the number of bytes to be reserved.
    150145{{{
    151 my_buffer = Memspace( ''buiffer_name', size )
     146my_buffer = Memspace( 'buffer_name', size )
    152147}}}
    153148In the mapping section of the DSX/L program, the 2 following software objects must be placed :
     
    210205
    211206# creation of a cache controler
    212 my_Cache = Xcache( 'cache',
     207my_cache = Xcache( 'cache',
    213208                        dcache_lines = 32,
    214209                        dcache_words = 8,
     
    230225{{{
    231226# components instanciacion
    232 my_Proc0 = Mips( 'proc0' )
    233 my_Cache0 = Xcache( 'cache0' )
    234 my_Proc1 = Mips( 'proc1' )
    235 my_Cache1 = Xcache( 'cache1' )
    236 my_Ram = MultiRam( 'ram' )
    237 my_Crossbar = LocalCrossbar( 'crossbar' )
     227my_proc0 = Mips( 'proc0' )
     228my_cache0 = Xcache( 'cache0' )
     229my_proc1 = Mips( 'proc1' )
     230my_cache1 = Xcache( 'cache1' )
     231my_ram = MultiRam( 'ram' )
     232my_crossbar = LocalCrossbar( 'crossbar' )
    238233                     
    239234# components connexion
     
    243238my_crossbar.getTarget() // my_cache1.vci
    244239my_crossbar.getInitiator() // my_cache0.vci
    245 }}}
    246240}}}
    247241
     
    332326== E)  Mapping the software on the hardware ==
    333327
    334 This section describes the DSX/L syntax used to map the software objects on the hardware architecture.
     328At this point, we have defined the object '''my_tcg''' (defining the software application), and the object '''my_architecture''' (defining the hardware architecture).
     329This section describes the DSX/L syntax used to map the TCG on the hardware architecture.
    335330
    336331=== E1) Mapper declaration ===
    337332
     333AS it is possible to define various mapping for a given TCG, and a given architecture, we must define a third object : this ''mapper'' will contain all the mapping directives defined by the system designer.
     334{{{
     335my_mapper = Mapper( my_tcg, my_architecture )
     336}}}
     337
    338338=== E2) Mapper definition ===
    339339
     340The mapper has a method ''map()'' that is used to assign a software object to an hardware component.
     341An hardware component can b a processor, or a segment associated to an embedded memory bank,
     342or a segment associated to an addressable peripheral.
     343{{{
     344# Mapper definition
     345my_mapper = Mapper( my_tcg, my_architecture )
     346 
     347# a segment seg_x is designated by my_architecture.seg_x
     348
     349# For a MWMR channel, 4 software elements must be placed
     350my_mapper.map( my_channel, 
     351        lock = my_archi.seg_locks,  # The lock protecting the channel is placed in segment seg_locks
     352        status = my_archi.seg_data,  # The channel status is placed in segment seg_data
     353        desc = my_archi.segdata, # The channel descriptor is placed in segment seg_readonly
     354        buffer = my_archi.sgdata ) # The channel buffer is placed in segment seg_data
     355
     356# for a software task, 4 software objects must be placed
     357my_mappe.map( my_task,
     358        desc = my_archi.seg_data,  # The task descriptor is placed in segment seg_readonly
     359        status = my_archi.seg_data,  # The task state is placed in segment seg_data
     360        stack = my_archi.seg_data,   # The private task stack  is placed in segment seg_stack
     361        run = my_archi.cpu0 )   # task will be running on cpu0
     362}}}
     363
    340364== F)  Code generation ==
    341365