Part III: Mapping Designs to Reconfigurable Platforms 275
15.4 The Interface to Module Generators
As in many hardware design flows, individual hardware cells (in our case, the circuits used as HWOPs), are retrieved from a library. Instead of static cells, however, a more flexible approach uses procedural module generators to tailor these circuits to fit current requirements. For example, a multiplier might have eight pipeline stages in one context and only four in another, matching it to the latency/clock speed of the rest of the datapath. No longer a passive collection of cell descriptions, the library now becomesactive: It accepts a set of constraints from another part of the flow and delivers a matching circuit.
The very flexibility of these parametrized generators complicates their inte- gration with the rest of the tool flow: Other tools need not only the circuit description in the form of a (possibly preplaced) netlist but also data about this specific instance. Different tools are interested in different aspects of the
15.4 The Interface to Module Generators 327 circuit. This plethora of cellviews, combined with the sheer volume of the design space covered by each parametrized generator, precludes a simple enumeration of all alternatives. Thus, the traditional static library data files, holding tables of delays, bounding boxes, and the like, for a set of fixed parameter values, become impractical.
The Flexible API for Module-based Environments (FLAME) [11] is one approach to overcoming these difficulties. It consists of three major components:
(1) the communications interface between the generator library and the other flow tools, (2) the design data model, and (3) the library specification.
A reference realization of a FLAME-based generator library exists in the form of the Generic Library for Adaptive Computing Environments (GLACE) [14].
This package has successfully been used in the COMRADE compiler [7], which compiles C into hybrid hardware/software applications for adaptive computer systems. GLACE uses a Java-based FLAME implementation, but could be called from other languages using the Java Native Interface (JNI).
15.4.1 The Flow Interface
The communications infrastructure and API provided by the FLAME Manager (Figure 15.8) replace static library files with an active function call–based inter- face. Clients in the main design flow can thus enter into a dialog with the module libraries and retrieve data specific to the actual parameter values of the cur- rent instance. In GLACE, the client queries accepted by the FLAME Manager are forwarded to the circuit generation code [6], resulting in the retrieval of circuit characteristics, or the creation of actual netlists.
15.4.2 The Data Model
The information exchanged in this manner just described is represented using the FLAME design data model. This model is partitioned into a number of task- specific views: A frontend compiler might request a “behavior” view to determine which functions are available for a given target technology. Later on, it could
FLAME Manager
FLAME interface FLAME
interface Design data
Module generator library
Replies
Main design flow
add
mult
logic
abs
Queries
Placement
Compaction Mapping
FIGURE 15.8 IFLAME system overview.
query for a “synthesis” view to retrieve area and timing characteristics for a specific module instance. Additional views include “topology” for layout shapes and port pitch, and “netlist,” “placed,” and “mapped” views describing the circuit itself. For the latter, standard formats such as EDIF are encapsulated inside the FLAME messages.
15.4.3 The Library Specification
The FLAME library specification describes a set of behaviors and interfaces.
One or more of these can be attached to a hardware cell to precisely define its function for automatic use by another tool. For example, the cell of a runtime controllable adder/subtractor might have both the addition and subtraction behaviors attached. The interface carefully distinguishes between the logical (e.g., the operands of the adder) and the physical perspective (e.g., clock ports and clock enable signals). Furthermore, a FLAME interface extends beyond port specifica- tions such as width and data type to the control characteristics of the cell. This can cover “start” and “done” signals as well as mode switches (e.g., alternating between addition and subtraction). By considering all of these aspects, another tool can choose the cell most applicable to a given task and automatically drive it correctly from the central datapath controller.
15.4.4 The Intra-module Layout
For efficiency, most module generators create circuits whose internal PEs have already been preplaced. In this case, the module generators and the datapath placement tools must agree on a set of common layout conventions. Otherwise, the regular target layout described in Section 15.1.1 will not be achievable.
Figure 15.9 shows such a regular layout, along with the FLAME description of its topology, using an unsigned 8-bit multiplier from GLACE as an example.
Regular datapath area
Overflow detection
Local controller
(TECHNOLOGY "Xilinx" "Virtex" "XCV50PQ240I" "24"
(STATUS QUERYOK "technology ok. area unit is ’CLB’s...") (MATRIX
(SHAPE ) (PORTLOC
(PORTS
( ("a" 7 0) ("b" 7 0) ("start" 0 0) ("out" 7 0) ("done" 0 0) ) (PITCH 2 1) gPort pitch for busses is 2 bits per CLB
(COORD 0 0)
(FOLDING LINEAR) gLayout is not folded )
) )
("CLB" (RECT 4 6 1)) Layout is a single 4x6 CLB rectangle extending 1 unit below baseline g
Datapath baseline
4
Target device has matrix architecture
FIGURE 15.9 I Module topology and FLAME reply.