Design Automation

Reconfigurable Logic Modeling

Using an HDL for FPGAs improves designer
productivity.

by Kevin Kwiat and Warren Debany

Over the last 50 years, the enabling circuit technology in the electronics industry has evolved from relays and vacuum tubes to discrete transistors, to systems-on-a-chip with millions of transistors in a single package. During this period, designers have had to make a decision between placing a given function in hardware or in software. Traditionally, hardware has been synonymous with speed, while software has been associated with flexibility. Now, however, new digital circuit technologies are blurring the distinctions between these functions.

An early innovation in computing was to store frequently used, unchanging software permanently in read-only memory (ROM). Using dynamically reconfigurable FPGAs, the complement to ROM storage is now possible: infrequently used, changing hardware can be downloaded into programmable logic elements. Atmel Corp. (San Jose, CA), a developer of dynamically reconfigurable FPGAs, has trademarked the term "Cache Logic" to describe this technique. Using dynamic reconfigurability, engineers can create FPGA-based systems that adapt to the demands of various computational tasks through hardware reuse.

At the U.S. Air Force's Rome Laboratory (Rome, NY), engineers have taken the idea of Atmel's Cache Logic one step further. Unhappy with the inability of current FPGA CAE environments to simulate the dynamics of the FPGA programming process, they experimented with tools that support the development of dynamically reconfigurable FPGAs for adaptive multiprocessing and fault tolerance. At the Rome Laboratory, engineers generate VHDL models of dynamically reconfigurable FPGAs and execute them in the V-System/VHDL simulation environment created by Model Technology Inc. (Beaverton, OR). VHDL does more than describe the static hardware--it assists in verifying that a virtual FPGA that is much larger than the physical FPGA has been created. This verification would be impossible without explicit consideration of the intermediate reprogramming steps.

Exploiting reconfigurability Configuring the logic concurrently with device operation, overlaying layouts to preserve cell configurations, and self-reconfiguration are some of the schemes used to fully exploit the FPGA's versatility. Using dynamic reconfiguration, engineers achieved, within a single FPGA having 5 usable kgates, high-speed designs that would otherwise exceed 20 kgates. Time for reconfiguring between functions depends on how many cells need reprogramming. Reconfiguration time can be reduced by programming only the differences between functions. To selectively reprogram the FPGA on a cell-by-cell basis, it is important to adopt a bottom-up modeling process (see Figure 1).

After technology mapping, a logic function in the FPGA consists of specifications for each logic cell that make up that function. Engineers initially created models of the unprogrammed
FPGA in the netlist intermediate form (NIF)--a language developed at the Rome Laboratory for the transfer of digital design data. The translator that generated the NIF models for the FPGA, formatted the simulation vectors that programmed the FPGA and, simultaneously, applied the "mission vectors" that exercised the intended user functions. Engineers then translated these NIF models into netlists for gate-level fault simulation. In addition, the NIF model was translated to VHDL for eventual simulation using V-System/VHDL.

Figure 1. To reprogram the FPGA on a cell-by-cell basis, it was necessary to adopt a bottom-up FPGA modeling process.

NIF NIF contains only structural information. No behavioral or functional data are included. NIF is an intermediate target language for a set of translators that convert files between simulation languages. This is far more efficient than writing a direct translator from every language of interest to every other simulator language. Other languages have been developed expressly for the purpose of transferring design data. For example, the Electronic Design Interchange Format (EDIF) allows a user to describe many types of data. NIF's description of gate interconnections is more convenient than EDIF's because it can be translated into multiple HDLs for different types of simulation, as well as because EDIF-to-NIF and NIF-to-EDIF translators have already been built.

NIF handles purely structural descriptions of designs at the gate or block level. A model contains macros (for hierarchical descriptions) and a main model. Macros and the main model have the same syntax. The building blocks are components, which each have a name, type, inputs, and outputs. Inputs and outputs are lists of signals. A component type is either the name of a predefined macro or is assumed to be a primitive (a primitive can be a NAND gate, for instance). NIF does not interpret or give meaning to primitives--that is solely the task of the translators.

Figure 2. A bus component resolves the outputs of cells connected to the same row or column bus.

FPGA generation An FPGA model consists of cells, buses, and internal programming logic. The FPGA implementation that we use for this article is based loosely on Atmel Corp.'s AT6000 architecture.

The FPGA is modeled with the following conventions. Each component cell's A, B, and four bus outputs are labeled using the cell's coordinates as a prefix. In addition, output signals that are put on a bus are given an "o" suffix. As a result, CELL1_2 produces outputs 1_2A , 1_2B , 1_2NS1o , 1_2NS2o , 1_2EW1o , and 1_EW2o ). Fanout of a cell's A and B outputs are always connected to the adjacent cell. The connections to a cell are determined by the cell's coordinates. Component-type CELL is a macro described at the gate level. Figure 2 shows the NIF declaration of CELL2_2 . A bus component resolves the outputs of cells connected to the same row (or column) bus.

Exhaustive simulation of the behavioral cell verified that its output responses were identical to those of its structural version. By simply deleting the cell macro from the NIF model and inserting the cell's corresponding behavioral code in the VHDL library, a more abstract FPGA model was generated in which every structural cell was replaced with its behavioral counterpart. This resulted in a decrease in the simulation times for the adaptive system and an increase in the size of the FPGA models that the V-System/VHDL simulator could support. Carrying the abstraction process further, collections of cells that perform various FPGA functions were given behavioral descriptions and connected, using NIF, to ultimately produce a behavioral VHDL description for the entire FPGA.

An FPGA's logic cell specification determines the operating function and interconnect structure. An interpreter can convert the logic into code for HDL simulation as well as put data into an appropriate format for ROM storage. Note that the interpreter simultaneously creates the NIF model of the FPGA and its programming data.

To reduce both the model complexity and the simulation times, cells that are unused in every configuration (during the current simulation) can be replaced by stubs of full cells. A stub is a cell with all programming logic removed. The cell's architecture is reduced to that of disabled bus drivers, input sinks, and an output that sources a constant zero.

Cells can be programmed by either specifying a standard state (combinational, sequential, or constant), or by individually defining each programming bit. A programming language example appears in Figure 3. In this example, the interpreter will generate the vectors to set CELL2_2 's programming bits for the standard (predefined) combinational state cs20. This state calls for the cell to be configured as a two-input (A and B) multiplexer with output selection provided by a bus. For its inputs, CELL2_2 uses the output of its Northern and Eastern neighbors for A and B, respectively. Bus ns1 determines the selection for the cell's multiplexer function. Fanout of the output is always connected to the adjacent cells; however, the A output in this example is also routed to the ew2 bus. The individual setting of program bits is performed when bus connections between cells must "turn corners" (from East-West to North-South, for example).

Figure 3. The programming language example illustrates how the code identifies and programs the cells in an FPGA.

Data vectors that exercise the operation of the programmed FPGA also appear in this programming language. When the interpreter encounters these vectors, they are formatted for application to the FPGA's primary inputs. During initial programming of the device, "don't care" values (X's) are placed on the data inputs. Thereafter, data vectors can be flagged so they will be simultaneously applied with the serial program data.

Translation to VHDL The translation from NIF to VHDL was straightforward because the FPGA models that were created were purely structural. The VHDL models were based on a four-valued logic--0, 1, X, and Z.

The NIF-to-VHDL translator automatically creates VHDL code. Component instantiations were mapped one-for-one from the NIF model. The precompiled gate-level library does not usually contain every gate-type needed for every logic model. Thus, the translator also creates the behavioral code for the missing gate-types.

The translator also creates a customized VHDL testbench that reads ASCII vectors and writes the stimulus/response data as an ASCII file. This testbench permits the same test vectors to be used for emulation in VHDL or fault graded in another HDL. Furthermore, these input/output data formats are compatible with a wide array of vector preprocessors and postprocessors developed at the Rome Laboratory.

Figure 4. This basic adaptive system is the high-level schematic for a VHDL model of a board translated from NIF.

VHDL simulations Once translated to VHDL, the FPGA model was simulated in the V-System/VHDL environment. This VHDL tool set was used because it was available on both the PC and Sun SPARC workstation, and our CAD tools were distributed between these two platforms.

Data vectors in the FPGA simulations were combined with programming bits to verify the dynamic reprogrammability of the device--even while it is operating. Reprogramming an FPGA when it is in a system requires support chips. Figure 4 shows the high-level schematic of a VHDL model of a board translated from NIF.

The ROM and FPGA controller are components declared in NIF, but their behavior is defined in a VHDL library. The FPGA component is a NIF macro composed of many other macros and translated to a detailed structural VHDL model.

A state machine in the FPGA controller coordinates FPGA programming and execution. The controller receives a signal from the VHDL testbench to initiate FPGA programming. In non-reconfigurable designs, VHDL testbenches apply stimulus after every clock cycle. Applying vectors for a function that is not completely configured would yield meaningless results. Thus, to reduce the size of the vector file, the testbench applies data vectors to the model only when signaled to do so by the controller. Engineers simulated reprogramming the FPGA with a new function, while it simultaneously performed an existing function. The simulations confirmed signal and data integrity by using data vectors applied to the FPGA's inputs during the transition.

Reloading functions using virtual ICs Because all cells are reprogrammable, the FPGA can be used repeatedly to perform many different functions, with groups of cells making up virtual ICs (VICs). The VICs are rarely active at the same time. Therefore, an algorithm implemented in the FPGA begins with only a subset of its functions. Because FPGA modification occurs dynamically, new VICs are loaded during the functional latency. The functions can also exhibit a locality of reference so that loading of future VICs occurs in anticipation of their need. Control of the modification process is necessary to properly place a requested VIC and to ensure that a currently active VIC is undisturbed. We apply dynamic reconfiguration to the control process itself. Figure 5 shows the partitioning of functions. At boot-up, the initial controller function (fcn 0) is configured by loading a counter with a "0" count. This is the starting address for fcn 0 stored in ROM. As the count proceeds, fcn 0 is loaded into the FPGA. The count is then halted by this function. All requests for FPGA functions are made through fcn 0. As shown in Figure 5, a request for fcn 13 is made to fcn 0. The starting ROM address is loaded into the counter.

Figure 5. The flow diagram shows how the external counter and ROM load functions into the FPGA. A request for fcn 13 is made to fcn 0, which is previously loaded from the ROM and resident in the FPGA.

The loading of fcn 0 is under control of the counter. The counter generates the ROM address bits and also addresses the FPGA cells for programming. A binary code stored in the ROM indicates the end of the function (EOF). The controller function fcn 0 halts the counter once it recognizes that an EOF has been read. After boot-up, fcn 0 receives all function requests and coordinates dynamic reconfiguration of the FPGA. As coordinator for the dynamic reconfiguration process, fcn 0 is never overwritten by another function. This function is analogous to the software that implements a page-replacement algorithm in a main-memory management scheme. It never allows itself to be paged out to disk because it would have no way to return. By applying dynamic reconfiguration, the complexity of the external FPGA controller shown in Figure 5 is reduced to that of a simple counter.

Conclusion Creating an adaptive system is now possible thanks to FPGA technology. Until recently, the only way to demonstrate the capabilities of these systems was to use the actual FPGAs. To prototype an adaptive system more rapidly, a strategy has been implemented to model versatile FPGAs. This strategy has been applied in the transfer of FPGA designs to VHDL, where the FPGA's full versatility is more effectively demonstrated and verified. The automated process creates the VHDL description of the FPGA for simulation at different levels of abstraction.

Kevin Kwiat and Warren Debany are with the Diagnostics Research Branch of the USAF Rome Laboratory, Rome, NY. They work in the areas of fault-tolerant computing, fault simulation, BIST, and diagnostics integration. They both received their doctorates from Syracuse University.

To voice an opinion on this or any Integrated System Design article, please e-mail your message to michael@isdmag.com.

integrated system design  December 1996