Identifying JTAG Compliance Nets with Automation Configuration
Compliance enable pins are one of the main sources of misery when developing
JTAG tests—while they may be well documented and included in the BSDL, they are
just as often undocumented, hidden, and can result in hours and hours of debug
For example, I have experienced headaches in the past when overlooking a JTAG_EN
pin that switched a processor between debug/emulation mode and boundary-scan
mode. Finding the right net was a matter of searching through netlists,
schematics, and CPU documentation to find the proper net and, once I’d
discovered the culprit, adding a test point to the board. But how could I ensure
that I would remember to look for this pin in the future and not perform the
same debug tasks twice?
By building our knowledge and then adding to TPG (both on Corelis’ side with
enhancements to our preparation engine and on our users’ side using our
configuration features) we try to make sure that no work must be duplicated
uneccessarily. This is where the Automation Configuration feature in ScanExpress
TPG shines: learning from previous experience to make every new project a little
bit easier. In this article, we’ll talk about using Automation Configuration to
produce a “Most Relevant” filter that helps point out possible compliance nets
during test development.
Compliance Enable Pins
Our prime concern is compliance-enable pins; pins that need to be a set and kept
in a certain state in order for JTAG tests to work properly. As an example,
let’s say that we have projects that may include boundary-scan components from a
variety of vendors; each vendor has defined their own compliance enable pins,
but we can see consistency across projects (since our designers like to re-use
parts from the same family). We want to be able to catch variants of the common
compliance enable pins listed below.
Identifying Filter Terms
Note: Many of these are compliance enable nets that must be held at a certain
state from power up, before boundary-scan takes control. In these cases, a
boundary-scan constraint is not enough. We include them in the list for easy
identification—when we view the constraints page in TPG and see them in the most
relevant filter, it tells us to check the schematic and test documentation to
make sure that these pins will be in the correct state for testing.
JTAG_EN – Let’s simply use just the term JTAG in our filter. This might include
JTAG TAP signals, but that’s something we can live with; if we’re developing
boundary-scan tests, we want to be aware of all nets related to JTAG! For a
real-world example, the schematic for a system with an ARM-based CPU we have
experience with calls the pin and net JTAG_CTRL. There are endless possibilities
in net names; it all depends on the naming conventions used in the projects
nCONFIG – This is an Altera compliance enable pin. We’ll use CONFIG—this should
catch most variants (eg. nCONFIG, CONFIG_N, #CONFIG) of the config pin.
PROG_B – PROGRAM is a standard Xilinx FPGA compliance enable pin. Our standard
filter already includes PROGRAM, but there are often shortened variants such as
PROG_B, PROG_N, and others. Let’s add PROG to our filter to catch these.
HSWAP_EN – Also known as PUDC_B, HSWAP_EN is another important pin on Xilinx
chips. For more information about how to deal with this particular compliance
enable pin, see the post Tip: The HSWAP Pin. We’ll add three terms to the
string: HSWAP, HSWP, and PUDC.
EMU0, EMU1 – These pins are included on many TI DSPs. A simple filter for EMU
should take care of it.
In addition, we want to flag variants of tri-state and enable pins, so let’s add
Defining The Automation Configuration String
We’ve now added to our string:
To use this string, open up ScanExpress TPG and click Tools -> Automation
Configuration… to open up the automation configuration window. The “Text to
Search for in Constraints Most Relevant Filter” field defines what we’ll see
when using the constraints browser and filtering by “Most Relevant”. Terms are
separated by a command space, so be sure to add a comma and space before pasting
in your new string data. If we started with the default string from ScanExpress
TPG v2.05, we should now have:
We’ve improved our filtering capability, but the filter isn’t going to catch
everything. We’ll want to revise the string as we become aware of other net
names and as they come up in the process of developing tests. Each improvement
to the filter cuts down on future test development time and increases test