PROGRAMMABLE ASIC DESIGN SOFTWARE

There are five components of a programmable ASIC or FPGA: (1) the programming technology, (2) the basic logic cell, (3) the I/O cell, (4) the interconnect, and (5) the design software that allows you to program the ASIC. The design software is much more closely tied to the FPGA architecture than is the case for other types of ASICs.

8.1 Design Systems

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 designentry 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 ) arrangementsimilar to buying a car with a stereo manufactured by an electronics company but labeled with the automobile companys 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 vendors 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 operationsignal 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 forwardannotation ) 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.

8.1.1 Xilinx
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-androute 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.

8.1.2 Actel
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. TABLE 8.1 File types used by Actel design software. ADL Main design netlist IPF Partial or complete pin assignment for the design CRT Net criticality VALIDATED Audit information COB List of macros removed from design VLD Information, warning, and error messages PIN Complete pin assignment for the design DFR Information about routability and I/O assignment quality Placement of non-I/O macros, pin swapping, and LOC freeway assignment PLI Feedback from placement step SEG Assignment of horizontal routing segments STF Back-annotation timing RTI Feedback from routing step FUS Fuse coordinates (column-track, row-track) DEL Delays for input pins, nets, and I/O modules Fuse programming times and currents for last chip AVI programmed 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. TABLE 8.2 FPGA state-machine language. LOG/iC state-machine language PALASM version *IDENTIFICATION TITLE sequence sequence detector detector LOG/iC code CHIP MEALY USER *X-NAMES CLK Z QQ2 QQ1 X X; !input EQUATIONS *Y-NAMES Z = X * QQ2 * QQ1 D; !output, D = 1 when three 1's QQ2 := X * QQ1 + X * appear on X QQ2

*FLOW-TABLE ;State, X input, Y output, next state S1, X1, Y0, F2; S1, X0, Y0, F1; S2, X1, Y0, F3; S2, X0, Y0, F1; S3, X1, Y0, F4; S3, X0, Y0, F1; S4, X1, Y1, F4; S4, X0, Y0, F1; *STATE-ASSIGNMENT BINARY; *RUN-CONTROL PROGFORMAT = P-EQUATIONS; *END

QQ1 := X * QQ2 + X * /QQ1

8.1.3 Altera
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.

8.2 Logic Synthesis

Designers are increasingly using logic synthesis as a replacement for schematic entry. As microelectronic systems and their ASICs become more complex, the use of schematics becomes less practical. For example, a complex ASIC that contains over 10,000 gates might require hundreds of pages of schematics at the gate level. As another example, it is easier to write A = B + C than to draw a schematic for a 32-bit adder at the gate level.

The term logic synthesis is used to cover a broad range of software and software capabilities. Many logic synthesizers are based on logic minimization. Logic minimization is usually performed in one of two ways, either using a set of rules or using algorithms. Early logic-minimization software was designed using algorithms for two-level logic minimization and developed into multilevel logic-optimization software. Two-level and multilevel logic minimization is well suited to random logic that is to be implemented using a CBIC, MGA, or PLD. In these technologies, two-level logic can be implemented very efficiently. Logic minimization for FPGAs, including complex PLDs, is more difficult than other types of ASICs, because of the complex basic logic cells in FPGAs. There are two ways to use logic synthesis in the design of FPGAs. The first and simplest method takes a hardware description, optimizes the logic, and then produces a netlist. The netlist is then passed to software that maps the netlist to an FPGA architecture. The disadvantage of this method is the inefficiency of decoupling the logic optimization from the mapping step. The second, more complicated, but more efficient method, takes the hardware description and directly optimizes the logic for a specific FPGA architecture. Some logic synthesizers produce files in PALASM, ABEL, or CUPL formats. Software provided by the FPGA vendor then take these files and maps the logic to the FPGA architecture. The FPGA mapping software requires detailed knowledge of the FPGA architecture. This makes it difficult for third-party companies to create logic synthesis software that can map directly to the FPGA. A problem with design-entry systems is the difficulty of moving netlists between different FPGA vendors. Once you have completed a design using an FPGA cell library, for example, you are committed to using that type of FPGA unless you repeat design entry using a different cell library. ASIC designers do not like this approach since it exposes them to the mercy of a single ASIC vendor. Logic synthesizers offer a degree of independence from FPGA vendors (universally referred to vendor independence, but this should, perhaps, be designer independence) by delaying the point in the design cycle at which designers need to make a decision on which FPGA to use. Of course, now designers become dependent on the synthesis software company.

8.2.1 FPGA Synthesis

For low-level logic synthesis, PALASM is a de facto standard as the lowestcommon-denominator interchange format. Most FPGA design systems are

capable of converting their own native formats into a PALASM file. The most common programmable logic design systems are ABEL from Data I/O, CUPL from P-CAD, LOG/iC from IsData, PALASM2 from AMD, and PGA-Designer from Minc. At a higher level, CAD companies (Cadence, Compass, Mentor, and Synopsys are examples) support most FPGA cell libraries. This allows you to map from a VHDL or Verilog description to an EDIF netlist that is compatible with FPGA design software. Sometimes you have to buy the cell library from the software company, sometimes from the FPGA vendor. TABLE 8.3 The VHDL code for the sequence detector of Table 8.2 . entity detector is port (X, CLK: in BIT; Z : out BIT); end; architecture behave of SEQDET is type STATES is (S1, S2, S3, S4); signal current, next: STATES; begin combinational: process begin case current is when S1 => if X = '1' then Z <= '0'; next <= S3; else Z <= '0'; next <= S1; end if; when S2 => if X = '1' then Z <= '0'; next <= S2; else Z <= '0'; next <= S1; end if; when S3 => if X = '1' then Z <= '0'; next <= S2; else Z <= '0'; next <= S1; end if; when S4 => if X = '1' then Z <= '1'; next <= S4; else Z <= '0'; next <= S1; end if end case; end process sequential: process begin wait until CLK'event and CLK = '1'; current <= next ; end process; end behave; As an example, Table 8.3 shows a VHDL model for a pattern detector to check for a sequence of three '1's (excluding the code for the I/O pads). Table 8.4 shows a script or command file that runs the Synopsys software to

generate an EDIF netlist from this VHDL that targets the TI version of the Actel FPGA parts. A script is a recipe that tells the software what to do. If we wanted to retarget this design to another type of FPGA or an MGA or CBIC ASIC, for example, we may only need a new set of cell libraries and to change the script (if we are lucky). In practice, we shall probably find we need to make a few changes in the VHDL code (in the areas of I/O pads, for example, that are different for each kind of ASIC). We now have a portable design and a measure of vendor independence. We have also introduced some dependence on the Synopsys software since the code in Table 8.3 might be portable, but the script (which is just as important a part of the design) in Table 8.4 may only be used with the Synopsys software. Nevertheless, using logic synthesis results in a more portable design than using schematic entry. TABLE 8.4 The Synopsys script for the VHDL code of Table 8.3 . /design checking/ search_path = . /use the TI cell report_design > libraries/ detector.rpt link_library = tpc10.db /optimize for area/ target_library = max_area 0.0 tpc10.db compile symbol_library = write -h -f db -o tpc10.sdb detector_opt.db read -f vhdl report -area -cell detector.vhd timing > detector.rpt current_design = free -all detector /write EDIF netlist/ write -n -f db write -h -f edif -0 hierarchy -0 detector.db exit check_design > detector.rpt

8.3 The Halfgate ASIC

This section illustrates FPGA design using a very simple ASICa single inverter. The hidden details of the design and construction of this halfgate FPGA are quite complicated. Fortunately, most of the inner workings of the design software are normally hidden from the designer. However, when software breaks, as it sometimes does, it is important to know how things

work in order to fix the problem. The formats, filenames, and flow will change, but the information needed at each stage and the order in which it is conveyed will stay much the same.

8.3.1 Xilinx
Table 8.5 shows an FPGA design flow using Compass and Xilinx software. On the left of Table 8.5 is a script for the Compass programsscripts for Cadence, Mentor, and Synopsys software are similar, but not all design software has the capability to be run on autopilot using scripts and a command language. The diagrams in Table 8.5 illustrate what is happening at each of the design steps. The following numbered comments, corresponding to the labels in Table 8.5 , highlight the important steps: TABLE 8.5 Design flow for the Xilinx implementation of the halfgate ASIC. Script Design flow # halfgate.xilin x.inp shell setdef path working xc4000d xblox cmosch000x quit asic open [v]halfgate synthesize save [nls]halfgate_ p quit fpga set tag xc4000 set opt area optimize [nls]halfgate_ p quit qtv open

[nls]halfgate_ p trace critical print trace [txt]halfgate_ p quit shell vuterm exec xnfmerge -p 4003PC84 halfgate_p > /dev/null exec xnfprep halfgate_p > /dev/null exec ppr halfgate_p > /dev/null exec makebits -w halfgate_p > /dev/null exec lca2xnf g -v halfgate_p halfgate_b > /dev/null quit manager notice utility netlist open [xnf]halfgate_ b save [nls]halfgate_ b save [edf]halfgate_ b quit qtv open

[nls]halfgate_ b trace critical print trace [txt]halfgate_ b quit

TABLE 8.6 The Xilinx files for the halfgate ASIC. Verilog file (halfgate.v) Preroute XNF file (halfgate_p.xnf)

LCA file (halfgate_p.lca)

Postroute XNF file (halfgate_b.xnf)

1.

The Verilog code, in halfgate.v , describes a single inverter.

2. The script runs the logic synthesizer that converts the Verilog description to an inverter (using elements from the Xilinx XC4000

library) and saves the result in a netlist, halfgate_p.nls (a Compass internal format). 3. The script next runs the logic optimizer for FPGAs. This program also adds the I/O pads. In this case, logic optimization implements the inverter by using an inverting output pad. The software writes out the netlist as halfgate_p.xnf . 4. A timing simulation is run on the netlist halfgate_p.nls (the Compass format netlist). This netlist uses the default delays every gate has a delay of 1 ns. 5. At this point the script has run all of the Xilinx programs required to complete the place-and-route step. The Xilinx programs have created several files, the most important of which is halfgate_p.lca , which describes the FPGA layout. This postroute netlist is converted to halfgate_b.nls (the added suffix 'b' stands for back-annotation). Next a timing simulation is performed on the postroute netlist, which now includes delays, to find the delay from the input ( myInput ) to the output ( myOutput ). This is the criticaland onlypath. The simulation (not shown) reveals that the delay is 2.8 ns (for the input buffer) plus 11.6 ns (for the output buffer), for a total delay of 14.4 ns (this is for a XC4003 in a PC84 package, and default speed grade '4'). Table 8.6 shows the key Xilinx files that are created. The preroute file, halfgate_p.xnf , describes the IBUF and OBUF library cells but does not contain any delays. The LCA file, halfgate_p.lca , contains all the physical design information, including the locations of the pads and I/O cells on the FPGA ( PAD61 for myInput and PAD1 for myOutput ), as well as the details of the programmable connections between these I/O Cells. The postroute file, halfgate_b.xnf , is similar to the preroute version except that now the delays are included. Xilinx assigns delays to a pin (connector or terminal of a cell). In this case 2.8 ns is assigned to the output of the input buffer, 8.6 ns is assigned to the input of the output buffer, and finally 3.0 ns is assigned to the output of the output buffer.

8.3.2 Actel
The key Actel files for the halfgate design are the netlist file, halfgate_io.adl, and the STF delay file for back-annotation, halfgate_io.stf. Both of these files are shown in Table 8.7 (the STF file is large and only the last few lines, which contain the delay information, are shown in the table). TABLE 8.7 The Actel files for the halfgate ASIC.

ADL file ; HEADER ; FILEID ADL ./halfgate_io.adl 85e8053b ; CHECKSUM 85e8053b ; PROGRAM certify ; VERSION 23/1 ; ALSMAJORREV 2 ; ALSMINORREV 3 ; ALSPATCHREV .1 ; NODEID 72705192 ; VAR FAMILY 1400 ; ENDHEADER DEF halfgate_io; myInput, myOutput. USE ADLIB:INBUF; INBUF_2. USE ADLIB:OUTBUF; OUTBUF_3. USE ADLIB:INV; u2. NET DEF_NET_8; u2:A, INBUF_2:Y. NET DEF_NET_9; myInput, INBUF_2:PAD. NET DEF_NET_11; OUTBUF_3:D, u2:Y. NET DEF_NET_12; myOutput, OUTBUF_3:PAD. END.

STF file ; HEADER ; FILEID STF ./halfgate_io.stf c96ef4d8 ... lines omitted ... (126 lines total) DEF halfgate_io. USE ; INBUF_2/U0; TPADH:'11:26:37', TPADL:'13:30:41', TPADE:'12:29:41', TPADD:'20:48:70', TYH:'8:20:27', TYL:'12:28:39'. PIN u2:A; RDEL:'13:31:42', FDEL:'11:26:37'. USE ; OUTBUF_3/U0; TPADH:'11:26:37', TPADL:'13:30:41', TPADE:'12:29:41', TPADD:'20:48:70', TYH:'8:20:27', TYL:'12:28:39'. PIN OUTBUF_3/U0:D; RDEL:'14:32:45', FDEL:'11:26:37'. END.

8.3.3 Altera
Because Altera complex PLDs use a deterministic routing structure, they can be designed more easily using a self-contained software packagean all-in-one software package using a single interface. We shall assume that we can generate a netlist that the Altera software can accept using Cadence, Mentor, or Compass software with an Altera design kit (the most convenient format is EDIF). Table 8.8 shows the EDIF preroute netlist in a format that the Altera software can accept. This netlist file describes a single inverter (the line

'cellRef not'). The majority of the EDIF code in Table 8.8 is a standard template to pass information about how the VDD and VSS nodes are named, which libraries are used, the name of the design, and so on. We shall cover EDIF in Chapter 9 . TABLE 8.8 EDIF netlist in Altera format for the halfgate ASIC.

Table 8.9 shows a small part of the reports generated by the Altera software after completion of the place-and-route step. This report tells us how the software has used the basic logic cells, interconnect, and I/O cells to implement our design. With practice it is possible to read the information from reports such as Table 8.9 directly, but it is a little easier if we also look at the netlist. The EDIF version of postroute netlist for this example is large. Fortunately, the Altera software can also generate a Verilog version of the postroute netlist. Here is the generated Verilog postroute netlist, halfgate_p.vo (not '.v' ), for the halfgate design: TABLE 8.9 Report for the halfgate ASIC fitted to an Altera MAX 7000 complex PLD. ** INPUTS ** Shareable Expanders Fan-In Fan-Out Pin LC LAB Primitive Code Total Shared n/a INP FBK OUT FBK Name 43 - - INPUT 0 0 0 0 0 0 1 myInput ** OUTPUTS ** Shareable Expanders Fan-In Fan-Out

Pin LC LAB Primitive Code Total Shared n/a INP FBK OUT FBK Name 41 17 B OUTPUT t 0 0 0 1 0 0 0 myOutput ** LOGIC CELL INTERCONNECTIONS ** Logic Array Block 'B': +- LC17 myOutput | LC | | A B | Name Pin 43 -> * | - * | myInput * = The logic cell or pin is an input to the logic cell (or LAB) through the PIA. - = The logic cell or pin is not an input to the logic cell (or LAB). // halfgate_p (EPM7032LC44) MAX+plus II Version 5.1 RC6 10/03/94 // Wed Jul 17 04:07:10 1996 `timescale 100 ps / 100 ps module TRI_halfgate_p( IN, OE, OUT ); input IN; input OE; output OUT; bufif1 ( OUT, IN, OE ); specify specparam TTRI = 40; specparam TTXZ = 60; specparam TTZX = 60; (IN => OUT) = (TTRI,TTRI); (OE => OUT) = (0,0, TTXZ, TTZX, TTXZ, TTZX); endspecify endmodule module halfgate_p (myInput, myOutput); input myInput; output myOutput; supply0 gnd; supply1 vcc; wire B1_i1, myInput, myOutput, N_8, N_10, N_11, N_12, N_14; TRI_halfgate_p tri_2 ( .OUT(myOutput), .IN(N_8), .OE(vcc) ); TRANSPORT transport_3 ( N_8, N_8_A ); defparam transport_3.DELAY = 10;

and delay_3 ( N_8_A, B1_i1 ); xor xor2_4 ( B1_i1, N_10, N_14 ); or or1_5 ( N_10, N_11 ); TRANSPORT transport_6 ( N_11, N_11_A ); defparam transport_6.DELAY = 60; and and1_6 ( N_11_A, N_12 ); TRANSPORT transport_7 ( N_12, N_12_A ); defparam transport_7.DELAY = 40; not not_7 ( N_12_A, myInput ); TRANSPORT transport_8 ( N_14, N_14_A ); defparam transport_8.DELAY = 60; and and1_8 ( N_14_A, gnd ); endmodule The Verilog model for our ASIC, halfgate_p , is written in terms of other models: and , xor , or , not , TRI_halfgate_p , TRANSPORT . The first four of these are primitive models for basic logic cells and are built into the Verilog simulator. The model for TRI_halfgate_p is generated together with the rest of the code. We also need the following model for TRANSPORT, which contains the delay information for the Altera MAX complex PLD. This code is part of a file ( alt_max2.vo ) that is generated automatically. // MAX+plus II Version 5.1 RC6 10/03/94 Wed Jul 17 04:07:10 1996 `timescale 100 ps / 100 ps module TRANSPORT( OUT, IN ); input IN; output OUT; reg OUTR; wire OUT = OUTR; parameter DELAY = 0; `ifdef ZeroDelaySim always @IN OUTR <= IN; `else always @IN OUTR <= #DELAY IN; `endif `ifdef Silos initial #0 OUTR = IN; `endif endmodule The Altera software can also write the following VHDL postroute netlist: -- halfgate_p (EPM7032LC44) MAX+plus II Version 5.1 RC6 10/03/94

-- Wed Jul 17 04:07:10 1996 LIBRARY IEEE; USE IEEE.std_logic_1164.all; ENTITY n_tri_halfgate_p IS GENERIC (ttri: TIME := 1 ns; ttxz: TIME := 1 ns; ttzx: TIME := 1 ns); PORT (in0 : IN X01Z; oe : IN X01Z; out0: OUT X01Z); END n_tri_halfgate_p; ARCHITECTURE behavior OF BEGIN PROCESS (in0, oe) BEGIN IF oe'EVENT THEN IF oe = '0' THEN out0 <= ELSIF oe = '1' THEN out0 ttzx; END IF; ELSIF oe = '1' THEN out0 ttri; END IF; END PROCESS; END behavior; n_tri_halfgate_p IS

TRANSPORT 'Z' AFTER ttxz; <= TRANSPORT in0 AFTER <= TRANSPORT in0 AFTER

LIBRARY IEEE; USE IEEE.std_logic_1164.all; USE work.n_tri_halfgate_p; ENTITY n_halfgate_p IS PORT ( myInput : IN X01Z; myOutput : OUT X01Z); END n_halfgate_p; ARCHITECTURE EPM7032LC44 OF n_halfgate_p IS SIGNAL gnd : X01Z := '0'; SIGNAL vcc : X01Z := '1'; SIGNAL n_8, B1_i1, n_10, n_11, n_12, n_14 : X01Z; COMPONENT n_tri_halfgate_p GENERIC (ttri, ttxz, ttzx: TIME); PORT (in0, oe : IN X01Z; out0 : OUT X01Z); END COMPONENT; BEGIN PROCESS(myInput) BEGIN ASSERT myInput /= 'X' OR Now = 0 ns REPORT "Unknown value on myInput" SEVERITY Warning; END PROCESS; n_tri_2: n_tri_halfgate_p GENERIC MAP (ttri => 4 ns, ttxz => 6 ns, ttzx => 6 ns)

PORT MAP (in0 => n_8, oe => vcc, out0 => myOutput); n_delay_3: n_8 <= TRANSPORT B1_i1 AFTER 1 ns; n_xor_4: B1_i1 <= n_10 XOR n_14; n_or_5: n_10 <= n_11; n_and_6: n_11 <= TRANSPORT n_12 AFTER 6 ns; n_not_7: n_12 <= TRANSPORT NOT myInput AFTER 4 ns; n_and_8: n_14 <= TRANSPORT gnd AFTER 6 ns; END EPM7032LC44; LIBRARY IEEE; USE IEEE.std_logic_1164.all; USE work.n_halfgate_p; ENTITY halfgate_p IS PORT ( myInput : IN std_logic; myOutput : OUT std_logic); END halfgate_p; ARCHITECTURE EPM7032LC44 OF halfgate_p IS COMPONENT n_halfgate_p PORT (myInput : IN X01Z; myOutput : OUT X01Z); END COMPONENT; BEGIN n_0: n_halfgate_p PORT MAP ( myInput => TO_X01Z(myInput), myOutput => myOutput); END EPM7032LC44; The VHDL is a little harder to decipher than the Verilog, so the schematic for the VHDL postroute netlist is shown in Figure 8.2 . This VHDL netlist is identical in function to the Verilog netlist, but the net names and component names are different. Compare Figure 8.2 with Figure 5.15 (c) in Section 5.4 , Altera MAX , which shows the Altera basic logic cell and Figure 6.23 in Section 6.8, Other I/O Cells, which describes the Altera I/O cell. The software has fixed the inputs to the various elements in the Altera MAX device to implement a single inverter.

FIGURE 8.2 The VHDL version of the postroute Altera MAX 7000 schematic for the halfgate ASIC. Compare this with Figure 5.15(c) and Figure 6.23.

8.3.4 Comparison
The halfgate ASIC design illustrates the differences between a nondeterministic coarse-grained FPGA (Xilinx XC4000), a nondeterministic fine-grained FPGA (Actel ACT 3), and a deterministic complex PLD (Altera MAX 7000). These differences, summarized as follows, were apparent even in the halfgate design: 1. The Xilinx LCA architecture does not permit an accurate timing analysis until after place and route. This is because of the coarsegrained nondeterministic architecture. 2. The Actel ACT architecture is nondeterministic, but the finegrained structure allows fairly accurate preroute timing prediction. 3. The Altera MAX complex PLD requires logic to be fitted to the product steering and programmable array logic. The Altera MAX 7000 has an almost deterministic architecture, which allows accurate preroute timing.

8.4 Summary
The important concepts covered in this chapter are:

FPGA design flow: design entry, simulation, physical design, and programming Schematic entry, hardware design languages, logic synthesis

PALASM as a common low-level hardware description EDIF, Verilog, and VHDL as vendor-independent netlist standards