Design Flow and Methodology

Introduction

Modern Field Programmable Gate Array (FPGA) and Complex Programmable Logic Device (CPLD) chips with ever increasing sizes and speeds allow designers to develop large, high-speed digital systems for a specific application very quickly. Modern design flows that allow the design of portions of the system in the most natural representation and support virtual prototyping 1 must be developed to manage complexity and exploit this increasing capacity. These design flows must utilize the capabilities of Hardware Description Languages, synthesis, and cosimulation to achieve these goals.

Hardware Description Languages (HDL) such as Verilog and VHDL have been developed that allow the description of the behavior and the structure of a digital system in a readable and simulatable form. Synthesis tools have been developed that can derive a gate-level hardware implementation of a digital systemfrom a behavioral description in an HDL. These synthesis tools typically operate at a fairly low level and are capable of synthesizing efficient Finite State Machine (FSM) implementations or blocks of combinational logic from behavioral HDL descriptions. Some synthesis tools have been developed that operate on more complex HDL descriptions and perform RTL (register transfer level) datapath design, and scheduling and assignment operations, but these tools generally perform best on dataflow intensive applications like Digital Signal Processing computations. For more control flow intensive systems such as microprocessors or microcontrollers, or applications that require the most efficient use of hardware resources and have critical timing requirements, the RTL level datapath must be designed by hand. The most efficient method for designing structure is the use of traditional schematic capture.

This document presents a design flow for developing Actel FPGAs using the Mentor Graphics and Actel tool sets. Behavioral HDL descriptions, logic level synthesis, schematic capture, and graphical HDL generation techniques are used where most appropriate to enable fast, efficient design of complex digital systems. Extensive simulation of virtual prototypes is performed at each stage in the design process to verify the design as each step is completed. Although the example presented herein uses VHDL as the HDL of choice, all of the tools used support Verilog and thus it could easily be used in this design flow.

The next section will present an overview of the design flow and the following section will illustrate the design flow in more detail using an example.

MGC/Actel Design Flow

The design flow described in this document consists of five major procedures as shown in Figure 1 , Functional Design, Synthesis, Place & Route, System Integration, and Fabrication. Although the design flow is drawn as a waterfall diagram, with flow only in a downward direction, it is in fact an iterative process in which the designer can return to or redo any step until the proper functionality is arrived at. Within each step, with the exception of the Fabrication process, there is a complete generate-simulate cycle in which the design components are developed and then simulated to ensure correct functionality before moving on to the next step. Each of these processes will be described in more detail in the following sections.

Functional Design

Functional design is the process of translating the initial system concept into an actual implementation that performs the required functions. In the case of the design flow described here, the initial concept must include how the design is to be partitioned across separate FPGAs if necessary, as the tools will not perform the partitioning function automatically (some FPGA tools will do this). Also note that the Actel family of FPGAs do not allow tri-state buses internal to the FPGA although tri-state pins are available at the individual FPGA boundaries. Therefore, the internal datapath of the design must be based on multiplexors, not busses.

Functional design begins with the development of a description of portions (building blocks) of the system in the most natural method possible for the component in question. For simple structures built from Actel primitives, such as multi-bit registers and multiplexors, the simplest description mechanism is schematic capture using Design Architect (DA) . For blocks of random logic such as decoders or ALUs, the simplest description is often a synthesizable VHDL model - usually generated by hand. For Finite State Machines (FSMs) such as are used for controllers, etc., the simplest description is also a synthesizable VHDL model, but automatic HDL generation tools such as Renoir can be used to generate the VHDL model from a natural graphical description. After the initial description of the building blocks are created, they should be simulated individually to ensure that they are functionally correct. This is done using the simulator appropriate for the model, Quicksim for schematics, or ModelSim for VHDL models. The flows for creation and simulation of the building blocks are shown in Figure 2 . Note that the Actel presimvpt tool must be used to prepare a unit delay simulation viewpoint for the schematics created with parts from the Actel library before it can be simulated with Quicksim .

Once the individual building blocks are designed and simulated, the next step is construction of the RTL level datapath using the building blocks previously created. Since the RTL level datapath is a structural interconnection of building blocks and possibly some additional parts from the Actel library, this step is most efficiently performed using schematic capture, again, with Design Architect . Before the building blocks can be instantiated in a Design Architect schematic, symbols must be created for them. This is easily done for both the schematic and VHDL building blocks using Design Architect . After the symbols are created, Design Architect can be used to create the overall structure of the design by interconnecting the building blocks in a schematic. Once this step is complete, the entire design should be functionally simulated again to ensure correct operation. Note simulations can be performed iteratively as the schematic is built up, which helps to isolate problems as they appear. For example, it may be helpful to simulate the datapath by itself without the controller first, using simulator force files to drive the control points to insure it operates correctly. Then the controller model can be added and the resulting design simulated. Finally, the I/O pads and any additional logic, such as reset generators or glue logic, can be added and the entire design (usually a complete FPGA) can be simulated.

In creating the symbols for the VHDL models, Design Architect will automatically add all of the properties necessary to use the Flexsim backplane to cosimulate them with Quicksim parts. Flexsim is the simulation backplane that connects the Quicksim and ModelSim simulators together and is invoked using the QSPro tool. There is caveat when using the QSPro tool to cosimulate Quicksim parts with VHDL models; the combination does not handle zero delay simulations very well. At a minimum, if you do not add delays to the control outputs of the FSM VHDL model, it will be very difficult to determine the order of events after a clock cycle. In the worst case, the simulation will not function correctly as the events in zero time do not seem to maintain proper order (a complete VHDL simulation would not have this problem as VHDL's delta delay mechanism was specifically designed to handle it). An easy solution is to add a few nanosecond delay to the assignment of the outputs in all VHDL models. This is easily done in the behavioral VHDL models that are written by hand or in the models generated by Renoir . During the synthesis process, these delays will be ignored, but they make the functional simulation process much easier. Figure 3 shows the design flow for functional design at the RTL level.

Synthesis

Synthesis is the process of mapping the VHDL behavioral models into logic gate implementations. In this design flow, synthesis is performed using the Leonardo Spectrum tool from Exemplar that is part of the Mentor Graphics tool set. Leonardo Spectrum is a synthesis tool which can target FPGA implementations. It accepts either VHDL or Verilog as its input and generates and output which consists netlist of library parts in the chosen technology, in this case the Actel ACT1 family. The output netlist format can be either EDIF (Electronic Design Interchange Format) VHDL, Verilog, or XNF (a netlist format specifically for Xilinx FPGA tools). For this design flow, the EDIF output format will be used as this is easily imported back into the Mentor Graphics environment.

One of the keys to the synthesis process, of course, is to write synthesizable VHDL models in the beginning, as part of the functional design process. Because VHDL is a high level language, it contains a number of complex constructs and allows modeling in various styles (such as recursion) which are meaningless in terms of an actual hardware implementation, and therefore are not synthesizable. Fortunately, the Renoir tool generates synthesizable code for state machines, so all that is necessary is to ensure that the behavioral descriptions that are written by hand for the random logic blocks are synthesizable. Most simple behavioral VHDL descriptions are in fact synthesizable, but there are a number of books and references on writing synthesizable VHDL including the HDL Synthesis Guide that describes the VHDL subset and coding style that the Leonardo Spectrum tool accepts. This reference should be consulted if any questions on the synthesizability of a VHDL model by Leonardo Spectrum arise.

Once the VHDL code is synthesized into a gate level implementation in terms of Actel library parts, it must be reimported into the Mentor Graphics environment for verification by simulation and for export to the Actel toolset. Actel provides a tool, called edn2mgc , that takes the EDIF netlist output by Leonardo Spectrum , and creates a design in the Mentor Graphics database format that is suitable for inclusion in a schematic within Design Architect , and for simulation with Quicksim . Since this is just a netlist format with no internal schematic, it is not possible to view the internal structure created by the synthesis tools, or to trace internal signals within the synthesized block during simulation. Normally, it is not necessary to do this, but it the designers wants to, he or she can use the Mentor Graphics schematic generator tool to generate an actual schematic for the synthesized block before incorporating it back into the overall design.

After the VHDL blocks are synthesized, new symbols for them must be generated (since they are schematics now, not VHDL models) and a new overall RTL level schematic must be created that has the synthesized blocks in place of the VHDL models. An easy way to do this is to save the old RTL level schematic that included the VHDL models, under a new name, and edit it to remove the VHDL blocks and replace them with their synthesized equivalent. Once this schematic is created, the entire design will be in terms of Actel library parts. It is wise at this point, to functionally simulate this design again to ensure that it is correct before the place and route function is performed. For this simulation, the presimvpt tool is used again to prepare the proper unit delay viewpoint, and the Quicksim simulator is used for simulation. Figure 4 shows the design flow for the synthesis step.

Place and Route

After the synthesis process is complete and the fully implemented design has been functionally simulated, the next step is to place and route the design onto an Actel FPGA. As previously stated, the designer must do the partitioning of the design across FPGAs as the Actel tools will not automatically perform this process. Therefore, the designs that are inputted into the place and route tool must represent a single FPGA portion of the overall design, if in fact, the design requires more than one FPGA. Also, Actel I/O pads must be placed on all of the inputs, outputs and bidirectional (tri-state) input/output signals to the design.

The place and route design flow, shown in Figure 5, begins with the generation of an EDIF netlist of the entire design to be placed and routed. This process is performed using the Actel mgc2edn tool. After the EDIF netlist is generated, the Actel Designer tool is used to perform the actual place and route functions. Designer imports the EDIF file, compiles it into an internal netlist format, does placement and routing, and then generates a timing file that can be imported back into the Mentor Graphics environment to allow full timing simulations on the resulting FPGA implementation to be done. Note that during the initial compilation process in Designer , the user must specify the type and size of Actel FPGA that the design is to be placed on. During the compilation process, Designer performs initial checks for correct design using the Actel parts (e.g. no I/O pads internal to the design, no fanout violations, etc.) and performs an initial check to ensure that the design will fit into the FPGA selected. Note however that successful completion of the compilation process does not guarantee that the Designer tool will be able to actually place and route the design into the FPGA chosen. Many variables such as the structure and regularity of the design, the number of internal signals, and the number of inputs and outputs in the design determine whether placement and routing will be successful. Utilizations as low as 60% of the available logic modules in an FPGA have been know to fail to be successfully placed and routed, while other designs have completed successfully at over 90% utilization.

After placement, routing, and timing extraction in the Designer tool are complete, the Actel del2mgc tool is used to import the timing information back into the Mentor Graphics environment. It is then a good idea to resimulate the chip level design using Quicksim with the -timing typical switch to ensure that the individual chip functions correctly at the selected clock speed with actual delays.

System Integration

The final process before actual construction of the physical design is that of system integration. System integration consists of constructing a complete schematic of the entire system which includes all FPGAs and other devices such as EPROMs, PLDs, RAMs, etc., and then performing a simulation of the system with all timing information. This is the highest level of virtual prototyping in that the model will be very close to the actual system in performance and successful simulation almost ensures correct operation of the physical prototype. The system integration flow, shown in Figure 6, starts with the use of Design Architect to generate symbols for the individual FPGA schematics after the placement and routing process is complete. Design Architect is then used to construct the schematic of the entire system. Models for other parts used in the system can be obtained from the Mentor Graphics parts libraries or others. After the system schematic is complete, the Mentor Graphics tool Design Viewpoint Editor (DVE) must be used to back annotate the timing information for the individual FPGAs into the overall system schematic. In the placement and routing flow, the Actel tool del2mgc was used to perform this process for the individual FPGA. The del2mgc tool actually uses DVE to perform back annotation, but for the complete system simulation, DVE must be used directly to back annotate the proper delay information for each separate FPGA into the overall system model. Quicksim is used for simulation with the -timing typical switch to use typical timing values for delay information. Note that the simulations at this stage should be as detailed as possible to uncover all design errors before the physical prototype is constructed. However, the amount of simulations performed may be limited by the amount of time required to actually execute them.

Fabrication

Once the entire system is simulated and the correct functionality is achieved, the actual construction of the physical prototype can begin. One last process that must be done using the Actel Designer tool is the generation of the fuse map for the individual FPGAs. When the fuse file is generated, it can be downloaded to the computer that runs the Actel programmer where the actual FPGA devices can be programmed. They are then placed in the prototype board that is already wirewrapped and tested, and system testing and debugging can be performed.

MGC/Actel Design Flow Example

In order to better illustrate the use of the design flow outlined here, its use on an actual system design will be presented in this section. The system designed was an 8 bit, unsigned multiplier. This system multiplies two unsigned 8 bit values, a multiplier and a multiplicand, and produces a 16 bit result. The multiplication is performed using the simple add/shift algorithm, the function of which can be found in any text on computer arithmetic. The RTL level datapath for the multiplier in block diagram form is shown in Figure 7 A. Figure 7 B shows the flow chart of the control unit FSM for the datapath.

For this design, schematic capture was used to construct the 8 bit register for M, the 8 bit shift registers for A and Q, and the overall RTL level datapath layout. The control unit FSM was coded in VHDL using Renoir and synthesized using Leonardo Spectrum , and the 8 bit adder was coded in VHDL by hand and synthesized using Leonardo Spectrum .

Functional Design

Functional design of the multiplier began with the generation of the schematics for the 8 bit register and 8 bit shift registers using Design Architect . In this design flow, Design Architect is invoked using the act_da command which simply starts DA and adds the Actel parts to the Libraries menu in the schematic mode. There are three families of parts in the Actel libraries, ACT1, ACT2, and ACT3, corresponding to the families of Actel FPGAs that the parts can be mapped onto. Within each family, the parts are further subdivided into hard and soft macros. Hard macros are primitive logic constructs that are mapped onto a single Logic Module in the Actel FPGA. Soft macros are constructs which implement higher levels of functionality and consist of schematic interconnections of hard macros. More information on the macros available in the ACT1 family, which will be used for this project, can be found in the Macro Library Guide document.

The 8 bit register was constructed using 8 single D flip-flops with enable and reset inputs. The 8 bit shift register was constructed using the same D flip-flops and 8 single bit 2-to-1 multiplexors. After the schematics were completed, symbols were created for them using Design Architect. The symbols can be created automatically by Design Architect, or generated by hand. In addition to the inputs and outputs for the schematic, a property called als_technology with a value of ACT1 must be placed on the symbol so that the simulator will know which parts library to use during simulation. In addition, it is a good idea to add the Mentor Graphics defined comp and inst properties to each symbol to make it easier to track down problems in simulation or netlist generation. The schematics and symbols for the 8 bit register and shift register are shown in Figure 8.

After the schematics and symbols are created, it is a good idea, even for something as simple as the 8 bit register, to functionally simulate the block using Quicksim . Recall that the presimvpt tool must be used on the blocks before the functional simulation can be performed. Figure 9 shows the functional simulation of the 8 bit shift register using Quicksim.

Next, after the register and shift register were created, the behavioral VHDL model for the 8 bit adder was written and tested. Although it would have been fairly easy to build the required functionality schematically using Actel parts, writing a VHDL behavioral model is even easier, both to initially create, and to modify later if problems arise. The VHDL behavioral model of the 8 bit adder and the symbol for QSPro generated by Design Architect is shown in Figure 10. The VHDL model uses the std_logic and std_logic_vector types throughout and uses the std_logic_unsigned package implementation of the "+" operation for std_logic_vectors . The std_logic_unsigned package is an IEEE standard package for VHDL and is supported by most major synthesis tools. Note that the two 8 bit inputs are padded out to 9 bits, as is the carry input, before the addition operation is performed. After the addition, the MSB of the result is stripped off and presented as the carry output. Also note that an arbitrary delay of 20 ns is added to all of the output values. This is done to avoid the zero delay problem in simulation describe earlier. This delay makes the overall simulation of the multiplier datapath easier to view and interpret, and the delay values are ignored by the synthesis tool.

After the model is written and compiled it is simulated using ModelSim to ensure correct functionality as shown in Figure 11.

The next step in the functional design processwas to construct a complete RTL level datapath using the blocks previously created and test it for correct overall functionality. This was done using DA to connect the symbols for the blocks in the proper configuration. The schematic for the multiplier datapath is shown in Figure 12 . Note that the control signals such as the M and Q register enables and shift modes are connected to named nets. This was done so that values could be easily forced on these signals by name in the simulation to emulate the functions of the control unit.

Figure 13 shows the functional simulation of the multiplier datapath. This simulation is performed using the QSPro tool that invokes the Flexsim backplane and the Quicksim and QuickHDL simulators. Note that both the Quicksim and Modelsim GUIs appear, but most of the required functionality of the simulator can be exercised through the Quicksim GUI alone. This includes tracing internal signals in the VHDL models such as the result signal shown. Also note that the presimvpt tool should be used on the datapath schematic to prepare the Actel portions for simulation.

The next step in the functional design process is to develop a VHDL behavioral model of the control unit. The control unit is an FSM that implements the flow diagram shown in Figure 7 B. The control unit for this multiplier was designed as a 5 state finite state machine. The states are idle, init, test, add, and shift. The control unit has 4 inputs; a clock, an asynchronous reset, a start signal, and the q0 control input. The control unit has 6 outputs; a mode and enable signal for the A (accumulator) shift register, a mode and enable signal for the Q (multiplier) register, an enable signal for the C (carry out) register, and an enable signal for the M (multiplicand) register. The idle state is the default, or reset, state for the control unit. In the idle state, all registers are disabled and the datapath is static. The init state is the state in which the initial values for the multiplicand and multiplier are loaded into the M and Q registers. The control unit transitions from the idle state to the init state when the start input is asserted. The test state is the state in which the value of the q0 input is tested to determine if an add/shift operation is to be performed, or just a shift operation. The control unit automatically transitions from init to test on the next clock cycle after the init state. The add state is the state in which M and A registers are added and input back into the A register. The A register is enabled in the register (non-shift) mode. The C register is also enabled in the add state. After the add state, the control unit automatically transitions to the shift state. In the shift state, the C, A, and Q registers are enabled in the shift mode and the product is left shifted one bit. The count value is also incremented by one in the shift state. The control unit then transitions back into the test state after the shift state. This cycle continues until the count value reaches 8.

The description of the control unit state machine is constructed using the Renoir tool as shown in Figure 14. Note that there is a default value specified for the outputs, an internal count signal is defined, and that an artificial delay value has been added to the output assignments. This delay value eliminates the zero delay simulation problems describe earlier. The VHDL behavioral description of the control unit is written automatically by Renoir and then compiled. A symbol for the control unit was generated using DA .

Complex FSMs should normally be functionally simulated by themselves to demonstrate at least some degree of correctness before they are added to the datapath. However, in this case, the control unit was simple enough that it was added to the datapath without first being functionally simulated. Design Architect was used to add the control unit to the datapath schematic as shown in Figure 15.

The full system consisting of the datapath and the control unit was functionally simulated using OSPro as before. Results of this simulation are shown in Figure 16. Note that the internal signals of the control unit state machine such as current_state, next_state, and count can be traced in the Quicksim window.

Synthesis

In this design flow, synthesis is the process of creating a gate level description of the blocks that are described behaviorally in VHDL and prepairing the complete design for the place and route process. The first step is to synthesize the VHDL behavioral descriptions into Actel parts using the Leonardo Spectrum tool. The output from Leonardo Spectrum is an EDIF netlist in Actel parts that performs the same function as the behavioral VHDL model. This EDIF netlist is then imported back into the Mentor Graphics environment using the Actel edn2mgc tool, a symbol for the synthesized part is generated using Design Architect , and optionally a schematic is generated using the Schematic Generator . The synthesized part it then placed in the RTL level schematic of the overall design in place of the VHDL behavioral model. Finally, I/O pads are added to the design and a final functional simulation is performed to ensure that the synthesized parts and the I/O pads were inserted correctly (and function correctly), and the design is ready for placement and routing.

Because the synthesis process will generate a new representation of the behavioral VHDL model, but will have the same name, it is a good idea to perform the synthesis, symbol generation, and schematic generation in another directory to avoid destroying the VHDL behavioral model representation. That way, if any problems arise in the synthesis process, it is possible to easily go back and modify the VHDL behavioral model, re-functionally simulate it, and re-synthesize it.

In the case of this design, a subdirectory called "actel" was created under the main design directory. The VHDL source code files were copied, into it, and the synthesis process was performed there.

Leonardo Spectrum is a fairly basic synthesis tool with a simple GUI that automates the synthesis process for the user. Another, more sophisticated synthesis tool, called Leonardo , is available that has more sophisticated synthesis and optimization algorithms which can lead to a smaller and faster gate level realization. However, Leonardo has a more complex GUI which requires more user interaction and knowledge about the synthesis process and thus is more complicated to use. It is possible to have the most of the benefits of both tools however, by running the Leonardo Spectrum synthesis GUI with the Leonardo synthesis engine. This is the methodology that was used in this design by invoking Leonardo Spectrum with the -product leonardo switch. After invoking the Leonardo Spectrum tool, synthesis consists of simply selecting the proper VHDL input file, either the 8 bit adder or the control unit description, selecting EDIF as the output file format, selecting the Actel Act1 output technology, turning off the "Add I/O Pads" synthesis switch under the Actel Act1Options dialog box, and pressing the Start Run button. Obviously, this is the simplest synthesis run that can be done, with only simple default area optimization, but more sophisticated optimizations for area and speed can be done if desired. More details on how to set these up are described in the Leonardo Spectrum documentation. A sample Leonardo Spectrum synthesis result is shown in Figure 17.

After the synthesis run is complete, the Actel edn2mgc tool is used to read in the EDIF file created by Leonardo Spectrum and create a Mentor Graphics database file that can be used for symbol generation, schematic generation (optional), simulation, and place and route. After the edn2mgc tool has competed, Design Architect is used to generate a symbol for the new synthesized part. Simply performing an open symbol operation on the database file that edn2mgc created (under the work directory) will cause Design Architect to automatically create the symbol with the proper input and output ports. At this time, the als_technology property with value ACT1 must be put on the symbol and it is recommended that comp and inst properties be added also. Optionally, the Schematic Generator can be used at this time to generate a schematic for the synthesized design. A schematic of a synthesized design can be very difficult to read, especially for large synthesized blocks, but it could be useful if the synthesized part does not perform correctly in functional simulation, to trace values on state bits in a synthesized FSM, for example. A compete description of generating schematics for parts synthesized to Actel libraries can be found in the Designer Series for Mentor Graphics document.

The final steps in the overall synthesis process consist of replacing the VHDL behavioral model blocks with their synthesized equivalent in the overall design schematic, adding Actel ACT1 I/O pads to the ports of the overall design, and functionally simulating the resulting complete FPGA design one final time before placement and routing is performed.

Figure 18 shows the schematic for the full design with the synthesized 8 bit adder and control unit replacing the VHDL behavioral model parts. Note also, that Actel I/O pads have been placed on all of the inputs and outputs of the design. For the 8 bit input busses for M and Q and the 16 bit output bus for product , the addition of numerous I/O pads in the overall schematic would have made it very difficult to read. Therefore, a new block (inbuf8) that includes 8 input pads was created for the M and Q busses and a new block (outbuf16) that includes 16 output pads was created for the product bus. In addition to the I/O buffers, additional internal buffers were added to the reset signal. This was necessary because the Actel ACT1 family of FPGAs allows a maximum of 24 module inputs to be driven by any module output (including an input pad buffer). Because the reset input fans out to all internal D flip flops in the M, A, Q, and C registers, it exceeded this maximum fanout number. The addition of the buffers eliminates these problems as each one only counts as one input to drive, but can itself drive an additional 24 module inputs. Also note that a special clock input buffer was placed on the clk input. This clock buffer drives the internal, balanced clock tree provided in the ACT1 family of FPGAs. The clock buffer does not have the restriction of only being able to drive a maximum of 14 inputs and is balanced through out the FPGA to minimize clock skew. The ACT1 family only provides one clock buffer per FPGA.

After the I/O pads and buffers were added to the design, it was functionally simulated a final time before the placement and routing was performed. This functional simulation can be done completely within Quicksim because all blocks are now described in Actel library parts. As before, presimvpt must be used on the complete schematic before simulating with Quicksim . Figure 19 shows the functional simulation of the complete design.

Placement and Routing

The placement and routing process begins with the Actel mgc2edn tool. This tool generates an EDIF netlist from the FPGA design schematic that is suitable for input to the Actel Designer placement and routing tool. After invoking Designer , the design EDIF file is imported and then the Compile, Layout, and Extract functions are executed. During the compile process, the user must input the type and package of the FPGA that the design will be mapped to. For this example, an Actel 1020B FPGA in an 84 pin PLCC package was specified. If there are fan out violations or any other problems with the input file to the Designer tool, they will be encountered in the compile process. The layout process actually performs the placement and routing functions. If there is a problem actually fitting the design into the type and size of FPGA selected, it will be encountered in the layout process. Like the synthesis tool, Designer has more sophisticated layout procedures that can be used to help fit a design into a given FPGA or generate a more optimal solution, but the basic placement and routing functions are usually sufficient. More detail on using Designer can be found in the Designer Series User's Guide .

Figure 20 shows an example Designer session on the multiplier FPGA. Note that this design utilized approximately 48% of the 547 logic modules available on the Actel 1020B 84 pin PLCC FPGA device. Also note that there were some fanout warnings where the fanout of some nets exceeded the recommended limit of 14. If speed was a significant issue for this design, it would have been a good idea to modify the schematic and add additional buffers to reduce the fanouts on those nets to less than 14.

Normally, the final step in the placement and routing process is to simulate the individual FPGA design with complete timing information. In order to do this, the Actel del2mgc tool must be run on the design. The del2mgc tool takes the timing information for the design extracted by Designer , and adds it to the Mentor Graphics simulation viewpoint for the design. Then, when the design is simulated using Quicksim with the -timing typical (or minimum , or maximum ) switch, the timing values are used in the simulation. This single FPGA timing simulation step is useful in determining the maximum clock rate at which the actual design will run and what the delays on the design's outputs are. However, this example consists of a single FPGA, so the timing simulation was actaully done in the next process, system integration and testing.

System Integration

The typical digital system being designed using FPGAs does not consist of a single FPGA, but rather contains multiple FPGAs, glue logic such as PDLs or TTL parts, and other components such as EPROMs and SRAMs. The system integration processinvolves developing a model of the entire system (a complete virtual prototype) and simulating it to ensure correct operation of the entire system.

The first step in the system integration process is that of generating symbols for the individual FPGA designs using Design Architect . As before, the als_technology property with the value of ACT1 must be added to the symbol and it is a good idea to add comp and inst properties to the symbol at the same time. Once the symbols for the FPGAs are created, the schematic of the entire system can be created using DA . Models for other parts such as PLDs, TTL components, EPROMS, and SRAMS are available in the MGC digital libraries within DA .

The schematic for the multiplier system is shown in Figure 21. For this example, the system design is somewhat contrived, but it consists of an EPROM which stores the values of the multiplier and multiplicand, and latches that hold the values on the M and Q inputs to the multiplier after they are read from the EPROM.

After the schematic for the system is created, the timing values for the individual FPGAs must be back annotated to it. The del2mgc program creates a viewpoint for the individual FPGA designs that includes this timing information, but the system level design does not automatically include it. The Mentor Graphics DVE tool must be used to back annotate the timing values for the FPGAs into the system level viewpoint for simulation. This is a simple process that is outlined in detail in the Designer Series for Mentor Graphics document.

Once the timing information is back annotated into the system level design, it is ready for simulation using Quicksim with the -timing typical switch. Simulation of the multiplier system board using Quicksim is shown in Figure 22.

Fabricate

Finally, after the system design is simulated correctly, the system can be fabricated. The only remaining step to be completed at this point in the CAD environment is generating the fuse maps for the FPGAs using Designer . Each FPGA design must be opened and the Fuse function executed. This generates an ASCII file named <design>.fus that can be downloaded to the Actel device programmer to actually burn the fuses in the Actel FPGAs. Then all that remains is to build and test the system board.Because of the extensive amount of simulation that has been performed during the design process, the actual fabrication can be approached with the knowledge that any bugs that occur will most likely (but not always!) be due to errors in construction such as wirewrapping or device problems.