The Dataflow Interchange Format (DIF): A Framework for Specifying, Analyzing, and Integrating Dataflow Representations of Signal Processing Systems Shuvra S. Bhattacharyya, University of Maryland at College Park, with contributions from Chia-Jui Hsu, Ivan Corretjer, Ming-Yung Ko, and William Plishker. University of Wisconsin at Madison, November 29, 2007

Motivation Implementation of digital signal processing (DSP) applications on System-on-chips (SoCs) is a multi-faceted problem Typical design flow consists of several complex steps Implementation constraints and objectives are multidimensional and complex Dataflow-based analysis and optimizations provide an effective class of techniques in the design flow for deriving more efficient solutions

DSP Hardware and Software Implementation Wide range of established and emerging processing architectures Programmable DSPs, FPGAs, embedded multiprocessors, ASICs, etc. Multi-dimensional implementation constraints Performance (latency, throughput, ...) Energy and power consumption Buffering constraints and memory requirements Cost Accuracy DIF provides a framework for designing, optimizing, integrating, and evolving software/firmware code in designs involving heterogeneous components and constraints

Dataflow Models of Computation Used widely in design tools for DSP system design Application is modeled as a directed graph Nodes (actors, components) represent functions. Edges represent communication channels between functions. Nodes produce and consume data from edges. Edges buffer data in FIFO (first-in first-out) fashion. Data-driven execution model A node can execute whenever it has sufficient data on its input edges. The order in which nodes execute is not part of the specification. The order is typically determined by the compiler, the hardware, or both. Iterative execution Body of loop to be iterated a large or infinite number of times Static periodic schedules are often used: a schedule is constructed once and executed over and over again for as many samples that need to be processed. Bounded memory verification is crucial for such schedules because they operate on large, sometimes unbounded volumes of input data.

Example: Dataflow-based design for DSP Example from Agilent ADS tool

Dataflow Example: QAM Transmitter in National Instruments LabVIEW Rate Control QAM Encoder Transmit Filters Passband Signal Source: [Evans 2005]

Dataflow Features and Advantages We emphasize that we employ dataflow primarily as a programming model Exposes high-level structure that facilitates analysis, verification, and optimization. Captures multi-rate behavior. Encourages desirable software engineering practices: modularity and code reuse. Intuitive to DSP algorithm designers: signal flow graphs. A wide range of different programming languages can be derived based on the dataflow framework, depending on the specific form of dataflow (dataflow model) that is chosen as the semantic basis for the language.

DSP Modeling Design Space: Co-design of Dataflow Models and Transformations Verification/Synthesis Simplicity/Intuitive Appeal Expressive Power DDF BDF C PCSDF PSDF MDSDF WBDF CSDF SSDF SDF

DSP Modeling Co-design: Key Challenges Providing increasing expressive power while leveraging techniques and properties from more restricted dataflow models For example, from synchronous dataflow (SDF) Designing static, dynamic, and hybrid scheduling techniques Common bridge between abstract application models and concrete implementations Handling large scale and repetitive graph structures Proving common representations and analysis techniques Across related dataflow models For meta-modeling techniques

High Level Dataflow Transformations A well designed dataflow representation exposes opportunities for high level algorithm and architecture transformations. High level of abstraction  high implementation impact Dataflow representation is suitable both for behavior-level modeling, structural modeling, and mixed behavior-structure modeling Transformations can be applied to all three types of representations to focus subsequent steps of the design flow on more favorable solutions Complementary to advances in C compiler technology (intra-actor functionality) Object oriented methods (library management, application service management) hardware (HDL) synthesis (intra-actor functionality)

Representative Classes of Dataflow Transformations Clustering of actors into atomic scheduling units to incrementally constrain the design space Buffer minimization: minimize communication cost Multirate loop scheduling: optimize code/data trade-off Parallel scheduling and pipeline configuration Heterogeneous task mapping and co-synthesis Quasi-static scheduling: minimize run-time overhead Probabilistic design: adapt system resources and exploit slack Data partitioning: exploit parallel data memories Vectorization: improve context switching, pipelining Synchronization optimization: efficient self-timed implementation

Dataflow Interchange Format (DIF) Project Designing a standard, textual language for specifying dataflow semantics. Dataflow Interchange Format [5, 6] DIF support for configuration of complex graphs [1] Developing a software package for working with, developing, and integrating dataflow models and techniques. DIF package [5] Porting DSP applications across design tools. DIF-based porting methodology [4] Automated derivation of implementations from dataflow modeling specifications. DIF-to-C software synthesis framework [3] Integrating VSIPL support in DIF Intermediate actor library [2] DIF-to-VSIPL software synthesis [2]

The DIF Package DIF representation DIF front-end (language parser) Java classes for representing and manipulating dataflow graphs. DIF front-end (language parser) Translates between DIF specifications and DIF representations. Algorithm implementations Dataflow-based analysis, scheduling, and optimization. Infrastructure Porting Software synthesis

DIF-based Design Flow for Hardware Synthesis HDL-based module libraries, encapsulated and characterized as dataflow components. Application constraints and optimization objectives Dataflow graph analysis and transformations DIF based application model The DIF-based application model can be derived automatically from another dataflow environment, or written directly in DIF. Code generation HDL implementation (Verilog / VHDL) Conventional HDL-based synthesis flow

Trends in FPGA-based System Design Heterogeneous resources Hard vs. soft processor cores Fabric for implementing random logic Domain-specific accelerators (e.g., “DSP slices”) Different kinds of memory resources Potential to customize the interprocessor communication network Optimized IP (intellectual property) modules are highly specialized for specific platforms Performance/cost-trade-offs are highly parameter- and platform-specific

DIF-based design flow for FPGA implementation HDL-based and block-box-IP module libraries Constraints in terms of performance and FPGA resource utilization Characterization: performance and resource costs Platform-specific resource-sharing models Dataflow graph analysis and transformations DIF-based application model Code generation HDL implementation Conventional HDL-based synthesis flow

Next Steps Starting with the current trigger system, model components and subsystems as DIF actors Determine a suitable dataflow model for each module Revise the interface of the module implementation so it is consistent with this dataflow model The module can then be represented as a DIF actor in any DIF program (regardless of how the module is implemented internally) Model system-level interfaces and performance constraints in terms of DIF graph properties Continue our ongoing work on CAL-to-DIF translation Lays a foundation for integrating DIF-based analysis and transformation techniques with the CAL language and Xilinx back-end capabilities.