Application¶
DSX models the application in a split way:
- The Tasks are the basic computation element,
- The Task and communication graph connects the tasks around communication resources.
The application is composed of tasks. They are self-contained and perform a single computation in the whole application. An application needs many tasks to be complete.
Depending on the parallelism paradigm chosen by the application, different tasks will share the workload in different ways. Some applications have many similar tasks working in different elements of the datastream; other applications have a set of successive tasks working on the same datastream in a pipelined fashion. DSX permits both.
Communication is modeled around the communication resources.
Communication resources¶
DSX has some built-in communication resources included.
Todo
User can provide its own. Document adding communication resources
Built-in communication resources are presented here.
MWMR channel¶
MWMR channels are the preferred way of modeling the communication in DSX. They offer several features:
- They can be accessed from hardware or software tasks transparently.
- They can fit most parallelism paradigms: KPN, task-farm, work-queue.
- They are efficient
- They require a minimal memory footprint.
Todo
cite etienne
MWMR channels are multi-writer, multi-reader fifo channels conveying items of fixed width. An item is always copied atomically from/to a channel. Items are guaranteed to transit in order in a channel, but contiguity is not asserted. This is a side-effect of the multi- feature. Read and/or writes can be interleaved on an item boundary. As a subset of the multi-writer/reader setup, an MWMR channel with only one writer and one reader behaves exactly like a bounded KPN channel.
Mwmr channels can be declared through the description API, and can be used through the C API.
Lock¶
Locks are — with shared-memory buffers — another well-known shared-memory-based communication primitive. They offer exclusive temporal access to an associated resource. DSX offers such a primitive implemented as a mutex. Semantically binding the lock to another shared resource is up to the application designer.
Locks can be declared through the description API, and can be used through the C API.
Synchronization barrier¶
Synchronization Barriers are an usual feature of parallel workflows. They ensure all tasks involved in a computation meet at a defined point in the program before going on.
DSX offers such a primitive.
Barriers can be declared through the description API, and can be used through the C API.
Constant¶
This is not a communication resource per se, but simply a per-instance constant value. This can help sharing the code of a task, yet differentiating the different instances.
Constants needs no declaration, and can be directly used as integers.
Tasks¶
Task can be associated to three concepts:
- A Task model is an abstract definition of the task from the Task and communication graph point of view.
- Task instance is the actual presence of the task once or many times in the graph.
- Task implementations are containing the code associated to the task model. One model may have many interchangeable implementations.
Task Model¶
A Task model defines a Task as seen from the outside. It corresponds to:
- a name,
- some ports that will be assigned to resources on instantiation,
- some parameters that must be specified in instantiation.
Task models can be declared through the description API.
Task Instance¶
Task instantiation is done when building a Task and Communication Graph. On instantiation, each task’s port must be associated to a compatible resource, and valid instance parameters.
Task instances can be created through the description API.
Task implementations¶
When declaring a Task model, implementations have to be specified. There can be any number of implementations, but at least one is necessary if TCG is to be implemented.
Software implementation¶
This is an implementation of a task corresponding to compilable C (or any gcc-supported language) code. The corresponding code must use the C Task API: System Resource Layer middleware. This ensures the code can be compiled on all supported backends.
A software task can be used:
- on a workstation,
- on a SoC with a MutekH-based operating-system,
- as a synthetic task.
Designers must take extra care for portability of their code. Endianness and data word widths can vary from one target to another.
Software Task implementations can be declared through the description API.
Hardware implementation¶
Hardware implementation of a task can correspond to either:
- An hardware module that can be interconnected through an mwmr-controller,
- An hardware module that got synthetized from a high-level source code (like C code for instance).
Hardware Task implementations can be declared through the dedicated APIs in hardware component library support package, like soclib.hwtask.MwmrCoproc.
Synthetic task¶
Synthetic implementation of a task is the software implementation of the task running as a coprocessor, wrapped in a transactor component making it act as a soclib.hwtask.MwmrCoproc. This is done by the soclib.hwtask.SyntheticTask class.
Having a software task acting as an hardware one can help evaluating the relevance of creating a coprocessor without actually implementing it.
Task and Communication Graph¶
A Task and Communication Graph is a bipartite graph where:
- nodes are task instances and communication resources,
- edges are connections from the ports of tasks to the associated communication resources.
All the communication in the application is explicit.
Example representation of a TCG composed of a producer task and a consumer task connected through an MWMR channel.