Signal Integrity

If Check Chain, Connection Test or functional tests usually pass but sometimes show unexplained errors then running the Signal Integrity test can be used to help ascertain if there is a problem with the JTAG chain.

Running Signal Integrity Test

Click the Signal Integrity... button in the Chain Operations section in the sub-menu of Check Chain to open the Signal Integrity Options dialog.

Signal Integrity Options Dialog

Scan Mode

• DR scan in 'SAMPLE' (Default) - Places all devices into SAMPLE mode and then scans large amounts of data through the Data Register.
• DR scan in 'BYPASS' - Places all devices into BYPASS mode and then scans large amounts of data through the Data Register.
• DR scan in 'IDCODE' - Places all devices that are supported into IDCODE mode (any unsupported are placed into BYPASS) and then scans large amounts of data through the Data Register. It does not look at the IDCODES returned, rather only checking data with a random pattern which is passed through at the end of the IDCODES.

  This mode is not available in Dynamic Chain projects.

• IR scan - Scans large amounts of data through the Instruction Register, checking the data returned matches the data sent.

Once an option has been chosen, click Start to begin running.

Stopping The Signal Integrity Test

The Signal Integrity test is designed to run indefinitely, or until 20 errors have been found. The test may be stopped at any time by clicking the Stop button. The longer the test is left to run the better, but as a general rule it should be left to run for at least 20 minutes. Ideally the scan should be left to run for many hours.

Signal Integrity Errors

Automatic Analysis

If errors are detected during the Signal Integrity Test, XJTAG will inspect the data scanned through the chain. Should the error match a known problem, XJTAG will

• Describe the error seen
• Attempt to predict the cause

Detectable Cases

This section outlines errors that the automatic analysis will look for, and describes the potential conditions on the device under test that would cause the error.

Consistent incorrect data alignment

xx11 0011 0011 0011 --> 1100 1100 1100 11xx

If the data scanned back from the chain matches the data scanned into the chain, but offset by a number of bits, this indicates that the JTAG chain length is different from what was expected.

An error such as this may occur if a device in the JTAG chain has shifted to a different state. For instance, a glitch on TCK may have caused a device to scan data through its Instruction Register, as opposed to the intended Data Register.

When an error such as this is detected, the automatic analysis will inspect each device in the chain, and using the configured BSDL files, suggest which device may have experienced the glitch.
It will also consider the possibility that a group of devices saw the glitch, although this is limited to JTAG chains of less than 20 devices.

Transient incorrect data alignment

0011 0011 0011 0011 --> 0010 0110 0111 0011

If the data scanned back from the chain initially matches the data scanned out, then becomes offset by a number of bits, and then realigns itself later on, this could be an indication that a glitch on TCK has caused a device to shift more bits than it should have.

Similar to the consistently shifted data case above, the automatic analysis will compare register lengths in the BSDL files for the devices to the number of bits the shift was observed for to suggest which device may have experienced a glitch.
Currently analysis for this type of error is limited to single devices.

Single delayed bit

0000 1111 --> 0000 0111

If the data returned from the chain exactly matches the data scanned into it, with the exception of one transition occurring one bit late, this could indicate that the setup time for one of the devices in the chain is not being met. The likely cause for this is that TCK may be too fast for the device.

Single early bit

0000 1111 --> 0001 1111

If the data returned from the JTAG chain matches what was scanned in, but with a single transition appearing one bit ahead of where it was expected, this could indicate that a glitch on TCK caused a device to shift an additional bit.

By considering the surrounding correctly aligned transitions, XJTAG will then attempt to determine the device or devices that were affected by the possible glitch.

Single skipped bit

0101 1010 --> 0101 1110

In this pattern, a pair of transitions between values have vanished. There could be many causes for such an error. It could be that TCK is too fast, and the erroneous bit is an early transition, as in the case above. Alternatively, it could be the result of an incorrect logic threshold, or just random noise.

Single flipped bit

0000 1111 --> 0000 1011

Here, a bit has appeared flipped. The most likely cause of this error is an incorrect logic threshold, or it could be noise affecting the TDI/TDO lines.

Gradual decay between logic states

x..x --> 0000 0000 0001 0010 0011 0111 1011 1111 1111

N.B. This case can be identified solely by the data returned from the chain as it is completely independent of the data that is read in.

If the data scanned back in from the chain is initially seen as all one logic value (0 in the example), and slowly transitions to the opposite value (1 in the example), this could indicate that there is a floating net somewhere in the JTAG chain.

This could happen if one of the devices did not correctly get into the requested SHIFT state - possibly due to a TCK glitch whilst navigating the JTAG state machine before the scan started. Another possible cause is that a device received an asynchronous reset or was powered down part way through a scan.

Other Potential Causes

When the Signal Integrity test fails, it shows that data cannot be reliably transferred though the JTAG chain from TDI to TDO. There are many reasons why this may happen, but the following are quite common:

• TCK frequency too high. If the period of TCK is shorter than any propagation delay, either between JTAG devices or within any JTAG device, then data errors will occur. Reducing the TCK frequency will resolve this problem.

  Get Max TCK only gives an approximate maximum frequency that can be used. It does not guarantee that the JTAG chain will work 100% reliably at that frequency.

• Incorrect buffering and/or termination of TCK. If the TCK signal is not correctly buffered and terminated then one or more devices on the JTAG chain may detect additional, spurious, clock edges. To avoid such problems, we recommend following the Design For Test (DFT) guidelines on the XJTAG website. Changing the TCK frequency may temporarily eliminate such problems, but this isn't a guaranteed stable solution. Changing the Target Termination and the Slew Rate of the TCK pin(s) on an XJLink2 may however make significant improvements.
• Crosstalk between JTAG signals. All JTAG devices change the value on TDO on the falling edge of TCK. Depending on how the signals have been routed on the board being tested, as well as the routing from the XJLink to the board, the resulting crosstalk between signals can introduce a small glitch into the falling edge of TCK. This can be enough for at least one JTAG device to detect an additional TCK cycle, corrupting the data scanned through the JTAG chain. This effect is data dependent, so the JTAG chain may appear to work reliably for some time before such an error occurs. Adding a small series termination resistor on the TDO output from JTAG devices can often help resolve such problems.
• Poor ground connections between the XJLink and the board being tested. Signals driven by the XJLink require a path for the return current to get back to the XJLink. For signals that switch at very low frequencies the route this return current takes is not as significant as when the signals switch at much higher frequencies. In the latter case there should be a route that allows the return current to closely follow the path the signal takes. This means the ground connection between the XJLink and the board should connect to the board close to where the JTAG signals connect - it should not just connect to the ground terminal of the test system's power supply! Furthermore, this ground connection should stay adjacent to the signal all the way to the XJLink.

If any problems are encountered with signal integrity then, as a minimum, both of the ground connections on the XJLink should be connected to ground points on the board being tested. See the Pin Mapping Screen for the locations of these pins on different XJLinks. If using a ribbon cable then it is ideal to have the TCK signal on a core adjacent to a ground connection, and where possible ground connections should be interleaved between JTAG signals.