 | |  | |  | |  | |  | |  |
DFT Tips for implementing Boundary Scan in your design.
1) TCK shall be laid out on your PCB with Critical Signal / Clock Rules. Trust us, this saves
you and designers many hours of signal integrity debug!
2) Terminations of Scan Signals : @10K ohm resistors recommended
- TCK : Pullup or pulldown (but do not leave floating-designers like pulldowns here)
- TMS : Pullup
- TDI : Pullup
- TDO : Pullup
- TRST : Pullup
NOTE: You could check your BSDLs to see what 'state' TCK can be stopped in, then
recommend a pull to that state. Some devices may only like TCK to be stopped HIGH or
LOW... Technically, this is the thing to do...but we've never run into a problem with it
stopped in either state (on all of the devices we've tested, over all the years of testing).
3) Re-buffer your scan signals onto and off of your Unit Under Test. This will avoid fanout
limitations and termination issues with your tester, as well as ensure terminations
on-board are isolated from off-board. It's also good for board level signal integrity.
4) If you have a device in question (with a unknown/non-compliant scan chain), we
recommend putting series 0 ohm resistors on all the scan signals to these devices. This
will allow you to remove the resistors and jumper around the chip during debug. If it in fact
is non-compliant, you want to remove all of the signals because you cannot guarantee how
the non-compliant chip will react to stimulus on any Scan signal...it's non-compliant!!
5) Probably unnecessary to say, but serially connect the TDI->TDO's of all of your chips.
This will create the serial chain. All other Scan signals(TCK, TMS etc) are wired in parallel.
Keep a close eye on propagation delays for any re-buffered / voltage conversion devices
within the serial scan chain. Adding delay to one scan signal and not the others, could
create a debug and maximum TCK speed problem.
6) Ensure that you or your design engineer are aware of any Compliance Enable signals
(see BSDLs) associated with the chips on your design. Make sure they are set in the static
state required PRIOR to attempting to apply any scan signal protocol. Some folks feel that
if a scan cell is on a compliance enable pin, it can be driven during the test to activate the
chip in questions' boundary scan....but in most cases....this creates a chicken-or-egg
problem...
7) Check your BSDL files to see if they have been hardware validated and not just for
software compliance checking. Software compliance testing only means it adheres to the
IEEE standard and does not say that it matches/works properly with the hardware. This is
a big issue which we could write numerous horror stories about. If you have the leverage,
we recommend requesting hardware validation test results from your silicon supplier.
8) Programmable devices...several FPGA manufacturer's have developed devices in which
the Boundary Scan I/O structure changes with the I/O functionality programmed into the
device. In cases like this, we strongly recommend getting a 'programmed BSDL' file from
your design engineer....otherwise you will chase false failures. Some FPGA suppliers
provide a soft-tool to 'program the BSDL', others have special software switch settings on
their Programming system that keep all I/O's bidirectional during Boundary Scan test. Be
aware of this and at least have the discussion with your FPGA designer.
9) Programmable devices...be aware...I/O Banks of some FPGAs, will revert back to the
default VCCO on that bank if the FPGA is blank. Some folks feel that toggling the Program
signal will turn all I/O's back to bidirectional and eliminate the programmed BSDL problem.
This is probably OK in some situations, but if a designer has changed an I/O pins voltage
within an FPGA's bank (to something other than default VCCO), you could potentially cause
problems/damage by driving a different voltage level on the network. We recommend
always having programmed devices and programmed BSDL's when dealing with these
devices.
10) If devices on your board need different TAP voltage levels, ensure they are properly
voltage level translated. We have had cases where 'they're only test signals' was the
designers mentality....these thoughts forced an ECO to the UUT hardware. This is not an
issue in most cases...but something to look at during your DFT analysis.
11) If you plan to perform both In-Circuit and boundary scan testing, you may want to
consider tri-stateable buffers between chips on your TDO-TDI lines. In-Circuit testing will
try to test the Boundary Scan devices. Having tristateable buffers between devices allows
'guarding' against TDO data propagating through the board while TMS and TCK are applied
to the device(s). (Note: Remember, TMS & TCK are wired in parallel, affecting all devices in
the chain when applied; if no separation buffers are present.
you and designers many hours of signal integrity debug!
2) Terminations of Scan Signals : @10K ohm resistors recommended
- TCK : Pullup or pulldown (but do not leave floating-designers like pulldowns here)
- TMS : Pullup
- TDI : Pullup
- TDO : Pullup
- TRST : Pullup
NOTE: You could check your BSDLs to see what 'state' TCK can be stopped in, then
recommend a pull to that state. Some devices may only like TCK to be stopped HIGH or
LOW... Technically, this is the thing to do...but we've never run into a problem with it
stopped in either state (on all of the devices we've tested, over all the years of testing).
3) Re-buffer your scan signals onto and off of your Unit Under Test. This will avoid fanout
limitations and termination issues with your tester, as well as ensure terminations
on-board are isolated from off-board. It's also good for board level signal integrity.
4) If you have a device in question (with a unknown/non-compliant scan chain), we
recommend putting series 0 ohm resistors on all the scan signals to these devices. This
will allow you to remove the resistors and jumper around the chip during debug. If it in fact
is non-compliant, you want to remove all of the signals because you cannot guarantee how
the non-compliant chip will react to stimulus on any Scan signal...it's non-compliant!!
5) Probably unnecessary to say, but serially connect the TDI->TDO's of all of your chips.
This will create the serial chain. All other Scan signals(TCK, TMS etc) are wired in parallel.
Keep a close eye on propagation delays for any re-buffered / voltage conversion devices
within the serial scan chain. Adding delay to one scan signal and not the others, could
create a debug and maximum TCK speed problem.
6) Ensure that you or your design engineer are aware of any Compliance Enable signals
(see BSDLs) associated with the chips on your design. Make sure they are set in the static
state required PRIOR to attempting to apply any scan signal protocol. Some folks feel that
if a scan cell is on a compliance enable pin, it can be driven during the test to activate the
chip in questions' boundary scan....but in most cases....this creates a chicken-or-egg
problem...
7) Check your BSDL files to see if they have been hardware validated and not just for
software compliance checking. Software compliance testing only means it adheres to the
IEEE standard and does not say that it matches/works properly with the hardware. This is
a big issue which we could write numerous horror stories about. If you have the leverage,
we recommend requesting hardware validation test results from your silicon supplier.
8) Programmable devices...several FPGA manufacturer's have developed devices in which
the Boundary Scan I/O structure changes with the I/O functionality programmed into the
device. In cases like this, we strongly recommend getting a 'programmed BSDL' file from
your design engineer....otherwise you will chase false failures. Some FPGA suppliers
provide a soft-tool to 'program the BSDL', others have special software switch settings on
their Programming system that keep all I/O's bidirectional during Boundary Scan test. Be
aware of this and at least have the discussion with your FPGA designer.
9) Programmable devices...be aware...I/O Banks of some FPGAs, will revert back to the
default VCCO on that bank if the FPGA is blank. Some folks feel that toggling the Program
signal will turn all I/O's back to bidirectional and eliminate the programmed BSDL problem.
This is probably OK in some situations, but if a designer has changed an I/O pins voltage
within an FPGA's bank (to something other than default VCCO), you could potentially cause
problems/damage by driving a different voltage level on the network. We recommend
always having programmed devices and programmed BSDL's when dealing with these
devices.
10) If devices on your board need different TAP voltage levels, ensure they are properly
voltage level translated. We have had cases where 'they're only test signals' was the
designers mentality....these thoughts forced an ECO to the UUT hardware. This is not an
issue in most cases...but something to look at during your DFT analysis.
11) If you plan to perform both In-Circuit and boundary scan testing, you may want to
consider tri-stateable buffers between chips on your TDO-TDI lines. In-Circuit testing will
try to test the Boundary Scan devices. Having tristateable buffers between devices allows
'guarding' against TDO data propagating through the board while TMS and TCK are applied
to the device(s). (Note: Remember, TMS & TCK are wired in parallel, affecting all devices in
the chain when applied; if no separation buffers are present.
DFT Tips - Scan Control Signals etc.
| Copyright ©2009 JEK Technical Services LLC All Rights Reserved |
| Information on this page is provided free of charge and is subject to the Legal Notices posted on this website. |