 Enhancements
to ScanWorks include the latest test advancements
By Dave Bonnett
Technical Marketing Manager
With the release of version 3.5, ASSET’s
ScanWorks will be the first boundary-scan system to
offer support for both the IEEE 1149.6 Standard for
Boundary-Scan Testing of Advanced Digital Networks and
the IEEE 1532 Standard for In-System Configuration of
Programmable Devices. In fact, ScanWorks is the first
in the industry to include 1149.6 support as an option.
And, unlike other implementations which only support
a subset of the standard, ScanWorks will support all
of the capabilities of the 1532 standard.
A key to this accomplishment has been
the major role ASSET personnel have played in the development
of both standards. Adam Ley, chief technologist, has
been an active member of the 1149.6 working group while
Dave Bonnett, technical product manager, has served
as vice-chairman of the 1532 working group.
Testing High-Speed Serial Buses
The 1149.6 standard, which is sometimes
referred to as the AC-EXTEST standard, was developed
in response to the growing trend toward high-speed serial
interconnect buses on printed circuit boards (PCBs).
These buses, which require AC coupling for inter-device
signaling, have data rates in excess of a gigabit/second.
Because of the time required to complete
each boundary-scan operation, boundary-scan testing
is essentially a static test technology requiring DC-coupled
nets. Signals generated and received by standard boundary-scan
cells can not be transmitted over AC-coupled nets between
devices. To overcome this problem, the 1149.6 standard
defines a method for passing signals between 1149.6-compliant
devices while maintaining the ability to transmit and
receive logic one and logic zero values.
Special 1149.6 scan cells are designed
into devices to test the AC-coupled connections between
them. Instead of transmitting and monitoring static
logic levels, the 1149.6 cells transmit and detect the
transitions between logic levels, commonly referred
to as “edges”. A logic-level transition
is transmitted by one device and detected by the receiving
device. The receiving device analyzes the transition
to determine whether it represents a logical one or
a logical zero. 1149.6 calls for the received signal
pattern to be shifted out of the device and compared
with the expected logic level in much the same way as
boundary-scan applies tests to DC-coupled nets. By maintaining
the ability to transmit and receive logic levels, 1149.6
tests can be included in the interconnect tests of DC-coupled
nets. Tests of AC-coupled nets are included in  ScanWorks’
regular tests for shorts. 1149.6 tests will determine
whether AC-coupled nets are shorted to any other net
and the results are included in ScanWorks’ standard
interconnect test fault coverage report.
The 1149.6 standard describes several
types of device cells and BSDL (boundary-scan description
language) file extensions for implementing 1149.6 in
a boundary-scan device. When 1149.6 support is offered
with ScanWorks 3.5, ScanWorks will only require BSDL
files with the 1149.6 extensions and a net list showing
the connections between devices that support 1149.6
interconnect testing.
1149.6 testing will be supported in
ScanWorks as an additional feature and it will be available
in the interconnect test generation action. By examining
the BSDL device files, ScanWorks’ interconnect
test pattern generation (TPG) tool will detect 1149.6-compliant
devices and then analyze the on-board nets to determine
whether AC-coupled testing is supported and needed.
If it is needed, test patterns that include 1149.6 tests
will be generated and included as a part of a standard
interconnect test pattern set. Creating a separate ScanWorks
test action for AC-coupled nets will not be necessary.
If devices and the board are designed and implemented
correctly, AC-coupled testing can be essentially transparent
to the user. The only difference a user may notice is
that he may have to adjust a wait-time parameter that
sets how long the test waits for the system noise to
settle down before detecting the edge transition which
defines the logic level transmitted.
The defects detected with 1149.6 testing
are very similar to the defects detected by 1149.1 boundary
scan. These include missing devices (ICs, resistors,
capacitors, and others) improperly mounted devices,
open solder joints, shorted solder joints, and misaligned
and dead devices.
With the capabilities of1149.6, ScanWorks
users will be able to take advantage of the latest high-speed
serial data bus technologies without sacrificing test
coverage during manufacturing. Many defects that would
have required additional testing on in-circuit test
systems or the performance of extra functional tests
can be detected with the same boundary-scan tools currently
in use. ASSET has reduced test costs by providing additional
test coverage within the framework of the ScanWorks
boundary-scan system.
In-system configuration
The 1532 in-system configuration (ISC)
working group has been a collaboration of programmable
logic device (PLD) vendors and boundary-scan tool suppliers
with major contributions from Agilent and Teradyne.
The objective of the working group has been to develop
a specification that establishes a standard method for
programming PLDs. This would enable the concurrent programming
of multiple devices from different vendors, significantly
reducing the time devoted to in-system configuration
during manufacturing.
PLDs have supported in-system configuration
via the JTAG test access port (TAP) signals since the
mid-1990s. Initially, each PLD vendor implemented its
own programming method, resulting in incompatible programming
algorithms. Devices from different vendors and, in some
cases, from a single vendor’s different device
families had distinct programming algorithms. As a result,
each device had to be programmed individually.
Programming times with boundary scan
depend on many parameters, including the amount of data
to be loaded, the length of the scan path, the  test
clock (TCK) frequency and the “burn-time”
for each device location to be loaded with data. Some
devices can be programmed almost instantaneously, but
others take several minutes. And as the size and complexity
of PLDs continues to increase, programming times have
become a critical issue during manufacturing.
The 1532 standard defines a set of
boundary-scan operations for applying programming operations
to more than one device at a time. Instead of distinct
scan operations for each device, 1532-based programming
operations and data can be shifted into several devices
with one scan. Also, the burn-time, or the process of
loading data into a storage element on a PLD, can be
performed on multiple devices concurrently.
ASSET has supported the in-system configuration
of complex PLDs (CPLDs) and field programmable gate
arrays (FPGAs) for many years. This has been accomplished
by supporting the application of the STAPL and serial
vector format (SVF) files which are created by many
of the device vendors’ tools. STAPL and SVF files
contain the data to be programmed into the device as
well as the sequence of scan operations that must occur
to complete the programming operation. By maintaining
compatibility with the SVF and STAPL files that are
created by the PLD vendor tools, ASSET does not have
to analyze each new type of programmable device or create
a programming algorithm for each device type. New devices
are supported immediately in ScanWorks so the most advanced
devices can be incorporated into prototype designs and
reconfigured quickly and easily during design debug.
ASSET has followed this same approach
for 1532 in-system configuration. The data to be programmed
into a PLD will be contained in an “ISC”
program data file while the programming algorithm itself
will be described in additional 1532-specific statements
in the BSDL file for the PLD. Both the ISC program data
file and the additional 1532 statements for the device’s
BSDL file will be provided by the PLD vendor. BSDL files
will be generic to device families while ISC data files
will be specific to the configuration being implemented
in the PLD by the board designer.
1532-based programming will be implemented
in ScanWorks 3.5 as a new type of programming action.
A new dialog box will support 1532 programming development.
For consistency and ease-of-use, the 1532 dialog will
conform to the standard ScanWorks user interface. Within
this dialog, the target devices to be programmed will
be selected along with the ISC data file for each device.
ScanWorks calls up the same design description that
it has accessed to generate tests. Based on this design
description, ScanWorks manages the scan path and targets
the data to the appropriate devices. However, to accomplish
1532 programming, the description of the design must
have been built with PLD BSDL files which support 1532
programming statements. The scan path can include other
boundary-scan devices and PLDs that do not support programming
with 1532.
ScanWork’s 1532 dialog also will
display the programming operations available for each
target device. The possible operations are described
in the device’s BSDL file and generally include
operations such as erase, program, read, verify and
secure. In the 1532 dialog, whether the device will
be programmed concurrently or sequentially will also
be selected. If a device is selected for concurrent
programming, but, for some reason it cannot be programmed
concurrently, it will be programmed sequentially.
Once the programming operations are
selected, ScanWorks will build the 1532 action and a
programming vector file will be created. This file is
a compressed binary file optimized for ISC, significantly
reducing programming file sizes. Programming files can
be applied by ScanWorks or an embedded scan engine.
ScanWorks’ 1532 optional capability
has emerged from a partnership between ASSET and Lattice
Semiconductor. Lattice’s proven ispVM™ has
provided its customers an established method of concurrent
1532 in-system configuration of Lattice devices for
several years. ASSET has incorporated ispVM into ScanWorks
and coupled it with ScanWorks’ extensive capabilities
for scan path management. ispVM creates the programming
vectors and ScanWorks applies them to target devices
anywhere on an accessible scan path, including secondary
scan paths that can only be accessed through scan path
management devices like TI’s Scan Path Linkers,
National Semiconductor’s Scan Bridge devices,
Firecron’s Gateway devices and the scan path linkers
implemented in Lattice’s programmable devices.
ScanWorks with ispVM will also concatenate scan paths
when target devices for ISC are on separate scan paths.
Ongoing Enhancement
The inclusion of 1149.6 testing and
1532 in-system configuration capabilities demonstrates
ASSET’s ongoing efforts to augment ScanWorks on
a regular basis with breakthrough enhancements and technologies.
It also shows that the flexibility of ScanWorks allows
it to incorporate new boundary-scan-based technologies
as they are needed.
|
