Danger of having JTAG TAP controller always enabled in Xilinx parts

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi all,

I am reviewing a design, which has a bunch of JTAG-enabled parts. Some of
the these have TRST pins, others (Xilinx) don't. I came across some
interesting read on this issue:
http://klabs.org/richcontent/maplug/notices/na-gsfc-2004-04.pdf

So, my questions to Xilinx folks is:
Can I somehow make sure that the TAP controller is held in reset during
normal operation?


Thanks,
/Mikhail




Re: Danger of having JTAG TAP controller always enabled in Xilinx parts
Mikhail,

The issue of the JTAG controller being upset, and causing difficulties
is covered in many scientific papers, like those from Los Alamos Labs
(Search for Heather Quinn), also those from JPL (Gary Swift), and also NASA.

There are well known, and well characterized SEFI (single event
functional interrupt) conditions that lead to the JTAG, or the
configuration state machines, or the power on reset sections of the FPGA
to "go crazy."

Up until V4, these rare SEFI events (which only occur in space, from
heavy ion strikes), required the device to be reprogrammed, and in some
cases, powered down.

Recently, the V4 QPRO product line was announced (for radiation tolerant
space flight), and the testing has shown that no power down SEFI events
occur, but some SEFI events may still require "pulling PROG low" to
completely restart the device.  Given the rare nature of these events,
the devices are finding their way into many spacecraft packages, as
techniques exist for mitigation and recovery that are acceptable to
these missions.

http://www.embeddedstar.com/weblog/2007/05/16/virtex-4-qpro-fpga /
http://edageek.com/2007/02/13/xilinx-virtex-4-qpro-fpga-mil-grade /
(and so on...)

Xilinx has two space effects consortia, one in the US, and one in the
EU, whose members are those companies designing spacecraft electronics,
and associated universities, and national laboratories.  The proceedings
and reports from these consortia are listed on our website, as well as
appearing on their own websites.

There are recommended techniques for monitoring the JTAG, and the
configuration, so that one can recover from SEFI events contained in
various applications notes (which also concern themselves with
"scrubbing" so single event upsets don't accumulate and "break" a TMR'd
design).

http://www.xilinx.com/products/silicon_solutions/market_specific_devices/aero_def/capabilities/see.htm

Austin

Re: Danger of having JTAG TAP controller always enabled in Xilinx parts
Quoted text here. Click to load it

Thanks Austin. I guess this is the critical piece of information I was
looking for, i.e. how likely it is that anything can happen in a non-space
application...


/Mikhail



Re: Danger of having JTAG TAP controller always enabled in Xilinx parts
Non-space,

Virtually never.

More likely is noise, or uncontrolled garbage on the JTAG.  We have
actually seen a case where this happened (open pin, random noise, shuts
down system through JTAG).

Austin

Re: Danger of having JTAG TAP controller always enabled in Xilinx parts


Quoted text here. Click to load it
Not just shut down, but fry it!  In the old days, I started with the
XC9500 series CPLDs
(not designed by Xilinx, they bought this product) and was often lazy
and left the JTAG pins open until I was sure I liked the program I
loaded.  After smoking a couple CPLDs, I learned that this wasn't such a
good idea, noise could actually reprogram the device to a pathological
state that would fry it.  Sometimes I noticed the chip getting hot and
killed power, and was able to reprogram and have it work again.  It
wasn't just a latch-up, as powering off and back on resulted in the same
non-operation and high current draw.  But, reprogramming would often fix
it.  Finally I've gotten smart and put 3 pull-up resistors on the JTAG
inputs so they never float.  With the FPGAs, they need a checksum to
match to accept the configuration, so they don't burn up, at least.

Jon


Re: Danger of having JTAG TAP controller always enabled in Xilinx parts
Quoted text here. Click to load it

But if you're not dealing with SEFI concerns...

JTAG reset has caused problems for some of our designs in the past
which include TRST and non-TRST devices in the same chain.  It's been
found that some devices with TRST behave very poorly for their
standard operation when TRST is asserted!  Not good.  Since the JTAG
protocol always has a foolproof way to enter the reset state, there
isn't a need to assert the external reset on the devices that include
TRST.

If you have a group that does internal testing on your boards (if you
aren't the guy) then you might get a better conversation on why to tie
ALL the TRST pins inactive especially when you have a mixture of TRST
support on the chain.  My suggestion on a recent internal review where
I work: find our JTAG guy and ask about disabling the TRST pin on all
devices in the chain.

- John_H

Re: Danger of having JTAG TAP controller always enabled in Xilinx parts
Quoted text here. Click to load it

One of the devices I have to deal with requires that its TRST pin must be
asserted or pulsed low after power up for proper device operation!

The datasheet for another reads: "As required by the JTAG standard, this pin
includes an integrated on-chip pull-up resistor. Alternatively, if the JTAG
port of the part is not used on the PCB, then this pin should be tied to
ground with a pull-down resistor." Yeah, great! A pull-down resistor in
addition to an internal pull-up... A nice recipe for a disaster...

What a mess!...


/Mikhail



Site Timeline