Goals

Goal of this tutorial is to show how DSX can help creating a flexible architecture description in order to achieve early performance evaluation.

DSX overview

DSX targets network or multimedia applications handling packet streams. DSX applications can use a common communication infrastructure composed of shared-memory, locks, fifo channels, ...

On the hardware side, DSX targets multiprocessor system-on-chips. This needs some parrallelization of the embedded software.

DSX assumes only the application designer himself can understand the application enough in order to make it parrallel efficiently. The prefered communication model is a fifo channel where any number of producers and consumers can be attached: the MWMR channels.

A classical DSX application is composed of tasks, all communicating through MWMR channels, preferably using this only means of communication. This splitting has some advantages:

• ease of parrallelization
• ease of migration of any task to hardware coprocessors when needed.

A DSX SoC description is composed of 3 parts:

• An hardware architecture description (a netlist);
• An application, described as a Task graph;
• A valid mapping of the application on the hardware, choosing for each task its actual implementation.

As DSX is a library implemented in the Python language, a DSX application description is actually a python program, in which any control structure or parametrization can be achived.

The MJPEG application

The application showed here is a software MJPEG decoder where:

• coarse-grained parallelization is done two ways:

  • the video stream is split at image boudaries, and distributed among different decoder pipelines

    

  • each decoder pipeline is split in successive tasks

    

• the hardware of the resulting SoC is composed of

  • a global interconnect,
  • local clusters, with some processors and ram, in which we'll implement each image decoding pipeline
  • a local cluster containing image input stream coprocessor
  • a local cluster containing image output framebuffer coprocessor
  

Creating the SoC

The amount of decoder pipelines implemented in the system can be choosen at compilation time, when calling the DSX descpription file (mjpeg.py), passing a numeric argument. Valid values range from 1 to 6.

The compilation process creates

• the embedded software (muteks/soft/bin.soft), composed of
  • the MutekH operating system;
  • some autogenerated glue code;
  • user C code
• the SoC simulator (exe.muteks_hard), using SoCLib components, and having a reference to the embedded software binary image.

Running the application

The exe.muteks_hard file is the main simulator, we can run it with ./exe.muteks_hard. It opens some windows:

• a framebuffer;
• a split TTY, printing messages from the split task;
• a libu TTY, printing messages from the libu task;
• pipeline_* TTYs, printing messages from all tasks from each associated pipeline.

Moreover, the terminal where we launched the simulator periodically prints the simulation speed.