An Open Framework for Rapid Prototyping of Signal Processing Applications

3.2.1. Overview of Graphiti

A type of graph is registered within the editor by a configuration. A configuration is an XML (Extensible Markup Language [29]) file that describes

(1)the abstract syntax of the graph (types of vertices and edges, and attributes allowed for objects of each type);

(2)the visual syntax of the graph (colors, shapes, etc.);

(3)transformations from the file format in which the graph is defined to Graphiti's XML file format , and vice versa (Figure 2);

Two kinds of input transformations are supported, from XML to XML and from text to XML (Figure 2). XML is transformed to XML with Extensible Stylesheet Language Transformation (XSLT [30]), and text is parsed to its Concrete Syntax Tree (CST) represented in XML according to a LL(k) grammar by the Grammatica [31] parser. Similarly, two kinds of output transformations are supported, from XML to XML and from XML to text.

Graphiti handles attributed graphs [32]. An attributed graph is defined as a directed multigraph with the set of vertices, the multiset of edges (there can be more than one edge between any two vertices). is a function that associates instances with attributes from the attribute name set and values from , the set of possible attribute values. A built-in type attribute is defined so that each instance has a type , and only admits attributes from a set given by . Additionally, a type has a visual syntax that defines its color, shape, and size.

To edit a graph, the user selects a file and the matching configuration is computed based on the file extension. The transformations defined in the configuration file are then applied to the input file and result in a graph defined in Graphiti's XML format as shown in Figure 2. The editor uses the visual syntax defined by in the configuration to draw the graph, vertices, and edges. For each instance of type the user can edit the relevant attributes allowed by as defined in the configuration. Saving a graph consists of writing the graph in , and transforming it back to the input file's native format.

3.2.2. Editing a Configuration for a Graph Type

To create a configuration for the graph represented in Figure 3, a node (a single type of vertex) must be defined. A node has a unique identifier called id, and accepts a list of values initially equal to (Figure 4). Additionally, ports need to be specified on the edges, so the configuration describes an edgeType element (Figure 5) that carries sourcePort and targetPort parameters to store an edge's source and target ports, respectively, such as acc, in, and out in Figure 3.

Graphiti is a stand-alone tool, totally independent of PREESM. However, Graphiti generates workflow graphs, IP-XACT and GraphML files that are the main inputs of PREESM. The GraphML files contain the algorithm model. These inputs are loaded and stored in PREESM by the SDF4J library. This library, discussed in the next section, executes the graph transformations.

3.3.1. SDF4J SDF Graph model

An SDF graph is used to simplify the application specifications. It allows the representation of the application behavior at a coarse grain level. This data flow representation models the application operations and specifies the data dependencies between these operations.

An SDF graph is a finite directed, weighted graph where:

(i) is the set of nodes. A node computes an input data stream and outputs the result;

(ii) is the edge set, representing channels which carry data streams;

(iii) is a function with the number of initial tokens on an edge ;

(iv) is a function with representing the number of data tokens produced at 's source to be carried by ;

(v) is a function with representing the number of data tokens consumed from by 's sink node;

This model offers strong compile-time predictability properties, but has limited expressive capability. The SDF implementation enabled by the SDF4J supports the hierarchy defined in [3] which increases the model expressiveness. This specific implementation is straightforward to the programmer and allows user-defined structural optimizations. This model is also intended to lead to a better code generation using common C patterns like loop and function calls. It is highly expandable as the user can associate any properties to the graph components (edge, vertex) to produce a customized model.

3.3.2. SDF4J SDF Graph Transformations

SDF4J implements several algorithms intended to transform the base model or to optimize the application behavior at different levels.

(i)The hierarchy flattening transformation aims to flatten the hierarchy (remove hierarchy levels) at the chosen depth in order to later extract as much as possible parallelism from the designer's hierarchical description.

(ii)The HSDF transformation (Figure 7) transforms the SDF model to an HSDF model in which the amount of tokens exchanged on edges are homogeneous (production = consumption). This model reveals all the potential parallelism in the application but dramatically increases the amount of vertices in the graph.

(iii)The internalization transformation based on [35] is an efficient clustering method minimizing the number of vertices in the graph without decreasing the potential parallelism in the application.

(iv)The SDF to DAG transformation converts the SDF or HSDF model to the DAG model which is commonly used by scheduling methods [33].

4.2.1. Scheduling Heuristics

Three algorithms are currently coded, and are modified versions of the algorithms described in [38].

(i)A list scheduling algorithm schedules tasks in the order dictated by a list constructed from estimating a critical path. Once a mapping choice has been made, it will never be modified. This algorithm is fast but has limitations due to this last property. List scheduling is used as a starting point for other refinement algorithms.

(ii)The FAST algorithm is a refinement of the list scheduling solution which uses probabilistic hops. It changes the mapping choices of randomly chosen tasks; that is, it associates these tasks to another processing unit. It runs until stopped by the user and keeps the best latency found. The algorithm is multithreaded to exploit the multicore parallelism of a host computer.

(iii)A genetic algorithm is coded as a refinement of the FAST algorithm. The n best solutions of FAST are used as the base population for the genetic algorithm. The user can stop the processing at any time while retaining the last best solution. This algorithm is also multithreaded.

The FAST algorithm has been developed to solve complex deployment problems. In the original heuristic, the final order of tasks to schedule, as defined by the list scheduling algorithm, was not modified by the FAST algorithm. The FAST algorithm only modifies the mapping choices of the tasks. In large-scale applications, the initial order of the tasks performed by the list scheduling algorithm becomes occasionally suboptimal. In the modified version of the FAST scheduling algorithm, the ABC recalculates the final order of a task when the heuristic maps a task to a new core. The task switcher algorithm used to recalculate the order simply looks for the earliest appropriately sized hole in the core schedule for the mapped task (see Figure 10).

4.2.2. Scheduling Architecture Model

The current architecture representation was driven by the need to accurately model multicore architectures and hardware coprocessors with intercores message-passing communication. This communication is handled in parallel to the computation using Direct Memory Access (DMA) modules. This model is currently used to closely simulate the Texas Instruments TMS320TCI6487 processor (see Section 5.3.2). The model will soon be extended to shared memory communications and more complex interconnections. The term operator represents either a processor core or a hardware coprocessor. Operators are linked by media, each medium representing a bus and the associated DMA. The architectures can be either homogeneous (with all operators and media identical) or heterogeneous. For each medium, the user defines a DMA set up time and a bus data rate. As shown in Figure 9, the architecture model is only processed in the scheduler by the ABC and not by the heuristic and edge scheduling submodules.

4.2.3. Architecture Benchmark Computer

Scheduling often requires much time. Testing intermediate solutions with precision is an especially time-consuming operation. The ABC submodule was created by reusing the useful concept of time scalability introduced in SystemC Transaction Level Modeling (TLM) [39]. This language defines several levels of system temporal simulation, from untimed to cycle-accurate precision. This concept motivated the development of several ABC latency models with different timing precisions. Three ABC latency models are currently coded (see Figure 11).

(i)The loosely-timed model takes into account task and transfer times but no transfer contention.

(ii)The approximately-timed model associates each intercore communication medium with its constant rate and simulates contentions.

(iii)The accurately-timed model adds set up times which simulate the duration necessary to initialize a parallel transfer controller like Texas Instruments Enhanced Direct Memory Access (EDMA [40]). This set up time is scheduled in the core which sends the transfer.

The task and architecture properties feeding the ABC submodule are evaluated experimentally, and include media data rate, set up times, and task timings. ABC models evaluating parameters other than latency are planed in order to minimize memory size, memory accesses, cadence (i.e., average runtime), and so on. Currently, only latency is minimized due to the limitations of the list scheduling algorithms: these costs cannot be evaluated on partial deployments.

4.2.4. Edge Scheduling Submodule

When a data block is transferred from one operator to another, transfer tasks are added and then mapped to the corresponding medium. A route is associated with each edge carrying data from one operator to another, which possibly may go through several other operators. The edge scheduling submodule routes the edges and schedules their route steps. The existing routing process is basic and will be developed further once the architecture model has been extended. Edge scheduling can be executed with different algorithms of varying complexity, which results in another level of scalability. Currently, two algorithms are implemented:

(i)the simple edge scheduler follows the scheduling order given by the task list provided by the list scheduling algorithm;

(ii)the switching edge scheduler reuses the task switcher algorithm discussed in Section 4.2.1 for edge scheduling. When a new communication edge needs to be scheduled, the algorithm looks for the earliest hole of appropriate size in the medium schedule.

The scheduler framework enables the comparison of different edge scheduling algorithms using the same task scheduling submodule and architecture model description. The main advantage of the scheduler structure is the independence of scheduling algorithms from cost type and benchmark complexity.

5.3.1. Algorithm Model

The goal of this exploration is to determine through simulation the architecture best suited to the 115km cell RACH-PD algorithm. The RACH-PD algorithm behavior is described as a SDF graph in PREESM. A static deployment enables static memory allocation, so removing the need for runtime memory administration. The algorithm can be easily adapted to different configurations by tuning the HSDF parameters. Using the same approach as in [47], valid scheduling derived from the representation in Figure 16 can be described by the compact expression:

(8Preproc)(4(64(InitPower

(2((SingleZCProc)(PowAcc))))PowAcc))

(64NoiseFloorThreshold)PeakSearch

We can separate the preamble detection algorithm in 4 steps:

(1)preprocessing step: (8Preproc),

(2)circular correlation step: (4(64(InitPower (2((SingleZCProc)(PowAcc))))PowAcc)),

(3)noise floor threshold step: (64NoiseFloorThreshold),

(4)peak search step: PeakSearch.

Each of these steps is mapped onto the available cores and will appear in the exploration results detailed in Section 5.3.4. The given description generates 1,357 operations; this does not include the communication operations necessary in the case of multicore architectures. Placing these operations by hand onto the different cores would be greatly time-consuming. As seen in Section 4.2 the rapid prototyping PREESM tool offers automatic scheduling, avoiding the problem of manual placement.

5.3.2. Architecture Exploration

The four architectures explored are shown in Figure 17. The cores are all homogeneous Texas Instrument TMS320C64x+ Digital Signal Processors (DSP) running at 1 GHz [48]. The connections are made via DMA links. The first architecture is a single-core DSP such as the TMS320TCI6482. The second architecture is dual-core, with each core similar to that of the TMS320TCI6482. The third is a tri-core and is equivalent to the new TMS320TCI6487 [40]. Finally, the fourth architecture is a theoretical architecture for exploration only, as it is a quad-core. The exploration goal is to determine the number of cores required to run the random RACH-PD algorithm in a 115 km cell and how to best distribute the operations on the given cores.

5.3.3. Architecture Model

To solve the deployment problem, each operation is assigned an experimental timing (in terms of CPU cycles). These timings are measured with deployments of the actors on a single C64x+. Since the C64x+ is a 32-bit fixed-point DSP core, the algorithms must be converted from floating-point to fixed-point prior to these deployments. The EDMA is modelled as a nonblocking medium (see Section 4.2.2) transferring data at a constant rate and with a given set up time. Assuming the EDMA has the same performance from the L2 internal memory to the L2 internal memory as the EDMA3 of the TMS320TCI6482 (see [42], then the transfer of N bytes via EDMA should take approximately): transfer cycles. Consequently, in the PREESM model, the average data rate used for simulation is 3.375 GBytes/s and the EDMA set up time is 135 cycles.

5.3.4. Architecture Choice

The PREESM automatic scheduling process is applied for each architecture. The workflow used is close to that of Figure 8. The simulation results obtained are shown in Figure 18. The list scheduling heuristic is used with loosely-timed, approximately-timed, and accurately-timed ABCs. Due to the 115 km cell constraints, preamble detection must be processed in less than 4 ms.

The experimental timings were measured on code executions using a TMS320TCI6487. The timings feeding the simulation are measured in loops, each calling a single function with L1 cache activated. For more details about C64x+ cache, see [48]. This represents the application behavior when local data access is ideal and will lead to an optimistic simulation. The RACH application is well suited for a parallel architecture, as the addition of one core reduces the latency dramatically. Two cores can process the algorithm within a time frame close to the real-time deadline with loosely and approximately timed models but high data transfer contention and high number of transfers disqualify it when accurately timed model is used.

The 3-core solution is clearly the best one: its CPU loads (less than 86% with accurately-timed ABC) are satisfactory and do not justify the use of a fourth core, as can be seen in Figure 18. The high data contention in this case study justifies the use of several ABC models; simple models for fast results and more complex models to dimension correctly the system.