Working with FPGAs isn't intimidating when you know the basic techniques and options.
Over the last several years, the use of FPGAs has greatly increased in military and commercial products. They can be found in primary and secondary surveillance radar, satellite communication, automotive, manufacturing, and many other types of products. While the FPGA development process is second nature to embedded systems designers experienced in implementing digital designs on an FPGA, it can be confusing and difficult for the rest of us. Good communication is important when technical leads, supervisors, managers, or systems engineers interface with FPGA designers.
The key to good communication is having an understanding of the development process. A solid understanding will help you comprehend and extract relevant information for status reports, define schedule tasks, and allocate appropriate resources and time. There have been many times when my FPGA knowledge has allowed me to detect and correct errors, such as wrong part numbers or misuse of terms and terminology found in requirements and other documents.
Regardless of your final product, FPGA designers must follow the same basic process. The FPGA development stages are design, simulation, synthesis, and implementation, as shown in Figure 1 . The design process involves converting the requirements into a format that represents the desired digital function(s). Common design formats are schematic capture, hardware description language (HDL), or a combination of the two. While each method has its advantages and disadvantages, HDLs generally offer the greatest design flexibility.
Schematic capture, the graphical depiction of a digital design, shows the actual interconnection between each logic gate that produces the desired output function(s). Many of these logic-gate symbols involve proprietary information making them available to the designer only through the specific vendor's component library. Schematic capture designs that mainly consist of proprietary symbols make the design unrecognizable by competitors' FPGA development tools. The proprietary nature of this type of design makes it vendor dependent, and the entire design process must be repeated if a different vendor is used.
Examples of schematic capture tools are Viewlogic's ViewDraw and HDL's EASE. The main advantage of schematic capture is that the graphical representation is easy to understand. However, its major drawback is an increase in cost and time to reproduce a design for different vendors due to the design's proprietary nature.
Hardware description languages (HDLs) use code to represent digital functions. “Firmware” often refers to the resulting HDL code. HDLs are a common and popular approach to FPGA design. You can create the source code with any text editor. Special HDL editors like CodeWright and Scriptum (a free HDL text editor by HDL Works) offers features such as HDL templates and highlighting reserved words not found in ordinary text editors. HDLs can be generic (supported by multiple simulation and synthesis tool sets) like Verilog or VHDL (Very High Speed IC HDL), or vendor-specific like Altera's Hardware Description Language (AHDL), which is only recognizable by Altera's design tool set.
There are two writing styles for HDL designs, structural or behavioral. Structural firmware is the software equivalent of a schematic capture design. Like schematic capture, structural designs instantiates or uses vendor-specific components to construct the desired digital functions. This type of HLD firmware is vendor-dependent like its graphical counterpart and has the same disadvantages. Like schematic capture designs, repeating the design process is necessary for different vendors.
Behavioral HDL firmware describes digital functions in generic or abstract terms that are generally vendor independent. This provides enough flexibility for code reuse in different vendor's FPGAs so little or no code modification is required. Advantages of behavioral designs are its flexibility and time and cost-savings, and it offers little to no vendor dependence. For designs that require vendor specific resources, such as RAM, only those components must change for different vendors.
VHDL and Verilog are the most popular HDL languages. VHDL files consist of three main parts: library declaration , entity declaration , and architecture section . While not required by VHDL, an optional heading section should be included. This section should contain pertinent information, such as the designer's name, filename, a brief summary of the code, and a revision history. Listing 1 shows an example of a VHDL file's behavior. Because HDLs are similar to software, firmware designers should follow some of software development rules.
View the full-size imageHDL guidelines
- Use comments to provide code clarity.
- Indicate active low signals by n , _n , _b , * at the end of the name.
- Signal names should be relatively short but descriptive. For example:
- A good signal name would be CEn for an active low chip enable.
- A bad signal name would be active_low_chip_enable .
- Use underscores in name description for clarity.
- Synchronize signals to change on a clock edge.
- Process, routes, modules, and so forth, should perform a single function.
- Use formatting, such as tabs and spaces, to provide readability of code.
- Include a header section for each file or module. Suggestive header information designer's name, file description, and revision or history record.
VHDL syntax rules
Now for some VHDL specifics, including data types:
- Std_logic can have values of high 1, low 0, unknown X , uninitialized U , high impedance Z , weak unknown W , weak 0 L , weak 1 H , and don't care – to represent a single data bit.
- Std_logic_vector can have the same values as std_logic; however it represents multiple bits.
- A bit can only have a value of high 1 or low 0, and it represents one data bit.
- Boolean represents true or false.
- Comments are denoted by double dash marks — .
- Comments continue after — until a carriage return.
- Each statement ends with a semicolon ; .
- VHDL is not case sensitive.
- No specific format is required.
- Reserved words aren't valid signal names.
- Signal names must start with a letter; numbers are not acceptable.
The library declaration is the first section in the source file. This is where you place the library and package call-out statements. Libraries and packages define and store components, define signal types, functions, procedures, and so forth. Packages and libraries are standardized, such as the IEEE library, and defined by a user (designer) or vendor. The IEEE library offers several packages, such as standard, textio, and std_logic_1164. Each of these packages defines various types, attributes, procedures, files, and so on. Here's an abbreviated list of selected IEEE packages:
- standard defines types (such as boolean, bit, time, and integer), subtypes (such as natural and positive), and the attribute foreign .
- textio package defines types (such as line and text), files (such as input and output), and procedures (such as read, readline write, and writeline).
- Std_logic_1164 package defines types (such as std_ulogic and std_ulogic_vector) and functions (such as nand, and, or, nor).
The work library serves as a place to add or delete designs. Designs stored in the work library get analyzed during synthesis and simulation. Various tools handle libraries in different ways. Therefore, users should consult the tool's documentation for correct use. To use what's in a library or package, the library must be made visible by using the keywords Library and Use clause. The IEEE std_logic_1164 package contains the types used in Listing 1. Therefore, the LIBRARY IEEE; statement makes it visible and USE IEEE.std_logic_1164.all; tells the tools to use all the contents in the std_logic_1164 package.
When a designer has specific constants, formulas, processes, and procedures that are used by multiple modules or submodules within their design, he or she can create a custom package. By doing this, the functions in the user-defined package can be shared with other designers and projects. A user-defined library/package is an easy way to repeatedly use specific HDL elements in multiple files with the luxury of only defining its elements once. Assuming a designer creates a package called my_package and stores this package in the library called Test , the following command would make the package visible, thereby allowing its contents to be used in the source file.
LIBRARY Test;USE Test.my_package.ALL;
User/designer-defined packages are similar to those supplies by vendors, such as Xilinx, whose packages contain elements such as RAMs, counters, and buffers. Xilinx's “vcomponents” package contains constants, attributes, types, and components that become available once the library and package are visible to the design. The package contains components like AND3, which is a three-input AND gate, and NAND3, a three-input NAND gate. The “vcomponent” package provides timing information, the I/O port names (used to instantiate components in design), and other information used by synthesis and simulation tools. The vendor's package becomes visible in the same manner as the standard and user-defined libraries. To use the elements in Xilinx's “vcomponent” package, designers must make the library visible. For example, the following command makes the “Xilinx” library with vcomponent package visible to the design:
LIBRARY Xilinx;USE Xilinx.vcomponents.ALL;
Once all the libraries and packages are visible, this section is complete.Entity declaration
The entity declaration section immediately follows the library declaration. Each entity has an assigned name; Monitor is the entity name of the VHLD code in Listing 1. Just as the library declaration section makes libraries and packages visible to the design, the entity section makes the I/Os visible to other source files and the design and can represent the I/Os as physical FPGA pins. VHDL designs can contain one source file or a hierarchy of multiple files. Hierarchical file structures consist of several files connected through the signals declared in their entities. Figure 2 shows a simplified hierarchical file structure for a home security system.
On the other hand, if the design is only one file, the top-level entity declaration defines all of the I/O that represents physical FPGA pins. All I/O signals defined in this section must have unique names, indicated signal direction (input or output), and number of bits reserved for the signal. From Listing 1, reset is an input, only one data-bit wide and is a std_logic data type. The keyword END followed by the entity's name signifies the end of the entity. All entities must be associated with an architecture section.
The architecture section , which contains the circuit description, is the body of the VHDL source code. The libraries, packages, and signals work together to develop the desired functions. Like the entity, each architecture must have an assigned name. The format for declaring the architecture is the reserved word Architecture followed by its name Door_monitor , then the reserved word Of , then the entity's name Monitor . Signals not defined in the entity section are defined in this section.
The signal assignment format consists of the reserved word Signal followed by the signal name and then the data type (such as std_logic and std_logic_vector ), as in Listing 1. Like names defined in the entity, each signal name must be unique and have a data type. This section is also for declaring constants, variables, and other data types.
Signals can be thought of as wires used to connect functions and store values. After defining all the design's signals, the designer is ready to develop the code that describes the desired functions. The reserved word Begin signifies the start of the next subsection, which combines the concurrent and sequential statements. Concurrent statements update or change value at anytime. The signal assignment immediately following the first reserved word BEGIN in Listing 1 is an example of a concurrent statement. Sequential statements update or change value when signals in the sensitivity list (see Listing 1) change state. Signals in “processes” are sequential statements. Most processes have a sensitivity list, process name, and circuit description (HDL code) between reserve words BEGIN and END PROCESS . The process name precedes the reserved word Process , and the sensitivity list is enclosed in the parenthesis.
Listing 1 contains two processes. The first is checking_door_status , which has a sensitivity list that contains three signals: reset , clock_20mhz , and reset_start_timer . The second process is set_alarm_enable , which only has two signals, reset and clock_20mhz , in its sensitivity list. Signals in a process that update or change following a clock edge are called synchronous signals. Start_500ns_timer in the checking_door_status process is an example of a synchronous signal. The architecture section closes by using the reserved word END followed by the architecture's name.Simulate or synthesize
One or more designers may be responsible for a design. A number of factors influence the numbers designers needed, such as design complexity and size; the designers' skill level; and the designers' schedule and availability. Regardless of the number of designers, after the design is completed, there are a couple of options. He or she may choose to simulate or synthesize the design. There isn't a hard and fast rule stating you must simulate before synthesis. There are advantages to each option, and designers must determine which step is most beneficial. In fact, there may be times when a designer decided to simulate following the completion of the initial design while another time decide to synthesize. Each option lets the designer detect and correct different types of errors.
Simulating the design prior to synthesis allows logic errors and design flaws to be resolved early in the development process. Synthesizing lets the designer resolve synthesis errors prior to logic errors and design flaws. Ideally, the designer would perform minimal simulation, leaving the more stringent testing to a code tester. The original code designer shouldn't test his own code because he's less likely to detect specific design flaws such as:
- Misinterpretation of requirements; if the designer misunderstood a requirement, he or she will test and evaluate the design based on that misunderstanding.
- It's more difficult for a person to find his own errors. A third-party generally tests the code more rigorously and is more eager to find bugs than the original designer.
Regardless of who performs the simulations, the process is the same. For the sake of this article, we're going to assume the testing is performed by a code tester, not the original designer.
Simulation is the act of verifying the HDL or graphical digital designs prior to actual hardware validation. The circuit's input-signal characteristics are described in HDL or in graphical terms that are then applied to the design. This lets the code tester observe the outputs' behavior. It may be necessary to modify the source code during simulation to resolve any discrepancies, bugs, or errors.
Simulation inputs or stimulus are inputs that mimic realistic circuit I/Os. Stimulus forces the circuit to operate under various conditions and states. The greatest benefit of stimulus is the ability to apply a wide range of both valid and invalid input-signal characteristics, test circuit limits, vary signal parameters (such as pulse width and frequency), and observe output behavior without damaging hardware. Stimulus can be applied to the design in either HDL or graphical/waveform format. Generally, when a tester or designer speaks of a testbench, he's referring to applying stimulus to the design in the form of HDL. Listing 2 shows an example of a VHDL stimulus or testbench file.
The testbench looks similar to the actual VHDL design. Hence, the same VHDL language rules apply. Each tester has a style in which he or she writes a testbench, which can be automatic or manual and can use external files for simulation and analysis. Automatic testbenches can analyze simulation data and provide a final result, output error data, or other important information. Manual testbenches require the tester to manually analyze the data. An example of an automatic testbench would be one that reads valid data from an external file, compares it with simulation data, and writes the final pass/fail results to an external file. External files are useful for duplicating events seen on actual hardware.
Data can be taken from the hardware, stored in an external file, then read into a testbench and used as the input stimulus. Many simulators accept both waveform and testbenches as input stimulus; consult your simulator user's manual for acceptable formats. Some popular simulators are Mentor Graphics' ModelSim, Aldec's Riviera, and Altera's Quantus II.
There are three levels of simulation: register transfer level (RTL), functional, and gate level. Each occurs at a specific place in the development process. RTL follows the design stage; functional follows synthesis and after implementation is completed the gate level simulation. Generally, the stimulus developed for the RTL simulation is reusable without modification for each level of simulation.Simulation
The initial simulation performed immediately after the design stage is the RTL simulation . This involves directly applying the stimulus to the design. RTL simulation only lets designers verify that the logic is correct. No realistic timing information is available to the simulator. Therefore, no serious timing exists for the design. The only timing information that can be available to the simulator is tester generated. Much like input stimulus, a tester can insert simulated or injected delays into the original HDL design, as in Listing 1. Most synthesis tools (discussed later) will ignore these simulated delays.
Applying test stimulus to the synthesized or optimized netlist produced by a synthesis tool is a functional simulation . Optimized netlists produced by non-vendors apply estimated delays that produce more realistic simulation output results. The main benefit from performing functional simulation is that it lets the tester verify that the synthesis process hasn't changed the design. Many, but not all, third-party simulation tools accept post-synthesis netlists.
Gate-level simulation involves applying stimulus to the netlist created by the implementation process. All internal timing delays are included in this netlist, which provides the tester with the most accurate design output. Again, many, but not all, third-party simulation tools can perform gate simulation.
Ideally, each level of simulation is performed at the appropriate development stage. However, if this isn't possible, it's recommended that at a minimum, RTL is performed. As this simulation is performed, it's normal for the original design to require modifications due to logic errors. Each simulation level offers various benefits. RTL uncovers logic errors, the functional level verifies that the pre- and post-synthesis designs are equivalent, and the gate level uncovers timing errors.
Some benefits to spending sufficient time generating quality testbenches and simulation are reduced time troubleshooting hardware (generally, cheaper to testbench troubleshoot than hardware troubleshoot) and a decrease in the chance of damaging hardware resulting in a faster time to market. Opting to omit simulation and testbenching will generally cost the project additional time and money. Lab testing requires collecting and setting up test equipment (such as a logic analyzer and oscilloscope) and depending on the equipment used, the designer may have a limited number of signals available. Or, the desired signal must be made available on an output, which requires additional time. Simulation is valuable and as a guideline, at least 2X the number of hours spent writing the code should be spent developing and testing the code.
While some designers prefer to proceed directly to simulation, I prefer to synthesize the design. Synthesis is the process that reduces and optimizes the HDL or graphical design logic. Some third-party synthesis tools are available as a part of the FPGA vendor's complete development package. Synplicity's Synplify and Mentor Graphics' LeonardoSpectrum, Precision RTL, and Precision Physical are examples of third-party synthesis tools. Xilinx offers ISE Project Foundation, which is a complete development application that includes a synthesis tool. Altera has Quartus II Integrated Synthesis, QIS.
Although some FPGA vendors offer synthesis, they still recommend using a third-party's synthesis tools. The synthesis tool must be set up prior to actually synthesizing the design. Synplicity's Synplify goes through a common set-up process, as it involves providing the design files (completed during design stage) and information about the FPGA. FPGA information includes the vendor's name, the specific part or family, the package type, and the speed. The synthesis process takes this information and the user-defined constraints and produces the output netlist. A constraints file specifies information like the critical signal paths and clock speeds. After completing set-up, synthesis can begin. General synthesis flow for tools like Synplicity's Synplify involves three steps, creating structural element, optimizing, and mapping. Figure 3 shows a synthesis flow diagram.
The first step in the synthesis process is to take the HDL design and compile it into structural elements. This means that the HDL design is technology independent. Synplify graphically represents this step as the “RTL Schematic View”, viewable in Synplify. The next step involves optimizing the design, making it smaller and faster by removing unnecessary logic and allowing signals to arrive at the inputs or output faster. The goal of the optimizing process is the make the design perform better without changing the circuit's functions.
The final step in the synthesis process involves mapping or associating the design to the vendor specific architecture. The mapping process takes the design and maps or connects it using the architecture of the specific vendor. This means that the design connects to vendor-specific components such as look-up tables and registers. The optimized netlist is the output of the synthesis process. This netlist may be produced in one of several formats. Edif is a general netlist format accepted by most implementation tools, while .xnf format is specific to Xilinx and is only recognized by Xilinx's implementation.
In addition to the optimized netlist, many synthesis tools like Synplify will produce a netlist for gate-level simulation and other report files. Stimulus applied to this netlist instead of the original HDL design produces the functional-level simulation, which lets the designer verify that the synthesis process hasn't changed the design's functions. At this point, synthesis is complete and ready for the implementation process. Each FPGA vendor has its own implementation tool, such as Xilinx's Project Navigator and Altera's Quartus II's.Design implementation
The final stage in the FPGA development process is the design implementation, also known as place and route (PAR) . If the FPGA vendor has a complete development tool, meaning it can perform synthesis, and the design is synthesized using this tool, little or no set-up is required for PAR. However, if a third-party synthesis tool is used, the implementation tool must be set up, which involves directing the PAR tool to the synthesized netlist and possibly a constraint file. The constraint file contains information such as maximum or minimum timing delays for selected signal(s) and I/O pin assignments.
Pin assignments can be automatic (performed by the tool) or manual (dictated by the designer). Automatic pin assignment is generally the best option for new designs, as it lets the tool more effectively route the design without having fixed pin assignments. It may be necessary to manually assign signals to specific pins to achieve easy board routing, to provide the minimum signal route for timing-critical signals, or be compatible with legacy designs.
There are numerous reasons why manual pin assignments would be necessary. But regardless of the reason, the designer must make this information available to the PAR tool, which is done by creating a user constraint file that's used by the PAR tool. After completing setup, the PAR process can begin. Each PAR tool may have a slightly different approach to design implementation, so consult your PAR documentation. Xilinx's Foundation or Project Navigator performs design implementation in three steps, translate, fit, and generate programming file.
Step one, called translate, involves verifying that the synthesized netlist is consistent with the selected FPGA architecture and there are no inconsistencies in the constraint file. Inconsistencies would consist of assigning two different signals to the same pin, assigning a pin to a power or ground pin, or trying to assign a non-existing design signal to a pin. If the design fails either check, the translate step will fail and the implementation process will be stopped.
Translate errors must be corrected and the translation step must be error free before advancing to step two, which is the fit stage. This step involves taking the constraints file and netlist and distributing the design logic in the selected FPGA. If the design is too large or requires more resources or available logic than the selected device offers, the fitter will fail and halt the implementation process. To correct this type of error, replace the current FPGA with a larger one and re-synthesize, and repeat PAR for the design. A successful fit stage is necessary to proceed to generate the programming file stage.
All timing information is available and many PAR tools will provide the required files necessary for the simulator to perform a timing simulation. The final step is to generate the programming file, which can be stored in flash memory, PROMs, or directly programming into the FPGA. JTAG and third-party programmers like Data I/O are two programming methods used to store the programming file in memory. The appropriate format depends on the FPGA vendor, the programming method, and the device used to hold the programming.
There are various output formats; consult your documentation for the correct one. In addition to the implementation process creating the programming file, there are several output report files created, such as a pad file. The pad file contains information such as signal pin assignment, part number, and part speed.
Beyond the basics
This article gives some basic examples of the FPGA development process, so a new embedded systems designer, manager, technical lead from other disciplines, or someone wanting to diversify his or her skills can understand what it takes to develop and implement a digital design in a FPGA. The generic process provided here will vary depending on the FPGA tools since each vendor may perform some of these tasks in a slight different manner.
A good resource for furthering your knowledge is Essential VHDL RTL Synthesis Done Right (Sundar Rajan, F.E. Compton Co, 1998).
Gina R. Smith is CEO and owner of Brown-Smith Research and Development Laboratory Inc., an engineering services, technical training and consulting company. She is also a senior systems engineer, with responsibility for performing failure mode effect and criticality analysis, requirements analysis and definition, creating physical and functional block diagrams, and evaluating design tool needs. She has a BS in electrical engineering magna cum laude from North Carolina A&T State University and an MS with honors in systems engineering from Johns Hopkins University. Smith can be reached at .