Visitors for Dataflow and Procedural IR and IR Interpreter

The Gang Of Four in Design Pattern [165] defines a visitor as: "Represent an operation to be

performed on elements of an object structure. A visitor lets you define a new operation without changing the classes of the elements on which it operates". In Orcc visitors, patterns are used

to traverse the Dataflow and Procedural IR for code analysis, IR to IR transformations, IR optimizations passes, and code generation.

The Orcc Interpreter is implemented as a Visitor that executes for each Object in the Dataflow and Procedural IR a set of functions that represent the interpretation and execution of the IR Object.

3.7 Conclusion

In this chapter, the notion of dataflow parallel programming has been illustrated. A formal behavioral description called CAL has then been introduced and presented through a collec- tion of CAL source code examples. Concepts like actors, actor composition, actions, guards, priorities, finite state machine have been illustrated. As presented, the CAL and its Dataflow MoC has the property to express an application as network processes. Beside that fact that is inherently concurrent and modular, CAL offers parallelism scalability, no shared memory between the process, communication with queues, state encapsulation, sequential execution inside each process provided by finite state machines and bitwise types. All previous proper- ties lead to the portability of CAL which makes it a potential candidate for unifying the system level design for heterogeneous platforms.

A standardized subset of CAL called RVC-CAL and RVC standard and its compiler were also described. Moreover, an in-depth illustration of a compiler infrastructure and its Dataflow

3.7. Conclusion

and Procedural IR called Open RVC-CAL Compiler. Despite the fact that Dataflow IR makes it useful to describe most of the dataflow MoCs, limitations due to early decisions made by its original developers are perceived. First of all, the mandatory ordering of the actions makes indeterministic actors deterministic. Secondly, the absences of an action selection class in the IR makes the construction of an action sequencer for each platform implementation tedious. To construct a new scheduler, a back-end developer should visit all the patterns of actions and the FSM class of the actor and should extract the guard part of the actions. Thirdly, the guard of an action is an expression whose transformation into a procedure makes the analysis of the firing condition more difficult. In the Conclusion chapter, a better IR structure will be discussed. Finally, this chapter described all needed information on the Orcc’s Dataflow and Procedural IR that is used in the following chapter. The following chapter is about the RVC-CAL high-level synthesis tool called Xronos. This tool extends Orcc IRs and implements missing compilation techniques that are necessary for high-level synthesis.

4

High-Level Synthesis of Dataflow Pro-

grams: Xronos

Njeriu në jetë ka nevoj për një filxhan shkencë, një shishe kujdes, dhe një oqean durim, "Man in life needs a cup of science, a bottle of care, and an ocean of patience" — Ismail Kadare

4.1 Introduction

The first implementation of a direct path to HW generation, called CAL2HDL, from CAL dataflow program has been reported by Janneck and al. in [146]. CAL2HDL was a part of the OpenDF [147] framework for developing CAL programs. At first it transforms a CAL actor to an intermediate representation called XML Language Independent Model (XLIM). Secondly, OpenForge is used to generate a Verilog description of the XLIM. OpenForge was initially developed by Xilinx under the name Forge until it became available as open source in 2008 and renamed as OpenForge. CAL2HDL supports only a subset of CAL (for instance synthesis of unsigned integer types, procedures with arguments and action input/output patterns with multi-token lists are not supported). Thus, the unification of software and hardware development is limited. Rewriting an elegant and compact piece of code into a version that could be synthesized, for very complex applications, is especially resource consuming and an error prone task (i.e. a parser of a video decoder).

As described in Section 3.4, a subset of CAL was standardized by ISO MPEG in ISO/IEC 23001-4 with the purpose to become the reference software code for video coding specifications. There was a need to support the full specification of the RVC-CAL standard to facilitate the creation of video codec circuits. An early attempt was made in [166]. Yet, it lacked loop support and was therefore never finalized. In [2] an XLIM backend for Orcc was developed for unifying the software and hardware code generation. However, support of multi-tokens on input and output port was missing. In addition, the code generation process when dealing with complex design such as AVC/H.264 video decoder was very slow. Then Jerbi and al proposed an interesting solution for the multi-token support in [167]. This approach was based on transforming the Orcc’s IR of actors by modifying the actor’s finite state machine and by

Compiler Infrastructure Code Generation Synthesis or Compilation Implementation Profiling and Analysis Performance Estimation RVC-CAL (Behavioral Description) Architecture Constraints R ef ac to ri n g D ir e ct io n s C o m p il e r D ir ec ti ve s ir Procedural Optimizations Pruned SSA CDFG Action Selection + Procedures Unconstrained Scheduling Allocation & Binding Verilog SW Interface Wrappers C++ HW Interface Wrappers C++ Actor and Network Template Xronos SystemC SystemC Actor and Network Template SystemC Interface Wrappers Interface Procedural Optimizations

Figure 4.1 – Xronos in the Design Flow.

introducing to the IR the equivalent of mono-token actions. Although this represented a solution to the problem, it resulted into an excessive sequentialization of equivalent actor states. As a result, overall latency was increased, the overall performance was reduced, and also the resources were increased.

Xronos has been coded from scratch but it can be seen as an evolution of the CAL2HDL and the work done in [2]. Xronos was created with the purpose to resolve all the above stated problems and to accelerate the code generation. It uses Orcc as the RVC-CAL frontend and OpenForge as a backend for generating synthesizable Verilog code for each actor. To be precise, Xronos is the middle-end between these tools. Firstly, it transforms the IR of ORCC with a set of transformations/optimizations. Secondly, it turns the IR to a Control-and-Data Flow Graph so that OpenForge can generate a Verilog representation of the actor. After that, Xronos produces C++ source code for a general purpose and embedded processing platforms. Finally, it generates code for the hardware and software interfaces for heterogeneous platforms. Table 4.1 summarizes the features and contributions of this thesis. All features in bold have