Corelis Boundary-Scan Blog Boundary-Scan Blog
Successful boundary scan testing and in-system programming of your design depend on a fully functional boundary-scan chain. If the scan chain is not fully functioning, boundary scan tools won’t be able to perform and provide accurate test results. Testing all boundary scan devices simultaneously helps achieve maximum test coverage. However, it’s not uncommon for scan chain issues to arise.
Corelis offers complete training and design guidelines to our customers, but following a few basic tips can help you identify where failures exist and how to resolve them.
There are three basic tips for identifying where failures are located:
- Run a clock rate sweep by systematically running an infrastructure at all possible clock rates while looking for failures at specific frequency bands.
- Observe actual versus expected results from diagnostics. Poor signal integrity on the scan chain can result in double-clocking during data register scans which may result in a shift of actual data.
- Look for intermittent failures during the boundary-scan register test. These are often a key indicator of signal integrity problems.
Once the user is able to identify where the failure exists, debugging is the next step towards fixing the problem. In general, there are two types of scan chain integrity failures, consistent and inconsistent. Consistent failures are not intermittent and the results remain constant when tests are re-run.
Three of the most common causes of consistent failures are listed below along with possible solutions:
1. IDCODE failures
These failures are often the result of a different BSDL file version compared to the actual revision of the populated device. If it is just the version field, it is usually safe to change the BSDL file to match the new value, or the version field can be changed to “don’t cares” by using “X” instead of one or zero. If it is more than the version field, check that the device installed matches the BSDL file and the schematic.
2. Implied IDCODE failures
Implied IDCODE refers to when a device leaves the test-logic-reset state, IDCODE is the default preloaded instruction. When the device shifts out of the data path, the IDCODE register will be read. The Implied IDCODE test resets the scan chain and shifts out the device IDCODE values. If a single zero is the first bit shifted out and all the remaining bits are ones, TDI and TDO may be shorted at the TAP connector. This zero is the “leading” bit that is checked in the IDCODE test.
3. Boundary scan register issues
This is usually a length problem. Note that only the length is checked, not any return values. This runs significantly more bits through the scan chain than the other infrastructure tests. If the IDCODE passes, but the boundary scan register test fails, this may be an indicator of a bad BSDL file that does not match the silicon. Ensure that the correct BSDL file is used for the specific package part being tested.
Inconsistent failures, where test results vary and tests may pass intermittently, are typically due to signal integrity problems. With these failures, we recommend the following non-sequential considerations for debugging:
- Minimize the cable length from the boundary scan controller to the target. In general, a shorter TAP cable length decreases capacitive loading. Depending on the signal bandwidth, a short enough length may also decrease reflections/ringing. If a longer cable works better, or a specific length is required, this also indicates a signal integrity problem.
- Series termination resistors values (on TDO from the board to the controller and any on-board buffering) should be appropriate. For most boards, 22 to 33 Ohms is appropriate. Some boards have unusually high values, such as 100 Ohms or higher. This is rarely appropriate for series termination; we recommend replacing or adding another resistor in parallel to decrease it to a more appropriate value.
- Bypass each device in different infrastructure tests. Or, conversely, bypass all but one in different infrastructure tests. This may help isolate the problem.
- We recommend TDI (driving to the target), TCK, TMS, TRST all use a 1K pullup termination resistor, as close to the receiver as possible. If a device needs a signal low on power up, a pulldown may be necessary on that signal. Pulldowns instead of pullups will usually work, but has some electrical disadvantages compared to a pullup. In some cases, both a pullup and pulldown are necessary for signal termination.
- In general, lowering the TAP voltage below the “matching” interface voltage is a useful debug technique. If it decreases the failure rate, this usually indicates a signal integrity problem. A lower voltage can decrease the edge slew rate, ringing can be decreased, undershoot and overshoot can be decreased.
