Achilles: A High-Level Synthesis System. for Asynchronous Circuits. Jordi Cortadella, Rosa M. Badia, Enric Pastor, and Abelardo Pardo y

Transcription

1 Achilles: A High-Level Synthesis System for Asynchronous Circuits Jordi Cortadella, Rosa M. Badia, Enric Pastor, and Abelardo Pardo y Dept. of Computer Architecture Universitat Politecnica de Catalunya (Barcelona) jordic@ac.upc.es y Dept. of Electrical Engineering University of Colorado (Boulder) Abstract This paper presents Achilles, a High-Level Synthesis System for asynchronous digital circuits. A new architecture model based on a completely distributed control structure is proposed. The most relevant dierences from synthesis systems for synchronous circuits appear in the phases of scheduling and synthesis of the control. Signal Transition Graphs are automatically generated to describe the behavior of local controllers. 1 Introduction Asynchronous circuits require no global clock and elude, thus, the problem of clock skew. A task can be executed as soon as their preceding tasks are completed. The computation time of a task depends, in general, on the input data and can be represented by a distribution function with a worst-case and an average delay. The nonexistence of a global clock eases the extendability of asynchronous systems [1]. One-toone local synchronization between modules allows their interconnection without aecting the system's functionality. Furthermore, asynchronism does not add timing constraints that could eventually limit the physical size of the system. However, asynchronism also involves several problems that make circuit design dicult. Metastability, race conditions, and hazard conditions [2] have been topics deeply studied for many years, and design methodologies to synthesize error-free circuits have been proposed [3]. On the other hand, the design of an asynchronous circuit also implies some area penalty due to the overhead required for synchronization, mainly for the routing of dierential signals when using dual-rail encoding in self-timed units. As asynchronous circuits are more extensively used, there is a need of synthesis tools that hide the underlying complexity of their design to the user. Currently, most of the research is focused on the synthesis of asynchronous circuits from signal transition graphs (STGs) rstly introduced by Chu [4]. 7225) Work funded by CYCIT TIC , Dept. d'ensenyament de la Generalitat de Catalunya and ACiD-WG (Esprit

2 Until now, only synchronous architectures have been proposed for high-level synthesis systems. The eorts on synthesis from high-level languages have been mainly focused on the generation of asynchronous circuits by syntax{directed translation [5]. When conceiving synthesis algorithms for asynchronous circuits, the major dierences from those in the eld of synchronous circuits come from the fact of using a dierent timing model. Scheduling and control synthesis are, thus, the steps that need to be rethought when considering an asynchronous target architecture. Until now, the algorithms proposed for scheduling have been based on the existence of a global clock to dene control states [6, 7]. In an asynchronous execution model, the scheduling phase must determine timing precedences which preserve dependencies between operations, with an estimation of the performance according to the average processing speed of the hardware modules used to execute the operations. A centralized control unit approach would neglect most of the attractiveness of asynchronous systems. Global signals introduce delays that reduce the potential parallelism inherent to asynchronism. Furthermore, the number of states of the control unit grows exponentially with the number of control signals [4], which makes the synthesis of control units for large systems prohibitive. Therefore, models based on the distribution of control functions must be proposed for asynchronous systems. This paper presents Achilles, a high-level synthesis system for asynchronous circuits that is currently under development and focuses on those issues that dierentiate it from synthesis systems for synchronous circuits: architecture model, scheduling, and control synthesis. Section 2 describes the target architecture model used in Achilles. An overview of the synthesis system is presented in section 3. The scheduling algorithm is described in section 4. Section 5 explains how control units are generated from the schedule dened for the operations. Finally, section 6 concludes the paper. 2 Architecture Model The architecture model proposed in Achilles is based on two main key-notions: Processing Unit and Channel. A processing unit (PU) is an entity that executes operations. Two PUs can communicate to each other through unidirectional channels. The granularity of a PU may vary from the basic modules given in a library (adder, ALU, multiplexor, register, etc.) to large, complex modules (elliptic lter, microprocessor, etc.). Moreover, at lower levels of abstraction a PU may be composed of other PUs. Each PU consists of a data processing part and a control part. The data processing part is implemented by a self-timed module (either asynchronous or locally-synchronous) that executes operations. The control part manages the communication and synchronization with other PUs. There is no global PU snd(p ) 1 ack_rcv(p ) 1 port 1 channel PU rcv(p ) 2 port 2 ack_snd(p ) 2 Figure 1: Communication Protocol

3 control managing the functioning of the circuit. Thus, control is fully distributed among PUs, which communicate to each other locally. 2.1 Communication Protocol Communication between PUs follows a message passing handshake protocol as illustrated in gure 1. A channel has an active port in one PU (designated as p 1 ) and a passive port in other PU (p 2 ). Four primitives are used to implement the communication protocol: snd(p 1 ): Send data to p 1. rcv(p 2 ): Receive data from p 2. ack snd(p 2 ): Send data reception ack to p 2. ack rcv(p 1 ): Receive data reception ack from p 1. Communication between two PUs is initiated by the active PU (PU connected to the active port). Once the active PU has completed its operation sends the output data to p 1 (snd(p 1 )). The passive PU receives its input data from p 2 (rcv(p 2 )). When the data received from p 2 is no longer required, the passive PU accomplishes an ack snd(p 2 ) and continues its execution. At the other side, the active PU receives the acknowledgment (rcv ack(p 1 )) and continues its execution. 2.2 Behavioral Model for Processing Units In 1 In 2 Repeat R4 R1 R2 R3 In R1 In R2 R4 := R1 R2 Out M1 M2 R3 := R1 R4 R4 := R2 R3 adder Local Control Out R4 For ever (a) R1 Data processing unit (b) Figure 2: (a) Communication Processes and (b) Implemented code The semantics of the model used for the description of the behavior of the PUs must be capable of expressing all the potential parallelism inherent to the asynchronism of the operation execution. Dierent languages have been used to express parallel behavior in hardware, like CSP or ISPS. In Achilles, we have chosen Petri Nets. Two main reasons have endorsed this decision: The ability for Petri Nets to express ne-grain parallelism. The simplicity of translating Petri nets into Signal Transition Graphs[4]. Figure 2(a) depicts a circuit composed of seven processing units: an adder, two multiplexors, and four registers. The operations executed in this circuit are described by the RTL code in gure 2(b). Each PU receives data, performs an operation and sends the result to other PUs through output

4 channels in an asynchronous manner. Figure 3(a) shows the behavioral specication (Petri Net) for multiplexor M2. Actions like rcv(r4), rcv(r2), and rcv(r3) can occur in parallel with other actions like evaluate, snd(alu), and ack rcv(alu). rcv(r2) ack_rcv(alu) evaluate rcv(in1) rcv(in2) ack_rcv(r2) snd(alu) evaluate snd(alu) rcv(r3) ack_rcv(in1) ack_rcv(in2) evaluate snd(out) ack_rcv(alu) ack_rcv(r3) rcv(r4) ack_rcv(alu) ack_rcv(out) ack_rcv(r4) evaluate (a) snd(alu) (b) Figure 3: Petri net for (a) MUX2 and (b) whole circuit With this approach, the whole circuit can also be expressed as a hierarchical structure of PUs. For example, gure 3(b) describes the behavior of the whole circuit. The operation evaluate includes all the operations executed in parallel by all the internal PUs. This description can then be used to consider the circuit as a new PU for more complex circuits. 3 Overview of Achilles Figure 4 describes the main phases of Achilles synthesis system. From a Control{Data Flow Graph, a library of self-timed modules, and a set of constraints, the scheduler denes a partial ordering for the execution of the operations and determines the type of module that will execute each operation. The scheduler generates a Scheduled Control{Data Flow Graph. The Module Binder assigns a hardware module instance to each operation (registers are considered as hardware modules that execute a storage operation). Thus, a processing unit can be dened for each hardware module of the circuit (ALUs, multipliers, multiplexors, registers, etc.). As a starting point, Achilles denes the PUs at the nest level of granularity: one for each hardware module. After module binding, a network of PUs and communication channels can be derived. Moreover, the data processing part of each PU is completely dened. Therefore only the local control of each PU is left to be synthesized. From the Scheduled CDFG and by means of a data{ow analysis, similarly to how optimizing compilers do, the input/output relationships among PUs can be determined and the Petri nets describing the behavior of the local controllers generated (see [8] for a more detailed explanation). Still, the description in terms of Petri nets is independent from the low-level handshaking protocol. These details are dened when a Signal Transition Graph is generated for each local controller: handshake signals, asynchronous or locally-synchronous communications, 2 or 4-phase protocol, dual or single-rail, etc. Next, STGs are merged to reduce the granularity of the distributed control. This step is optional and only applied to reduce the area and improve the performance of tightly-coupled local controllers (i.e.

5 Behavioral Description Compilation Constraints CDFG Module Library (ALU, regs, muxs...) Scheduling & Allocation Scheduled CDFG Module Binding Definition of Processes & Channels Process i Process1 (ALU) Process2 (MUX) Process3 (MUX) Process4 (REG) Local Control Data Processing Unit STG alu STG mux Control Definition STG merging Petri Net STG alu&mux Handshake protocol Dual or single rail Control Sythesis STG mux STG reg STG i Figure 4: Synthesis ow in Achilles. an ALU with its input multiplexors). Finally, an asynchronous sequential circuit is synthesized from each STG. 4 Operation Scheduling in Achilles This section presents the approach used by Achilles for operation scheduling (see [9] for further details). The problem to be solved is nding a partial ordering of the graph vertices which minimizes the total execution time under resource contraints. This partial ordering must preserve both data and structural 1 dependencies between vertices. The total execution time must be calculated by considering the estimated average execution time of each operation. 4.1 Frame Reservation Table (FRT) A Frame Reservation Table F RT r is a data structure that represents the utilization of a resource type r during the execution of the scheduling algorithm. It stores the number of active resources at each time instant. An FRT can also be represented as an Event List. An Event List EL r is a list of ordered pairs < time i ; nfus > where nfus is the number of available instances of type r from time i to time i1. 1 A structural dependency exists between two vertices if they cannot be executed simultaneously due to resource conicts.

6 Figure 5: (a) Frame Re FRT adder EL adder time nfus 0 1 t1 t2 t3 t (a) (b) (c) t -

7 t * * * * * * < Resources: 2 Mult (*) 1 ALU (,-,<) 1 Adder () * Mult ALU Adder

8 Figure 7: (a) ph P1 port X port Y P2 P1 snd(x) req X req Y rcv(y) P2 req X req Y ack_rcv(x) ack X ack Y ack_snd(y) ack X ack Y Data X Data Y req X - req Y - channel (X,Y) ack X - ack Y - (a) (b)