ch08.1.htm
来自「介绍asci设计的一本书」· HTM 代码 · 共 654 行 · 第 1/2 页
HTM
654 行
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML EXPERIMENTAL 970324//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="Adobe FrameMaker 5.5/HTML Export Filter">
<TITLE> 8.1 Design Systems</TITLE></HEAD><!--#include file="top.html"--><!--#include file="header.html"-->
<DIV>
<P>[ <A HREF="CH08.htm">Chapter start</A> ] [ <A HREF="CH08.htm">Previous page</A> ] [ <A HREF="CH08.2.htm">Next page</A> ]</P><!--#include file="AmazonAsic.html"--><HR></DIV>
<H1 CLASS="Heading1">
<A NAME="pgfId=76708">
</A>
8.1 <A NAME="24089">
</A>
Design Systems</H1>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=76710">
</A>
The sequence of steps for FPGA design is similar to the sequence discussed in <A HREF="/Humuhumu/from Antibes/Prof.htm#38757" CLASS="XRef">
Section 1.2</A>
, “<A HREF="/Humuhumu/from Antibes/Prof.htm#38757" CLASS="XRef">
Design Flow</A>
.” As for any ASIC a designer needs design-entry software, a cell library, and physical-design software. Each of the FPGA vendors sells <A NAME="marker=76709">
</A>
<SPAN CLASS="Definition">
design kits</SPAN>
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 <SPAN CLASS="Definition">
original equipment manufacturer</SPAN>
<A NAME="marker=76711">
</A>
(<SPAN CLASS="Definition">
OEM</SPAN>
<A NAME="marker=76712">
</A>
<A NAME="marker=76713">
</A>
) 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. </P>
<P CLASS="Body">
<A NAME="pgfId=76650">
</A>
Unfortunately, there are no standards in FPGA design. Thus, for example, Xilinx calls its 2:1 MUX an <SPAN CLASS="BodyComputer">
M2_1</SPAN>
with inputs labeled <SPAN CLASS="BodyComputer">
D0</SPAN>
, <SPAN CLASS="BodyComputer">
D1</SPAN>
, and <SPAN CLASS="BodyComputer">
S0</SPAN>
with output <SPAN CLASS="BodyComputer">
O</SPAN>
. Actel calls a 2:1 MUX an <SPAN CLASS="BodyComputer">
MX2</SPAN>
with inputs <SPAN CLASS="BodyComputer">
A</SPAN>
, <SPAN CLASS="BodyComputer">
B</SPAN>
, and <SPAN CLASS="BodyComputer">
S</SPAN>
with output <SPAN CLASS="BodyComputer">
Y</SPAN>
. 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! </P>
<P CLASS="Body">
<A NAME="pgfId=76651">
</A>
One solution to the lack of standards for cell libraries is to use a <A NAME="marker=76652">
</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. </P>
<P CLASS="Body">
<A NAME="pgfId=76653">
</A>
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 <A NAME="marker=76654">
</A>
hardware description languages (<A NAME="marker=76655">
</A>
HDL<A NAME="marker=76656">
</A>
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 <A NAME="marker=76657">
</A>
ABEL (pronounced “able”), <A NAME="marker=76658">
</A>
CUPL (“cupple”), and <A NAME="marker=76659">
</A>
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 <A NAME="marker=84306">
</A>
VHDL and <A NAME="marker=84307">
</A>
Verilog, which are higher-level and are more complex but are capable of describing complete ASICs and systems. </P>
<P CLASS="Body">
<A NAME="pgfId=76660">
</A>
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 <A NAME="marker=77103">
</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 <A NAME="marker=76661">
</A>
back-annotate the <A NAME="marker=76662">
</A>
postlayout timing information to the <A NAME="marker=84400">
</A>
postlayout netlist (also called a <A NAME="marker=84401">
</A>
back-annotated netlist). This is followed by a <A NAME="marker=84402">
</A>
postlayout timing simulation. </P>
<P CLASS="Body">
<A NAME="pgfId=76663">
</A>
The second type of simulator, the type most often used in FPGA design, is a <A NAME="marker=76664">
</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 <A NAME="marker=76665">
</A>
timing constraint; if the actual delay is longer, this is a <A NAME="marker=76666">
</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 <A NAME="marker=76669">
</A>
<SPAN CLASS="Definition">
forward-annotation</SPAN>
) to direct the place-and-route software.</P>
<P CLASS="Body">
<A NAME="pgfId=76670">
</A>
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.</P>
<DIV>
<H2 CLASS="Heading2">
<A NAME="pgfId=72530">
</A>
8.1.1 Xilinx</H2>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=3602">
</A>
<A HREF="CH08.1.htm#19692" CLASS="XRef">
Figure 8.1</A>
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 (<SPAN CLASS="BodyComputer">
pin2xnf</SPAN>
for FutureNet DASH and <SPAN CLASS="BodyComputer">
wir2xnf</SPAN>
for Viewlogic, for example) translate the netlist into a <SPAN CLASS="Definition">
Xilinx netlist format</SPAN>
<A NAME="marker=77699">
</A>
(<A NAME="marker=77695">
</A>
<SPAN CLASS="Definition">
XNF</SPAN>
) file. In the next step the Xilinx program <SPAN CLASS="BodyComputer">
xnfmap</SPAN>
takes the XNF netlist and <SPAN CLASS="Definition">
maps</SPAN>
<A NAME="marker=84430">
</A>
the logic into the Xilinx <SPAN CLASS="Definition">
Logic Cell Array </SPAN>
<A NAME="marker=77703">
</A>
(<A NAME="marker=77704">
</A>
<SPAN CLASS="Definition">
LCA</SPAN>
<A NAME="marker=77705">
</A>
) architecture. The output from the mapping step is a <A NAME="marker=25315">
</A>
MAP file. The schematic MAP file may then be <A NAME="marker=91151">
</A>
<SPAN CLASS="Definition">
merged</SPAN>
with other MAP files using <SPAN CLASS="BodyComputer">
xnfmerge</SPAN>
. 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 <SPAN CLASS="BodyComputer">
map2lca</SPAN>
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 (<SPAN CLASS="BodyComputer">
apr</SPAN>
or <SPAN CLASS="BodyComputer">
ppr</SPAN>
) 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 <SPAN CLASS="BodyComputer">
xmake</SPAN>
(that works like the <SPAN CLASS="BodyComputer">
make</SPAN>
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 <A NAME="marker=3642">
</A>
<SPAN CLASS="Definition">
download file</SPAN>
or <A NAME="marker=3645">
</A>
BIT file used to program the FPGA (or a PROM that will load the FPGA) is generated using the Xilinx <SPAN CLASS="BodyComputer">
makebits</SPAN>
<A NAME="marker=3647">
</A>
program.</P>
<TABLE>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableFigure">
<A NAME="pgfId=8458">
</A>
<IMG SRC="CH08-1.gif" ALIGN="BASELINE">
</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableFigureTitle">
<A NAME="pgfId=8460">
</A>
FIGURE 8.1 <A NAME="19692">
</A>
The Xilinx FPGA design flow. The numbers next to the steps in the flow correspond to those in the general ASIC design flow of <A HREF="/Humuhumu/from Antibes/Prof.htm#39342" CLASS="XRef">
Figure 1.10</A>
.</P>
</TD>
</TR>
</TABLE>
<P CLASS="Body">
<A NAME="pgfId=25610">
</A>
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.</P>
<P CLASS="Body">
<A NAME="pgfId=3666">
</A>
Xilinx uses a system called <A NAME="marker=3664">
</A>
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 <A NAME="marker=20649">
</A>
<A NAME="marker=20650">
</A>
Relationally Placed Modules (<A NAME="marker=20645">
</A>
RPM<A NAME="marker=20651">
</A>
), 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.</P>
</DIV>
<DIV>
<H2 CLASS="Heading2">
<A NAME="pgfId=71501">
</A>
8.1.2 Actel</H2>
<P CLASS="BodyAfterHead">
<A NAME="pgfId=71505">
</A>
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. <A HREF="CH08.1.htm#37446" CLASS="XRef">
Table 8.1</A>
shows some of the Actel file extensions and their meanings. </P>
<TABLE>
<TR>
<TD ROWSPAN="1" COLSPAN="2">
<P CLASS="TableTitle">
<A NAME="pgfId=71522">
</A>
TABLE 8.1 <A NAME="37446">
</A>
File types used by Actel design software.</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableLeft">
<A NAME="pgfId=71526">
</A>
ADL</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableLeft">
<A NAME="pgfId=71528">
</A>
Main design netlist</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableLeft">
<A NAME="pgfId=71530">
</A>
IPF</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableLeft">
<A NAME="pgfId=71532">
</A>
Partial or complete pin assignment for the design</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableLeft">
<A NAME="pgfId=71534">
</A>
CRT</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableLeft">
<A NAME="pgfId=71536">
</A>
Net criticality</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableLeft">
<A NAME="pgfId=71538">
</A>
VALIDATED</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableLeft">
<A NAME="pgfId=71540">
</A>
Audit information</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableLeft">
<A NAME="pgfId=71542">
</A>
COB</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableLeft">
<A NAME="pgfId=71544">
</A>
List of macros removed from design</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="TableLeft">
<A NAME="pgfId=71546">
</A>
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?