When interfaces between two Integrated Circuits fail, debugging can be difficult.
This Answer Record attempts to give some basic guidance on practices to help capture useful debug information to help identify board level issues.
The following topics are covered within this Answer Record:
For a detailed guidance on power and signal integrity analysis and debug, please see the Hardware Debug Guide in (Xilinx Answer 62181).
When facing a board level issue that appears to be related to the interface quality between two Integrated Circuits, one common starting point is to physically monitor the quality of the signal with an Oscilloscope.
Because Oscilloscopes are developed for a wide variety of applications, not all Oscilloscope and probes are appropriate for high speed signal quality debugging.
Look for the following in your measurement setup:
With Scope Shots captured, here are a few common things to look for.
1) Does your signal not cleanly settle at its steady state value? (note: this can happen on rising edges, falling edges, or both (only rising examples are shown below)
Check your termination scheme is appropriate for the standard you are using, and see (Xilinx Answer 47504).
2) Does the Digital data look solid, but do you see a blip on the rising or falling edges?
In this instance you might be looking at a capacitive reflection from the die, see (Xilinx Answer 47504).
3) When the signal is supposed to be a steady logic '1' or steady logic '0', do you see perturbances in the level that somehow relates to I/O switching on the board?
Look at adjacent signals to see if they could be coupling to the trace you are probing, check Simultaneously Switching limits are not violated (Xilinx Answer 31905), and ensure decoupling on the Vcco rail meets User Guide recommendations for the device you are using.
Using the rule of thumb of 180ps/inch, most perturbances will occur either delayed in time, or lasting for a time that correlates to a feature on your PCB.
For example if you have a perturbance that lasts 180ps, try looking for features on your PCB that might be an inch long.
5) Are there reflections on the line? Is there ringing on the line?
Is the Signal not crossing the thresholds at the receive side?
Reflections and ringing are usually caused by impedance mismatching on the transmission line.
Perform an IBIS simulation to see if the reflections in simulations are the same as on hardware, try the Fast-Strong and Slow-Weak process corners, and look at the Pin and the Die.
If the reflections are seen at the pin but not at the die, then there is not an issue. See (Xilinx Answer 47504) for more information.
If there are still reflection seen by the die, then there is an impedance mismatch on the line. Try running the Termination Wizard in the IBIS simulator (if available), ensuring that the simulation correctly reflects the hardware.
For example, include vias, PCB information like Stackup, and the other signals around the "victim" signals.
General Debug steps / questions:
Check the Vcco and Gnd rails.
Take an oscilloscope of the rails with persist on when the interface is running.
If there is access to the test pins, perform a spy hole measurement where the design continually drives out a Logic high on test pins and scope these pins (the beginning of the Answer Record provides details on Oscilloscopes).
Ground or power bounce can occur when a large number of outputs simultaneously switch in the same direction.
It is an important step to ensure that the design passes a SSN analysis.
For details on SSN analysis see (Xilinx Answer 31905).
Check the terminations. For details on terminations see (Xilinx Answer 47225).
Perform an IBIS or Spice simulation. For details on IBIS simulations see (Xilinx Answer 50644).
Board is experiencing receive errors:
If a board is experiencing receive errors on hardware, there can be many root causes.
Details of the transmitter if the FPGA is the transmitter:
To build up a clear picture of the system is it useful to understand the details of how the outputs are driven.
Is it an OSERDES, ODDR?
What clocking topology is used, for example, CCIO driving BUFIO/BUFR combination, BUFR diving by X.
Is an output delay used? What attributes are used?
Details of the input clock? for example, scope shots of the input clock including jitter characteristics.
Timing Report details (please include timing report).
Details of the receiver:
Measurements are usually taken at the receiver, therefore it is also useful to understand what is happening at the receive side.
What receiver is used? ISERDES, IDDR, etc. If an ISERDES is used, what are the attributes which are used. (mainly INTERFACE_TYPE)
Is an input delay used? What attributes are used?
Also, details of the input clock used to receive the data? for example, scope shots of the input clock including jitter characteristics.
This might be the forwarded clock from the transmitter.
How are the receive errors identified? BIST? Calibration failure? Please provide details on how the receive errors are identified.
If the FPGA is the receiver please also include ChipScope shot showing the errors.
Timing Report details, please include timing report.
Try reproducing the issue in a testcase, strip the design down to the failing interface. Does it still fail? If possible include the testcase in the Technical Support Service Request.
After gathering this information please create a Service Request including the details in the Technical Support SelectIO Service Request checklist listed at the end of the answer record.
Open a Service Request from the support page:
Technical Support Service Request checklist:
Other miscellaneous details that can also be beneficial: