Hardware/Software Cosynthesis of DSP Systems

Abstract

This chapter focuses on the automated mapping of high level specifications of DSP applications into implementation platforms that employ programmable DSPs. Since programmable DSPs are often used in conjunction with other types of programmable processors, such as microcontrollers and general-purpose microprocessors, and with various types of hardware modules, such as FPGAs, and ASIC circuitry, this mapping task, in general, is one of cosynthesis -the joint synthesis of both hardware and software -for a heterogeneous multiprocessor.Since a large variety of cosynthesis techniques have been developed to date, it is not possible here to provide comprehensive coverage of the field. Instead, we focus on a subset of topics that are central to DSP-oriented cosynthesis -application modeling, hardware/software partitioning, synchronization optimization, and block-processing. Some important topics related to cosynthesis that are not covered here include memory management [1,11,26,37,53], which is discussed in Chapter 10; DSP code generation from procedural language specifications [39], which is the topic of Chapter 7; and performance analysis [36,49,54].Additionally, we focus on synthesis from coarse-grain dataflow models due to the increasing importance of such modeling in DSP design tools, and the ability of such modeling to expose valuable, high-level structure of DSP applications that is difficult to deduce from within compilers for general purpose programming models, and other types of models. Thus, we do not explore techniques for fine-grain cosynthesis [21], including synthesis of applicationspecific instruction processors (ASIPs) [43], nor do we explore cosynthesis for control-dominant systems, such as those based on procedural language specifications [22], communicating sequential processes [50], and finite state machine models [6]. All of these are important directions within cosynthesis research, but they do not fit centrally within the DSP-oriented scope of this chapter.

Goal-Driven Reconfiguration Of Polymorphous Architectures

“…Our work is complementary to such existing efforts and also to work on multiprocessor system synthesis [1][2], which can be used to derive the store of pre-computed configurations that is input to the techniques developed in this paper.…”

SoC Memory Hierarchy Derivation from Dataflow Graphs

“…The memory size for the SW has also increased to store complete rows of data (13 kB), but because of the reuse employed, Eq. (1) indicates that the bandwidth required to the reference frame is reduced to [1] Src0, Src1, 18{A, A, 22{A, B, D, 33{15{C}, 33{C 3.7 MB/s; this is the minimum bandwidth possible, as it only reads each pixel once.…”

“…This requires modification to (1) to account for this cyclic nature; instead of only taking the bytes produced in one firing of B, the number of bytes produced in one execution of the cycle (ρ c ) is used, but is divided by the period of the cycle (L). This yields (2), and it can be noted for static values that the period is 1, while the number of bytes in a cycle is simply the number of bytes in one firing; thus, (2) is a generalised form of (1).…”

“…Using a medium sized Virtex-4 device, shown in Table 1, the maximum on chip BRAM resources are 1728 kb; the required memory for the two frames in the motion estimation algorithm is 1792 kb (for 8-bit pixels), implying that off-chip memory is necessary. Analysing the DFG schedule and token sizes can also be used to determine the data transfer bandwidths required using (1).…”

“…A common solution is to raise the level of abstraction and let the target domain determine the specific model of computation (MoC) to be used. Since signal processing applications often exhibit high levels of concurrency, dataflow models are commonly used as they allow the designer to visualise and extract parallelism from the algorithm [1]; they are also a natural and efficient way to model the data dominated operation observed in many of these applications. In addition, the capacity to analyse the dataflow graph (DFG) at compile time and ensure deadlock avoidance and bounded memory execution, for synchronous dataflow (SDF) at least, ensures consistency when transforming and optimising the algorithm and yields low overheads as algorithms can be statically scheduled [1,2].…”