@head: Advanced FPGA Technology for In-System Verification

@deck: Including programmable logic analysis cores eases the burden of FPGA designer, reduces design cost, and shortens the design cycle.

@text: Introduction

Moore’s Law states that the ever-growing density of each new memory integrated circuit (IC) contains roughly twice as much capacity as its predecessor, and each chip is released within 18-24 months of the previous chip. This means that, as the density of field-programmable-gate arrays (FPGAs) continues to increase, logic designers are continually challenged to discover new ways to test and verify their designs. These verification problems become even more daunting with the rapid advances in – and increased utilization of – high-speed I/O, intellectual property (IP), embedded processors, and other technologies.

Traditional methodologies have required that designers use logic analyzers, oscilloscopes, and bus analyzers to probe signals via test headers and connectors. Not only do these headers and connectors monopolize valuable board resources and device I/O, they also introduce signal integrity and clocking problems – particularly on high-speed designs.

Additionally, a great deal of planning early in the design cycle is required to predict the details of what might be needed during the testing phase. Basically, the questions facing verification engineers are: “What are the tools that can be used for taking internal FPGA measurements,” and “What techniques exist to maximize internal visibility using a fixed number of pins?” As a result, functionality that was once the sole domain of external test and measurement equipment is now being implemented in soft cores within the FPGA in order to solve the complex problems of test access.

HDL Simulation Shows Part of the Picture

Traditional HDL simulation is a well-defined and easy way to obtain a quick look at the logic contained within the design. As design sizes and complexities grow, however, problems occur which can be difficult or impossible to identify using only HDL simulation. These design observations may not allow for identification of problems that span different areas of the design or result from interaction between design modules, especially in the case of designs that include multiple clock frequencies.

Much like an auto mechanic trying to diagnose a problem in a car, there is only so much that can be observed while the car is parked in the garage. There are problems that can only be identified and diagnosed by taking the car out on the road. A verification methodology that includes on-chip debug allows the designer to see how the design operates in a real-world environment and at a normal operating speed.

On-Chip Debug

During the design process, FPGA designers have two distinct methods of taking internal, on-chip trace measurements:

  1. By planning ahead, designers can route specific nodes to allocated device pins. These signals can then be viewed using a traditional, external logic analyzer (Figure 1-1).
  2. Designers can insert low-impact verification and debug cores into the FPGA design. These cores directly access signals and nodes within the FPGA; they store captured data in internal FPGA memory and are accessed via the JTAG port (Figure 1-2).

Throughout the design process, FPGA developers make critical decisions – either by design or perhaps unintentionally – that determine how rigorous the debug process of their design will be. The most common method of gaining internal FPGA visibility is with a logic analyzer or datascope. Using this approach, the designer determines which internal nodes are of interest and need to be routed to pins for probing by an external analyzer. This method provides the advantage of deep memory traces where significant time intervals may separate the cause of a problem and the effect.

This approach of using an external logic analyzer also offers a convenient method to measure asynchronous events that might escape simulation. An example is two or more clock domains interacting with unrelated frequencies. Logic analyzers provide powerful triggering mechanisms and the resulting measurements can then be correlated with other events within the system.

To be truly effective, this type of verification requires a significant amount of up-front planning. External logic analyzers can only view signals that have been routed to pins. Thus, the primary trade-off associated with using a traditional logic analyzer is routing out signals and nodes to I/O pins that can be probed. This can be problematic in applications where I/O is at a premium.

This trade-off is further compounded by the fact that not all potential in-circuit debug issues can be identified early. Designers may have only a few pins available for debug, and this limited number may not provide adequate visibility for the problem at hand, thereby delaying project completion. Designers need to keep access to their design open in a way that allows them to make verifications decisions after they’ve implemented their design.

Logic Analysis Cores

The second option is to use programmable logic analysis cores embedded directly into the design. This verification strategy allows easy insertion of the low impact cores either prior to synthesis or post-synthesis using a variety of tools. This methodology offers designers the ability to integrate real-time debug planning into the design flow (Figure 2-1).

The ChipScope Pro system from Xilinx®, for example, allows user to interactively decide which debug cores to use and which signals and nodes need to be accessed. Core insertion is automatic by means of the Xilinx ISE Project Navigator. Designers have several different cores to choose from, depending on their design verification needs. These pre-defined verification cores can be inserted into the design or into the netlist. Following design implementation, the cores can be used to monitor and capture internal FPGA signals in real-time. These signals are then accessed via the software logic analyzer application running on a PC or workstation (Figure 2-2).

Integrated Logic Analysis (ILA) Core

The most basic of these programmable cores is the Integrated Logic Analysis (ILA) core. This is a customizable logic analyzer core that can be used to monitor any internal signal or node within the FPGA. Since the ILA core is synchronous to the design being monitored, all design clock constraints applied to the design are also applied to the components inside the core. The ILA core consists of three major components:

  • Trigger input and output logic to detect trigger events
  • Data capture logic to capture and store data samples in internal FPGA memory
  • Control and status logic to manage the operation of the ILA core itself

Integrated Bus Analyzer (IBA) Core

The use of programmable logic cores offers much more than the simply monitoring of logic signals. The Integrated Bus Analyzer (IBA) core, for example, addresses the growing reliance on embedded processors in today’s state-of-the-art FPGA designs. Thus, the IBA core is a specialized bus analyzer that is specifically designed to debug IBM CoreConnect bus structures implemented within an FPGA. The IBA core typically consists of four major components:

  • Data capture logic to capture and store trace data information using on-chip block RAM resources
  • A protocol violation monitor designed to detect and report violations of the IBM CoreConnect On-Chip Peripheral Bus (OPB) protocol
  • Trigger input and output logic to detect OPB, Processor Local Bus (PLB) bus, and other user-defined events
  • Control and status logic that manages the operation of the IBA/OPB/PLB core.

Virtual Input/Output (VIO) Core

Another advantage of programmable logic cores is that their interaction with the design can operate at a greater level than simply monitoring signals. In the case of the customizable Virtual Input/Output (VIO) core, for example, users can both monitor and drive internal FPGA signals in real time. Unlike the ILA and IBA cores, neither on- or off-chip RAM is required. Four kinds of signals are typically available in a VIO core:

  • Asynchronous inputs allow data sampling using the JTAG clock signal driven from the JTAG cable. The input values are read back periodically and displayed through an external analyzer.
  • Synchronous inputs which are sampled using the design clock. The input values are read back periodically and displayed.
  • Asynchronous outputs which are defined and driven out of the core to the surrounding design. Typically, a logical 1 or 0 value may be defined for individual asynchronous outputs.
  • Synchronous outputs are defined by the user, synchronized to the design clock and driven out of the core to the surrounding design. Typically, a logical 1 or 0 can be defined for individual synchronous outputs. With some debug products, like ChipScope Pro from Xilinx, pulse trains of 16 clock cycles’ worth of 1s and/or 0s may also be defined for synchronous outputs.

The ability to insert virtual I/O cores into a design allows users to interactively verify the design much faster and easier, and the ability to define specific I/O can greatly reduce the time spent in verification and help speed completion.

Agilent Trace Core 2 (ATC2)

In some cases, the demand for on-chip verification has been met using solutions that comprise a combination of techniques. Through joint development between Xilinx and Agilent Technologies, for example, designers also have access to a forth type of programmable logic core: the Agilent Trace Core 2 (ATC2). The ATC2 is a customizable debug capture core that is specially designed to work with the latest generation of Agilent logic analyzers by providingthe analyzer access to internal FPGA design nets.

This unique technology offers users the ability to configure and debug their designs on-chip using FPGA Dynamic Probing technology from Agilent Technologies. Users can define signal mapping between FPGA, I/O, and Agilent 16900, 1690, and 1680 logic analyzers. The ATC2 core also allows scalable ultra-deep sampling depth, more complex triggering capabilities, and 200MHz system debug performance. One other advantage not available with traditional test strategies is the ability to debug remotely through an Ethernet connection.

Modifying Test Criteria without Re-Synthesizing

In a perfect world, designers know in advance the testing criteria needed late in their design. In reality, however, there will be issues that arise late in the testing of the design that were not known prior to synthesis and implementation. The use of programmable logic analyzer cores accommodates these last minute adjustments. Hardware debug products are now available that allow users to change trigger patterns, trigger/data signal source, and enable external triggers – as well as run and stop triggers – without having to go back and re-synthesis the design. This reduces the impact of testing and shortens the time required for testing.

Even when an FPGA is involved, programmable logic analysis cores are not always the right choice. In cases where the design does not contain sufficient internal memory or when the device to be tested presents a minimal number of logic elements (which are the fundamental building block in an FPGA), test strategies based on logic analysis cores may not work. However, when testing involves a multimillion-gate FPGA with soft cores that are clearly definable, or when using high pin-count ball-grid packaging that makes external signal captures difficult or impossible, then consideration should be given to using programmable logic analysis cores as a designed-in test strategy.

Comparing Resources

Traditional test methods require the allocation of I/O pins and internal FPGA routing resources in order to bring signals out of the chip, whereas internal logic analysis cores make use of existing logic elements and internal memory resources. Designs that include user-defined logic which combine data from multiple soft cores are driving market demand for new packaging with very high I/O counts (1,100 pins in some cases).

Allocating the number of test pins necessary to fully accomplish a useful level of debugging reduces the FPGAs external functionality. Of course, the number of I/O pins assigned to test internal logic can be reduced, but only by limiting the richness of the data available for analysis.

The number of logic elements needed to empower test analysis cores within the FPGA depends primarily on the number of bits that must be analyzed in order to debug the FPGA's functional logic and the number of samples required (which determines the amount of sample memory needed).

Accuracy

In popular IC packages, signals are buried beneath the physical device and can only be accessed via board traces leading out to test headers and connectors. As the length of these traces increases and as clock speeds increase, signal reflections, clock skew, and signal crosstalk become factors that can compromise a traditional test strategy. Careful routing, shielding, and proper signal termination can minimize these effects, but require a significant amount of engineering to implement.

With external test implementations, the user is often required to debug a test strategy when attempting to characterize a problem involving high-speed control signals or wide data buses. By using vendor-supplied logic analysis cores, a user can rely upon the FPGA vendor to effectively model the delay paths between logic elements and memory. By definition, FPGA vendors use the most advanced IC processes to produce standard off-the-shelf parts that meet consistent, predictable requirements. This allows the designer to focus on differentiating internal functions and faults rather than on distinguishing equipment and connection artifacts from true failure mechanisms.

Deciding on the Test Methodology

Traditional logic analysis and core-based logic analysis technologies are both useful. Upfront consideration of several factors will help determine when each is a better fit for specific design debug requirements. Here are just a few questions to help guide the decision as to which testing methodology will be most effective:

  • What types of debug problems can be anticipated? Simpler logic problems, particularly if they are independent of design hierarchy, can be readily found with internal logic analyzers while traditional logic analyzers excel at the more complex debug applications.
  • In addition to simple logic states, will there be a need to capture timing information? If so, a traditional logic analyzer uniquely provides this value.
  • How deepare the traces that will be required? Traditional logic analyzers capture traces up to 64M on each channel while internal logic analysis cores are better suited for shallow trace depths.
  • How many pins can be dedicated for debug? The smaller the number, the better the fit with an internal logic analyzer. As more pins are dedicated to the debug process, fewer pins are available for the design itself. Remember, flip-chip and ball grid array packaging techniques don’t provide exposed leads for physical probing. So, even if the number of pins is not an issue, the available pins may not be easily accessible.
  • What tools are currently available and/or how much money does the team have to invest for new tools? While traditional logic analyzers start at $6,000 for 32 channels, internal logic analyzers start at less than $1,000.
  • What impact on the design is the team willing to tolerate? Internal cores consume some amount of FPGAs resources and may impact the timing of the design. Routing signals out to traditional logic analyzers consumes I/O resources and may also impact design timing.

Summary: The Impact of Incomplete Testing

The cost of incomplete or inadequate testing can be longer time to market, lower client satisfaction, higher design cost, and a potentially shorter product life cycle. The difficulty and cost of adding test headers and connectors can result in incomplete testing of new boards, which can have a tremendously negative impact when a bug or problem is identified.

By comparison, approaches such as prototype boards and test development boards can facilitate testing and verification of an FPGA design before a final product is produced. However, the board must still be tested and verified, and the back-and-forth nature of prototyping and verification can eat up precious design-cycle days. Alternatively, by taking advantage of the programmability available in an FPGA, complete device testing can be included in the initial design stage and subsequently used to verify the design at each development step.

author: Mark Goosman (), Product Marketing Manager, Xilinx, Inc., Longmont, CO

+++++++++++++++++++++++++++++++++++++++++++++

Captions:

Figure 1-1. FPGA signals routed to unused pins

Figure 1-2. FPGA signals captured by embedded debug cores

Figure 2-1. Examples of four programmable logic analysis cores

Figure 2-2. The ChipScope Pro hardware debugger from Xilinx