The sequence of steps for FPGA design is similar to the sequence discussed in Section 1.2 , “ Design Flow .” As for any ASIC a designer needs design-entry software, a cell library, and physical-design software. Each of the FPGA vendors sells design kits that include all the software and hardware that a designer needs. Many of these kits use design-entry software produced by a different company. Often designers buy that software from the FPGA vendor. This is called an original equipment manufacturer ( OEM ) arrangement—similar to buying a car with a stereo manufactured by an electronics company but labeled with the automobile company’s name. Design entry uses cell libraries that are unique to each FPGA vendor. All of the FPGA vendors produce their own physical-design software so they can tune the algorithms to their own architecture.
Unfortunately, there are no standards in FPGA design. Thus, for example, Xilinx calls its 2:1 MUX an M2_1 with inputs labeled D0 , D1 , and S0 with output O . Actel calls a 2:1 MUX an MX2 with inputs A , B , and S with output Y . This problem is not peculiar to Xilinx and Actel; each ASIC vendor names its logic cells, buffers, pads, and so on in a different manner. Consequently designers may not be able to transfer a netlist using one ASIC vendor library to another. Worse than this, designers may not even be able to transfer a design between two FPGA families made by the same FPGA vendor!
One solution to the lack of standards for cell libraries is to use a generic cell library, independent from any particular FPGA vendor. For example, most of the FPGA libraries include symbols that are equivalent to TTL 7400 logic series parts. The FPGA vendor’s own software automatically handles the conversion from schematic symbols to the logic cells of the FPGA.
Schematic entry is not the only method of design entry for FPGAs. Some designers are happier describing control logic and state machines in terms of state diagrams and logic equations. A solution to some of the problems with schematic entry for FPGA design is to use one of several hardware description languages ( HDL s) for which there are some standards. There are two sets of languages in common use. One set has evolved from the design of programmable logic devices (PLDs). The ABEL (pronounced “able”), CUPL (“cupple”), and PALASM (“pal-azzam”) languages are simple and easy to learn. These languages are useful for describing state machines and combinational logic. The other set of HDLs includes VHDL and Verilog, which are higher-level and are more complex but are capable of describing complete ASICs and systems.
After completing design entry and generating a netlist, the next step is simulation. Two types of simulators are normally used for FPGA design. The first is a logic simulator for behavioral, functional, and timing simulation. This tool can catch any design errors. The designer provides input waveforms to the simulator and checks to see that the outputs are as expected. At this point, using a nondeterministic architecture, logic path delays are only estimates, since the wiring delays will not be known until after physical design (place-and-route) is complete. Designers then add or back-annotate the postlayout timing information to the postlayout netlist (also called a back-annotated netlist). This is followed by a postlayout timing simulation.
The second type of simulator, the type most often used in FPGA design, is a timing-analysis tool. A timing analyzer is a static simulator and removes the need for input waveforms. Instead the timing analyzer checks for critical paths that limit the speed of operation—signal paths that have large delays caused, say, by a high fanout net. Designers can set a certain delay restriction on a net or path as a timing constraint; if the actual delay is longer, this is a timing violation. In most design systems we can return to design entry and tag critical paths with attributes before completing the place-and-route step again. The next time we use the place-and-route software it will pay special attention to those signals we have labeled as critical in order to minimize the routing delays associated with those signals. The problem is that this iterative process can be lengthy and sometimes nonconvergent. Each time timing violations are fixed, others appear. This is especially a problem with place-and-route software that uses random algorithms (and forms a chaotic system). More complex (and expensive) logic synthesizers can automate this iterative stage of the design process. The critical path information is calculated in the logic synthesizer, and timing constraints are created in a feedforward path (this is called forward-annotation ) to direct the place-and-route software.
Although some FPGAs are reprogrammable, it is not a good idea to rely on this fact. It is very tempting to program the FPGA, test it, make changes to the netlist, and then keep programming the device until it works. This process is much more time consuming and much less reliable than performing thorough simulation. It is quite possible, for example, to get a chip working in an experimental fashion without really knowing why. The danger here is that the design may fail under some other set of operating conditions or circumstances. Simulation is the proper way to catch and correct these potential disasters.
Figure 8.1 shows the Xilinx design system. Using third-party design-entry software, the designer creates a netlist that forms the input to the Xilinx software. Utility software ( pin2xnf for FutureNet DASH and wir2xnf for Viewlogic, for example) translate the netlist into a Xilinx netlist format ( XNF ) file. In the next step the Xilinx program xnfmap takes the XNF netlist and maps the logic into the Xilinx Logic Cell Array ( LCA ) architecture. The output from the mapping step is a MAP file. The schematic MAP file may then be merged with other MAP files using xnfmerge . This technique is useful to merge different pieces of a design, some created using schematic entry and others created, for example, using logic synthesis. A translator program map2lca translates from the logic gates (NAND gates, NOR gates, and so on) to the required CLB configurations and produces an unrouted LCA file. The Xilinx place-and-route software ( apr or ppr ) takes the unrouted LCA file and performs the allocation of CLBs and completes the routing. The result is a routed LCA file. A control program xmake (that works like the make program in C) can automatically handle the mapping, merging, and place-and-route steps. Following the place-and-route step, the logic and wiring delays are known and the postlayout netlist may be generated. After a postlayout simulation the download file or BIT file used to program the FPGA (or a PROM that will load the FPGA) is generated using the Xilinx makebits program.
FIGURE 8.1 The Xilinx FPGA design flow. The numbers next to the steps in the flow correspond to those in the general ASIC design flow of Figure 1.10 .
Xilinx also provides a software program (Xilinx design editor, XDE) that permits manual control over the placement and routing of a Xilinx FPGA. The designer views a graphical representation of the FPGA, showing all the CLBs and interconnect, and can make or alter connections by pointing and clicking. This program is useful to check an automatically generated layout, or to explore critical routing paths, or to change and hand tune a critical connection, for example.
Xilinx uses a system called X-BLOX for creating regular structures such as vectored instances and datapaths. This system works with the Xilinx XNF netlist format. Other vendors, notably Actel and Altera, use a standard called Relationally Placed Modules ( RPM ), based on the EDIF standard, that ensures that the pieces of an 8-bit adder, for example, are treated as a macro and stay together during placement.
Actel FPGA design uses third-party design entry and simulators. After creating a netlist, a designer uses the Actel software for the place-and-route step. The Actel design software, like other FPGA and ASIC design systems, employs a large number of file formats with associated filename extensions. Table 8.1 shows some of the Actel file extensions and their meanings.
Actel software can also map hardware description files from other programmable logic design software into the Actel FPGA architecture. As an example, Table 8.2 shows a text description of a state machine using an HDL from a company called LOG/iC. You can then convert the LOG/iC code to the PALASM code shown in Table 8.2 . The Actel software can take the PALASM code and merge it with other PALASM files or netlists.
Altera uses a self-contained design system for its complex PLDs that performs design entry, simulation, and programming of the parts. Altera also provides an input and output interface to EDIF so that designers may use third-party schematic entry or a logic synthesizer. We have seen that the interconnect scheme in the Altera complex PLDs is nearly deterministic, simplifying the physical-design software as well as eliminating the need for back-annotation and a postlayout simulation. As Altera FPGAs become larger and more complex, there are some exceptions to this rule. Some special cases require signals to make more than one pass through the routing structures or travel large distances across the Altera FastTrack interconnect. It is possible to tell if this will be the case only by trying to place and route an Altera device.