|
Xilinx Virtex-II Pro X™ devices contain
RocketIO™ X multi-gigabit transceivers
(MGTs) capable of 10 Gbps line rates, representing
the leading edge of serial I/O performance.
In Virtex-II Pro™ devices, up to
3.125 Gbps are available from each
RocketIO transceiver, with the largest
device in the family possessing 20 MGTs.
When channel bonded together, they yield
a single aggregated data channel with 62.5
Gbps of bandwidth.
At line rates as much as two orders of
magnitude higher than single-ended I/O, lab
and test equipment used in the development
environment must keep up. Unfortunately,
equipment designed for use with high-speed
serial I/O systems may consume a large portion
of program budgets.
Should limited access to high-speed
equipment stop you from reaping the benefits
of serial I/O? In this article, we’ll present
a solution that can lift this barrier to entry
and make serial technology more accessible.
It can also maximize the availability of
expensive lab equipment for other projects.
The solution comprises a bit-error rate
(BER) testing module connected to a flexible
on-chip logic analyzer core, both
implemented in FPGA fabric. Together
with ChipScope™ Pro software tools,
these two components can replace the
diagnostic functions of a high-speed BER
tester and logic analyzer, which together
could cost more than $50,000.
RocketIO Design Flow Overview
Designing a RocketIO system requires you
to simulate the system’s digital and analog
portions. Figure 1 shows the typical flow
for an MGT design.
To ensure a reliable link, SPICE simulation
of the analog system is mandatory.
An accurate setup must include all of the
physical connections between transmitter to
receiver, using accurate models for each of
the vias, traces, connectors, and transmission
media. (The importance of SPICE
simulation is highlighted elsewhere within
this series of signal integrity articles.)
At the same time, you must also simulate
MGT functionality together with user
logic; Xilinx provides MGT SmartModels
for this purpose. Please refer to Answer
Record #14596 in the Xilinx Answers
Database for HDL simulator requirements.
Using the simulation results, you
can then design and build the prototype
board for further testing. It is during
this hardware test, debug, and
development phase that you can realize
the benefits of this complete, low-cost
debugging solution.
Debugging Challenges
The RocketIO MGT functional block
diagram shown in Figure 2 is divided
into two layers. Functions in the physical
media attachment (PMA) layer are
implemented digitally, while those in
the physical coding sublayer (PCS) are
predominantly analog.
Diagnosing a serial link issue is also
split along the same divide: analog and
digital.
Locating errors in digital logic is a
familiar process because symptoms are
easily reproducible and isolated. You
can detect and fix deterministic errors
in hardware by comparing captured
data from a logic analyzer against
expected data from simulation.
Problems are more difficult to diagnose
for the analog portion, especially
if errors seem to occur infrequently and
randomly. Results vary from trial to trial because of the random nature in
which errors occur. However, over a number
of repeated trials, it is possible to
reproduce them reliably. The BER test
does just this, and provides a useful metric
for link performance.
Why Use BER Measurements?
BER equals the number of bit errors divided
by the total number of bits transmitted.
To measure the BER, test patterns are sent
over the serial link and then compared to
the original pattern at the receiver. Because
the occurrence of errors is modeled as a stochastic
process, a calculated minimum
number of bits are transmitted before the
BER is statistically valid. Xilinx Application
Note XAPP661 discusses the method for
calculating the confidence and precision of
the BER measurement in detail.
Although many factors affect link performance,
the final figure of merit for link
reliability is the BER. These factors include
signal trace design, clock quality, power
integrity, and even impedance mismatches
due to loose manufacturing tolerances. The
BER metric has a systemic scope that covers
all these factors, such that an anomaly in any
part of the link (or its associated subsystem)
will manifest as a higher than expected BER.
One assumption inherent to the BER
measure is that the errors follow a Gaussian
distribution. You should always test this by
examining the distribution of errors in the
data stream. If you observe bursts of errors,
then the errors are non-random. This
should prompt you to check if they are
related to any noise sources, or even to the
data pattern itself.
To simplify MGT designs, Xilinx provides
a comprehensive list of power supply
and oscillator recommendations within the
RocketIO User’s Guide. Power integrity is
virtually eliminated as a potential cause for
a high BER if these recommendations are
strictly followed. Similarly, clock quality is
addressed by the oscillator recommendations.
To date, the majority of signal
integrity issues have been traced to non-recommended
power supply and oscillator
configurations.
BER testing also verifies that your SPICE
simulations resulted in a physical connection that delivers all the performance of
which the silicon is capable. With power and
clock quality taken care of, any difference
between measured and simulated results
comes down to the accuracy of the models
and manufacturing processes. To differentiate
between these, use time-domain reflectometry
(TDR) measurements of the
high-speed traces to check impedance deviations
from the PCB specification.
Determining the root cause of poor BER
is not straightforward, since multiple factors
interact to produce the measured effect.
However, you can observe how incremental
changes affect link performance by comparing BERs before and after each change.
This is useful for quick what-if scenario
testing of changes made to any part of the
link, such as the PCB, power supply, clock
source, connectors, and cables. An example
of this is during a cost-down effort, where
cost reductions are traded off with performance
based on how each component change
influences BER.
XBERT – The “Soft” BER Tester
The XBERT module pictured in Figure 4
measures BER and is delivered as a reference
design with XAPP661. It uses an
MGT to transmit serial data constructed
by a pattern generator, while
a pattern follower and compare
logic detects bit errors at
the receiver.
Control signals into the
module toggle resets and select
between various pseudo-random
bit sequence (PRBS) and
clock patterns, while the outputs
provide statistics for BER
calculation.
An idle MGT, placed close
to the active MGT, provides a
simulated noise source that is
useful when diagnosing interference
from nearby MGTs.
Such active noise is often coupled
to other MGTs through
the power supply or through
poorly designed traces.
An appropriate test pattern
must stress the link sufficiently
to accurately simulate the
data-dependent stresses that it
will encounter with real traffic.
The patterns in XBERT
are International Telecommunication
Union (ITU) recommended test patterns
used in standards such as SONET and 10
Gigabit Ethernet.
By stepping through the various stress levels
and running each for a short time, you
can obtain a coarse measure of link performance
quickly. As the link reliability improves,
patterns should get harder and you will need
to run tests for longer periods.
On its own, XBERT is by no means a
complete replacement. (For example, jitter
tolerance testing is required by some standards,
which XBERT cannot perform.) But
it can perform many of the more time- and
resource-intensive measurements than
BERT test equipment can. XBERT frees up
lab equipment for other measurements and
makes more lab resources available.
Solution Overview
When implemented in Virtex-II Pro devices,
the combination of XBERT and ChipScope
software takes a form similar to the block
diagram in Figure 3. In this particular test
setup, the data is looped back at the far end
so that both links are tested in the same trial.
Alternatively, you can have another XBERT
at the far end to test each link independently.
The inputs to XBERT are connected to
ChipScope virtual I/Os (as shown) or to user
logic. XBERT outputs such as the frame
error count and bit error count are read by
the ChipScope integrated logic analyzer
(ILA) core and used as trigger conditions.
Together, the pair provides powerful diagnostic
functionality as a data analyzer. You
can trigger on a bit error or a combination of
conditions to isolate certain types of errors.
At the same time, you can sample the
received data to examine the data pattern
around an error condition.
This provides useful clues to identify the
root cause of a bit error, especially if it is data-dependent.
For example, if DC balance is
disrupted, then bit errors will probably occur
after long run lengths.
The ChipScope Pro tool implements a
logic analyzer within the FPGA without
additional hardware. It is a real-time
debugging solution that lets you look at
signals in a design as it is running. You can
examine more ports simultaneously with
ChipScope Pro software than with any
other logic analyzer equipment
available today.
Each FPGA requires a
ChipScope ICON core to
enable this JTAG connection
to the host PC. In turn, the
ICON core supports as many
as 15 ILA, ILA/ATC,
IBA/OPB, IBA/PLB, and
VIO cores. The maximum
number of signals possible per
ILA core is limited by the
amount of logic resources
available up to a maximum of
16 trigger ports, each with a
maximum width of 256 bits.
The ChipScope Pro analyzer
GUI has a convenient waveform
viewer that formats the
sampled data in the same way
as common HDL simulators.
You can view MGT data and
status signals as they appear in
simulation, thus speeding up
the verification process.
Typical Debugging Flow
Let’s consider a scenario where you are
debugging a new prototype board and bit
errors are reported by the user logic.
ChipScope software can monitor any bus
or signal in the design. By manipulating the
ChipScope probe locations in the design
hierarchy, you can narrow in on the problem
by comparing the data in hardware against
simulation results at various checkpoints.
When the digital logic has been eliminated as
a possible cause, you can then proceed to
debug the analog portion.
Here are some debugging steps to take
when using the solution:
- Double-check the power supply and
oscillator choices against Xilinx recommendations.
- Using ChipScope software, examine the
received data and status signals directly
from the MGT outputs before any user
logic. If all is as expected, then the user
logic is at fault.
- Use parallel and serial loopback modes
to check transceiver settings and verify
correct MGT operation.
- Use ChipScope software to check the
associated status signals for each of the
MGT functions in the following order:
a) Clock and Data Recovery
b) Comma alignment
c) 8b/10b
d) Clock correction
e) Channel bonding
f ) Cyclic redundancy check (CRC).
- Run BER tests on the PCB traces to see
if the physical link itself can operate
reliably at the target line rate. Try progressively
more challenging patterns if
no errors are detected with easier test
patterns.
- Using XBERT with ChipScope software
as a data analyzer, examine the distribution
of bit errors and check if these
errors are related to any noise sources.
- Measure TDR and analyze trace and via
construction.
- If possible, gather more information
using other lab equipment.
Debug Faster
The ChipScope tool speeds up debugging.
When using ChipScope software,
changing the trigger signal or data signal
source does not require changes to the
HDL code or re-synthesis, so you can
change probe points to any signal within
the same clock domain very quickly. To
effect these changes, you need only rerun
post-synthesis implementation, resulting
in significantly shorter implementation
iterations.
The ChipScope cores can be quickly
and easily removed and inserted via the
core inserter GUI. You can also place signal
probes much faster than with a conventional
logic analyzer, especially with wide
signal buses.
The XBERT with ChipScope solution
operates independently of user logic, software,
and system-level control. Before
measuring BER, the FPGA is simply configured
using an image containing
XBERT and ChipScope software. You can
modify that same image to fit different
devices and easily reuse the same design
and techniques.
Crowded Boards and Remote Control
With increasing FPGA device densities,
high pin counts make attaching test equipment
probes a real challenge. Given the bus
widths common today, numerous external
test points are necessary; this greatly reduces
the number of remaining I/Os.
In applications where board space is a
concern, connectors for these test points
consume precious real estate. The problem
is further complicated by having to route
these bus traces in tight places.
ChipScope software addresses this by
requiring only a four-pin JTAG connection
to the host PC. Because this connection
is often provided for Boundary Scan
testing during production, in most cases
no additional pins are needed for the
ChipScope tool.
Another advantage of the solution is
that ChipScope virtual I/Os are used to
toggle ports on the MGT and other control
signals, when board space restrictions
do not allow push buttons or DIP switches.
In addition, they can also replace manual
controls in an environmental testing
context, giving full control over any net in
the design.
If the selected device is too fully utilized
for ChipScope software, try using the
next larger footprint-compatible device
during development. You can keep costs
low by switching back to the smaller
device for production.
The additional logic resources available
through the use of footprint compatibility
are freed up when ChipScope software and
XBERT are not in use. Should the need
arise, these resources can accommodate new
features and design revisions that outgrow
the original device. This eliminates the need
for a board redesign, as the footprint can fit
a range of FPGA densities.
Even without the option of a footprintcompatible
device, you can employ a divideand-
conquer strategy to debug parts of user
logic at a time, leaving sufficient resources
to implement the two solution components.
Conclusion
The Xilinx XBERT with ChipScope solution
enables faster diagnostic testing, debugging,
and development of an MGT system
without the use of expensive lab equipment
such as logic analyzers and BERT testers.
These significant cost savings reduce total
serial system development costs, allowing
even more budgets to benefit from multigigabit
serial technology.
Xilinx will be offering a signal integrity
course in the coming months. In the
meantime, to find out more about the
complete serial connectivity solution from
Xilinx, please contact your local FAE for
more information, or visit the following
web resources:
| A Success Story |
| "My application uses four channel-bonded MGTs to
communicate between processor boards in a universal
mobile telecommunications system. The 128-bit wide channel-
bonded data and numerous status signals made it very
difficult to debug using a traditional logic analyzer.
ChipScope Pro™ enabled me to easily and accurately
examine even the widest data paths and internal signals.
XBERT also proved useful in verifying my PCB and backplane
design. This solution enabled me to locate and fix a
particularly elusive bug and is a great debugging tool.
With the assistance of a Xilinx Engineer on-site via
the Xilinx Titanium Technical Service program, we very
quickly started debugging using the advanced capabilities
of ChipScope Pro. The Xilinx AE also introducted us
to the use of XBERT as described in this article. The use
of Xilinx Titanium Technical Service saved us many
weeks of debug time!”
Hyung-Rak Kim
Hardware Engineer, UMTS Wireless Systems
LG Electronics
|
Printable PDF version of this article with graphics.  (3/25/04) 170 KB |
