Electronic Design

FPGA Design Issues 201

You may be familiar with the basics. But to resolve the challenges that plague today's FPGAs, you need to sign up for the next-level course.

It doesn't matter if you're the logic designer, hardware engineer, or systems engineer, or if you wear all of those hats. If you use an FPGA in any sort of complex system with high speeds and multiple protocols, you'll likely wrestle with device configuration, power management, intellectual property (IP), signal integrity, and other key issues. But you needn't face these challenges alone. Applications engineers at the top FPGA houses face them every day, and they've come up with some guidelines and solutions that will make your job easier.

FPGAs that offer the most multifunction pins, I/O standards, termination schemes, and differential pairs have the most complicated guidelines for assigning signals (see "For The Best FPGA Advice, Ask The Experts,"). While Altera has no guidelines, as its devices are simpler to implement, Xilinx's guidelines are pretty complex. In any case, there are some common steps to keep in mind when assigning signals to I/O pins:

  • Use a spreadsheet to list all planned signal assignments, along with their important attributes like I/O standard, voltage, required termination scheme, and associated clocks.
  • Review the manufacturer's bank/region compatibility rules.
  • Consider using a second spreadsheet to map out the FPGA to determine which of the pins are general-purpose versus specialized, which support differential pairs and global and local clocks, and which are required for voltage references.
  • Using the information in the two spreadsheets and the bank compatibility rules, assign signals to pins from most constrained to least. For example, you may need to start with serial buses and clocks that typically may only be assigned to specific pins.
  • Assign signal buses again from most constrained to least. Considerations like simultaneously switching output (SSO) issues and incompatible I/O standards may need to be carefully weighed during this step, especially if you have a considerable number of high-speed outputs or use several different I/O standards. If your design requires local/regional clocking, you'll likely need to use pins in the vicinity of your high-speed bus, so keep that in mind as well. If the selected I/O standard for a given bank requires voltage-reference signals, remember to keep those pins free. Always assign differential signals before single-ended ones. And if on-chip termination is provided, other compatibility rules may apply.
  • Assign remaining signals where appropriate.

During this process, consider writing an HDL file that contains only the port assignments. Then, add the necessary supporting information for the I/O standard and so on by creating a constraint file using the vendor-provided tool or by manually using a text editor. With these basic files in place, you can run the place-and-route tool to see if you've overlooked some rule or made an incorrect assignment (Fig. 1).

This will let you start working with the layout engineer and planning for pc-board (PCB) routability, escape planning, thermal issues, and signal integrity early in the design process. The FPGA tools may be able to assist in these areas and help resolve issues, so be sure you understand the capability of your toolset.

The longer you wait to consult a layout expert, the more likely you will deal with complex issues and iterations that were probably avoidable with some up-front analysis. Once you're satisfied with the signal assignments, lock them down using the constraint file.

Most advanced FPGAs can handle parallel bus speeds of hundreds of megahertz and have serial interfaces that operate in the gigahertz range. At these speeds, you need to understand the basics of signal integrity, because dealing with high-frequency (short rise/fall time) signals brings a torrent of analog issues into our nice and neat digital world.

Set aside some time for reading the literature from FPGA vendors. Even if you have a specific device or vendor in mind, read literature from other vendors, too, since they tend to view the outside world differently. You will note the different viewpoints on what makes a signal high speed, how much delay can exist between switching signals and still consider them simultaneous, and so on. The FPGA vendor tools are usually quite capable of performing some basic signal-integrity analysis, so be sure you fully understand a given tool suite's potential.

Also, there are hundreds of books on signal integrity and noise reduction. If you're a novice or need a refresher course, consider Signal Integrity Issues and Printed Circuit Board Design by Douglas Brooks. For a more in-depth discussion, try High-Speed Digital Design by Howard Johnson.

FPGAs may wreak havoc on signals in a system (or other FPGA signals) with too many high-speed SSOs, which cause noise known as simultaneous switching noise (SSN). Also called ground bounce or VCC bounce, for single-ended standards, SSN is caused by multiple output drivers simultaneously switching and inducing a change in device voltage with respect to system voltage as the outputs source transient current for low-to-high transitions and sink current during high-to-low transitions.

The low-to-high transition causes VCC to sag while the high-to-low transition causes ground bounce. Since capacitance normally is built in between the VCC and ground planes, SSN is typically seen on both references. Ground bounce on a low-to-high transition, then, is likely.

The SSOs then become aggressor signals, generating noise that can couple to adjacent victim signals. A high number of SSOs for a given region can cause power-supply disturbances. This has become more of an issue for two reasons.

One, switching (rise/fall) times have decreased dramatically. Two, reduced via size and trace widths, plus greater board thicknesses, have driven up board-level inductances, which has significantly increased potential for ground bounce.

Higher load capacitance also can contribute to SSN, though to a lesser degree. SSN can cause timing push out as well when the effective VCC is lower than expected, causing the I/O buffer to switch slower than expected.

There are several ways to mitigate SSN. Some devices simplify the issue by merely limiting the choices of I/O standards, but this isn't always an option. Several vendors suggest spreading high-speed bus outputs across the die, which is absolutely wonderful advice if SSN were your only care in the world. Two fundamental problems emerge with this suggestion, though.

First, it could lead to downstream routability issues, since spreading signals out will often lead to more trace crossovers. In turn, this can create the need for more signal routing layers. Second, most designs also require investigation before spreading out signals, as there are bank/region compatibility issues when a bus is spread outside a given bank or region. So, if you carefully spread a smaller bus across a bank/region or two while minding routability, it can work just fine (see "FPGA Escape Planning").

Most vendors offer technical papers on escape planning. For a good general discussion on the subject, see High Pin Count BGA Routing Techniques Extended by Hugh Allen of CopperCAD Design at www.coppercad.com/High_Pin_Count_ BGA_Routing_Techniques_Extended.pdf.

If you're stuck with a design that has adjacent high-speed switching outputs, several techniques can help resolve potential SSN issues. Start with the proper layout and decoupling for your design. For decoupling, use closely spaced power and ground plane pairs with planar capacitance designed in. Using planar capacitance for decoupling also helps reduce inductance, which is a major contributor to system noise.

If you still feel the need to use decoupling capacitors (for mitigating SSN), place them as close to the high-speed output pins as possible. A study by Altera1 has found them to become ineffective when used with proper planar decoupling if they're placed further than an inch away. Other suggestions for reducing SSN or its potential effects include:

  • Avoid placing sensitive signals (resets, clocks, enables, and so on) near SSOs.
  • When possible, use lower skew outputs and the lowest inductance vias possible.
  • Stagger outputs into stages by inserting delays where possible. This suggestion2 can be applied even after the PCB is manufactured.

If you want to dig into the nitty-gritty details to determine if SSN will wreak havoc on your system, you should be willing to research several parameters and make several calculations. First, it's best to determine the total inductance, which can be calculated by researching or estimating the following:

  • Via length in mils (board thickness)
  • Via diameter in mils (finished)
  • Pad-to-via breakout length in mils
  • Breakout width in mils
  • Other PCB parasitic inductances in nanohenries
  • Socket inductance in nanohenries

Looking at Figure 2, use the via length and diameter in the equation (a) to calculate the via inductance. Then, use (b) to calculate the trace inductance. Add all of the inductances together for the total inductance (c).

Next, consult the documentation for the components that will be connected to the FPGA. For each component, determine the maximum input low-voltage threshold in milivolts. This is the maximum voltage required to be driven by the FPGA so that it can still detect a valid logic low state (the max VIL value). Also, determine the absolute value of the maximum input undershoot in milivolts that can be tolerated by the device and still function.

In some cases, the maximum allowable ground bounce may be listed instead of, or in addition to, the above values. Determine the maximum system ground bounce allowed by taking the lowest value of the maximum input low-voltage threshold, maximum input undershoot, or maximum ground bounce for all connected components.

Next, group similar FPGA buses according to the number and type of nets with similar load characteristics. Then, research the number of power and ground pins per area, region, or bank, as well as the number of SSOs allowed per power and ground pin pair for each I/O standard used. These numbers can be employed to calculate the total capacitive loading per group and the capacitance per output driver to determine the SSO allowance.

You should also consult your vendor to determine if you're exceeding the recommended SSOs on a per-bank and per-bank-pair basis, assuming the vendor has researched this information. And since several factors contribute to SSN, it's best to build a robust system with built-in noise resistance. Otherwise, use a device that limits the types of I/O standards on a perpin basis and thus limits potential SSN issues.

You probably won't find more controversy in FPGA design than in the handling of differential signals. As with SSN, it's best to absorb as much information from the FPGA vendors, books, and user groups as possible. Also, consult your layout house to see what it recommends before committing to a specific scheme.

Great debates are being waged over whether differential pairs should be broadside or edge coupled, and exactly how much coupling should exist between the pair. The answer is usually some form of "well, it depends," so research is in order.

If you're unsure why you would want to choose a differential I/O standard over a single-ended one when given a choice, the answer is simple. With differential signals, you have almost complete control over the signal's return path. That's because it's part of the pair and, in theory, no current from the pair should appear on any of the ground (or power) planes.

This is assuming traces are of equal length, routed in close and constant proximity, constant and matched trace impedances, and so on. Also, with single-ended signals, you have very little control over the return path, and debugging a signal's return can be an exercise in futility.

The major disadvantage of differential signals is that they require two traces routed in close proximity to one another. This can be a headache when routing several hundred of them on a PCB. But that's the layout engineer's problem, right?

1. Altera Corporation Application Note 315: Guidelines for Designing High-Speed FPGA PCBs, published February 2004
2. Actel Corporation Application Note: Simultaneous Switching Noise and Signal Integrity, published June 2006

For The Best FPGA Advice, Ask The Experts
To prepare for this article, we talked with experts at Actel, Altera, Lattice Semiconductor, and Xilinx. We asked them a series of key design questions, including:

  • What are the top issues your applications engineers face on an ongoing basis?
  • What flow do you suggest your customers follow in starting a new FPGA design?
  • What do you suggest to your customers for handling I/O signal assignments?
  • How do you tell your customers to prepare for a migration path to another FPGA, a structured ASIC, or an ASIC?

Other questions tackled global and local/regional clocking, the combination of IP blocks, timing, and working with EDA companies. To see the full answers to these questions, check out "FPGA Q&A: Actel"; "FPGA Q&A: Altera"; "FPGA Q&A: Lattice Semiconductor"; and "FPGA Q&A: XIlinx". Also, see "Top Application Engineering Issues," which compares their answers in tabular format.

TAGS: Digital ICs
Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.