Feature Article

Early languages

Early languages such as DataIOęs ABEL and Alteraęs AHDL were once the tools of choice for FPGA hardware design. Both of these are well-suited for designs that are close to the hardware. However, writing code that is close to the primitives in the hardware is not necessarily the clearest way to write code. Also, neither language supports test benches for testing the code.

Two other languages, very-high-definition language (VHDL) and Verilog, have emerged to address these issues. VHDL came before Verilog and is a more highly typed and verbose language. Writing in Verilog is similar to writing in C, while VHDL more closely resembles Pascal. One feature available in VHDL and not Veri- log is the ability to set up three-dimensional (3D) memory spaces. However, clear, concise code can be written with either language, and both are widely used.

Just as in writing software for embedded applications, a coding standard is important when more than one person will ever have to use the source code. The big danger is that when the person who wrote the original code leaves or moves on to another project, no one will understand how it works if the code ever has to change. Even the original designer is likely to forget it in several months.

One can easily write individual lines of understandable HDL code that collectively become extremely difficult to follow. A good coding standard will help alleviate this by providing guidelines for hierarchical structures and component instantiations. For instance, many books use various types of flip-flops as examples to model component instantiations (mostly because these are already understood by the readers). However, in practice, itęs generally poor coding style to instantiate logic by mapping each register to various kinds of flip-flops. This can lead to longer, more obfuscating logic that does not take advantage of the ability to write in VHDL and Verilog at a higher level (see Code Listing 1).

Writing specifications

Writing a design specification for the required logic usually appears to add too much time to a design cycle. However, it often turns out that writing a design specification actually facilitates getting a part functioning sooner. Writing the specification forces the design team to actually think through items that are clear at a high level but not so clear at a detailed level. For instance, getting the software engineers on a project to agree on what is going to be in an FPGAęs memory map can be a real eye-opener. As the design progresses, itęs also useful to write a description (with timing diagrams) of how the design actually works.

After writing (and agreeing on) a detailed design specification, one can estimate the size of the PLD based on the number of flip-flops likely to be needed. Sometimes, a spreadsheet is useful for this exercise. Generally, one can rest assured that the amount of logic required for a design will increase as the work progresses. With the information in hand about the size of the design, one of the first choices is deciding whether to use a complex PLD (CPLD) or an FPGA.

CPLDs retain their program when the power is off because they are PROM or flash based. Most modern CPLDs can be purchased with in-system-programmability (ISP) capability. In the last few years, the emergence of ISP in many PLDs has enabled more parallel effort between circuit-board and logic designs. ISP enables PLDs to be reprogrammed by simply connecting a cable between a PC and a ten-pin joint test action group (JTAG) header on the circuit board with the PLD. This allows programmable test points that can be especially useful with ball-grid-array (BGA) packages.

FPGA basics

FPGAs are generally either fuse linked or static-RAM (SRAM)-based. Fuse-linked FPGAs retain their program when the power is turned off. However, they are one-time-programmable (OTP) devices and can be difficult to replace if their packages have a considerable number of pins. Also, fuse-linked FPGAs can take many minutes to actually program.

SRAM-based FPGAs lose their program when the power is removed. Serial EPROMs with ISP capability are now available for programming many SRAM-based FPGAs. Although a competitor could copy the data going from the EPROM to the FPGA, reverse engineering the design from that data would be incredibly difficult. CPLDs (with the security bit set) and fuse-linked FPGAs are much more difficult to copy. The major advantage of FPGAs compared to CPLDs (other than lower current draw) is higher logic density at a lower cost.

If a design requires more than approximately 200 flip-flops, an FPGA often becomes a better choice than a CPLD, assuming that very low propagation delays or being programmed when power comes up are not important. For quick development cycles, ISP capability for a PLD (even in the field) is useful. For this reason, one should have a special kind of application to decide to use a fuse-linked FPGA. An example would be for a satellite application where a fuse-linked part may offer substantially better immunity to cosmic radiation.

Generally, one must use the place-and-route tools provided by the vendor of the PLD or FPGA. The place-and-route software accepts either a netlist from the synthesis software or the source code from an HDL that it synthesizes directly. The outputs of the place-and-route software include a programming file for the PLD and behavioral model for simulation.

Some of the new, larger FPGAs or PLDs offer some nice extra features. For instance, some of Alteraęs largest PLDs offer the ability to probe some signals during operation through the JTAG port, providing something like a virtual logic analyzer. Altera and Xilinx are offering digital delay loops to help synchronize clocks to external signals. Importance of global clocks The importance of global clocks is a worthwhile discussion topic during FPGA design. Global clocks should be considered for the multiple clock sources needed in many designs. Several reasons exist:

• Synchronous logic. Global clocks allow logic such as synchronous counters to function without glitches. (Many of the next states of the flip-flops of these synchronous counters depend on most of the current states.) With Alteraęs Max+ PlusII, for example, synchronous logic can sometimes be worked around by declaring a small counter to be a clique. Using cliques can help place the logic cells for the counter close enough together that they receive the clock virtually simultaneously.
• Simpler routing. Global clock lines go to all logic cells on the FPGA (or macrocells on a CPLD), so clocks do not tie up routing resources that can be used for other signals.
• Short clock-to-output delays. The shortest clock-to-output delays are generally obtained with global clocks.
• No hold time. With global clocks, usually, no data hold times are required. Clocking a flip-flop with a nonglobal clock using in-put data from outside the FPGA probably means that the external input data must stay valid for several nanoseconds after the clock goes away. This was an issue in a design with a Motorola 860 microprocessor interfaced with an FPGA. The particular chip select line coming from the 860 was de-asserted at approximately the same time as the address and data. Bringing the chip select from the 860 microprocessor to a global clock input of the FPGA solved the problem.

Routing clocks

The discussion above should convince most designers, no matter which part they are using for implementation, to use global clocks for flip-flops where practical. Generally, the best performance using global clocks can be obtained by bringing in the global clock on a dedicated global clock pin. However, sometimes itęs desirable to put an internally generated clock onto a global net. Actually implementing this with the synthesis and place-and-route software tools can be tricky.

In one FPGA design, the software could not route the internally generated clock. The reason turned out to be a bug in the software that would not route the internally generated clock onto a global net before it routed the other nets. Once these other nets were routed, the software lacked the routing resources to put the internally generated clock onto a global net. If this situation exists, and if one can stand the input and output pad delays, itęs usually safer to feed the internally generated clock out of the chip and then back into a global clock pin.

Engineers should also watch out for global clocks that can only be used for clocking flip-flops. A global clock may not be used to gate other signals. Therefore, if a design requires a signal to be a global clock and a source for combinational logic, the signal should be brought into two pins on the FPGA where one of the pins is a global clock pin. (Note that some clocks may clock flip-flops on either their rising or falling edges. Similarly, a global reset may only feed the asynchronous, negative logic reset input of flip-flops with these parts.)

Suppose a designer wants to bring two clocks into an FPGA and then select one of them internally to be a global clock for many flip-flops. It is useful to remember that this clock selection will bear a gate or logic-cell delay of several nanoseconds. For high-speed designs, this delay may be too much. An alternative is to use a high-speed field effect transistor (FET) subnanosecond switch external to the PLD. While the switch may require several nanoseconds to select the other clock, the delay will be minimal once the clock is selected.

An engineer might also want to use PLD outputs to feed high-speed backplane drivers. A potential problem is that the clock-to-output time of the PLD may be too long. This problem can sometimes be solved by using drivers with built-in flip-flops. The clock-to-output time of the backplane drivers may be considerably faster than the PLDs. Instantiating global signals and other special PLD-brand-specific features within the synthesis software requires different implementations for each PLD brand. Itęs useful to make up short test cases for the desired features to try to get the synthesis software to communicate the right information correctly to the place-and-route software. This helps to eliminate extraneous information from the inevitable troubleshooting to make things work. A VHDL example of this exercise, showing how to work with 1 cells and globals in Exemplaręs Leonardo Spectrum and Alteraęs Max+PlusII, is shown in Code Listing 2.

Synthesis and simulation

For larger FPGA designs, the best VHDL or Verilog synthesis generally comes with a specialized synthesis tool rather than the PLD manufactureręs own software. For CPLDs and some small FPGAs, the PLD manufactureręs own software does an equivalent job of language synthesis. For these cases, it is better to skip the extra synthesis tool to avoid any problems in interfacing between the tools.

For simple simulations, one can make use of the graphical simulators often built into the PLD vendorsę place-and-route software. However, the complexity of these simulations is often limited. Also, one must check the results of the simulation graphically.

For more complex designs, it is more effective to simulate the design with Verilog or VHDL test benches. Often, these test benches are more complicated than the original source code. One can also create models of peripheral parts to the FPGA with these test benches in order to verify that things will work together correctly. For instance, it is common to model SRAMs that are connected to PLDs with the test bench. An engineer can design the test benches to automatically check important data conditions and to report any errors to a command window.

A designer can choose to simulate the design before it is synthesized (functional model) and after it has been run through the place-and-route software (behavioral model). Functional models are easier to create since they are simply the original source code, and they usually run much faster through test benches compared to behavioral models. However, behavioral models can reveal timing problems that are not at all obvious with functional models.

There are a number of synthesis and simulation tools available from vendors such as Exemplar, Synplify, Model Technology, Aldec, and Orcad. To operate these tools, engineers typically must set up a PLD vendoręs library in the simulator. For instance, for simulating Altera PLDs in ModelSim, the designer sets up a library with the following path (assuming the default installation of Alteraęs Max+PlusII): c:/maxplus2/ vhdl87/vital/ v3_0/alt_vtl.

During an evaluation, it was determined that ModelSim was a good simulator although its own scripting language is obtuse. It was useful to create script files just to execute series of ModelSim commands that were also available via its GUI.

When a command was invoked from the GUI, the corresponding text for the command would appear on the command window. The text could then be copied to a script file.

Evaluations also showed that ModelSim does not work well with some editors that seize too much control of a script file while it is open in the editor and ModelSim is using it. Ultraedit was found to be one editor that did not cause this problem.

Be careful

Even the most careful simulations sometimes will not match real-world conditions, however.

One should try to troubleshoot designs with a logic analyzer if at all possible. With care, one can usually find an aesthetic, efficient route through an FPGA design within a reasonable schedule. It is useful to remember that one is on a route, and skipping steps or taking shortcuts can easily lead one away from a transparent, functioning design.