| What is an application programming
interface (API)?
An Application Programming Interface is a specification of how a programmer
writing an application accesses the behavior and state of classes and objects.
What is the Java API for Boundary-Scan?
The Java API for Boundary-Scan is a complement to the Java platform.
It is a specialized Java application environment designed for the use of
developers of software and solutions for the IEEE 1149.1 boundary-scan
environment.
An attractive quality of Java API for Boundary-Scan is its exploitation
of Java’s inherent "write once run anywhere" capability. The Java API for
Boundary-Scan is a set of classes that describe the IEEE 1149.1 protocol.
Because they are written in Java they will run in a myriad of different
environments including automatic test equipment (ATE), PCs, workstations,
third party boundary scan hardware and software applications, PLD and memory
programmers and embedded processors. The Java API for Boundary-Scan enables
developers to quickly and easily build a endless variety of applications
for IEEE 1149.1 boundary scan that:
-
are platform independent.
-
are based on an easy-to-use and widely utilized and fully supported programming
environment (Java).
-
are capable of running in a wide variety environments including highly
constrained embedded processor systems such as those based on the 8051
and elaborate, resource-rich environments such as those based on the sophisticated
PowerPC.
-
are extensible and easily integratable into existing systems.
How will the Java API for Boundary-Scan
simplify boundary-scan applications development?
Today, professional developers worldwide, who construct boundary-scan
applications typically, do so in proprietary, low-level, highly constrained
assembler-like languages. These languages tend to be proprietary to each
programmable logic device manufacturer, device programmer, ATE or boundary-scan
support vendor, and do not port easily from one platform to the next.
The Java API for Boundary-Scan is revolutionary and provides a new approach
to boundary-scan applications development and execution. It will be based
on an API that is developed by and available to the entire boundary-scan
industry (both producers and consumers). The Java API for Boundary-Scan
will run on all existing Java platforms. As a result, developers can for
the first time deliver boundary-scan applications that once written can
run everywhere without modification. Instead of a small elite group of
programmers, thousands of Java programmers can now use existing development
environments to write Java-based boundary-scan applications. Sun will also
work with leading industry partners to produce easy-to-use tools that will
make it even easier to develop applications specifically for the boundary-scan
environment.
What is IEEE 1149.1 Boundary-Scan?
Boundary Scan or JTAG is formally known as IEEE/ANSI Standard 1149.1
and was first adopted in 1990. It describes a set of design rules that
facilitate testing, programming and debugging at the chip, board and systems
level. The standard is the result of the efforts of the Joint Test Action
Group (JTAG) formed by several North American and European companies in
the mid-1980’s. IEEE Std 1149.1 was originally developed as an on-chip
test infrastructure to extend the lifetime of available automatic test
equipment (ATE). This methodology of incorporating on-chip design-for-test
allows complete control and access to the boundary pins of a device without
the need for a bed-of -nails or other test equipment. Each 1149.1 compliant
device includes a boundary-scan cell connected to each input, output or
bi-directional pin that under normal conditions is transparent and inactive
allowing signals to pass normally. When the device is placed in the test
mode, input signals can be captured for later analysis and output signals
can be set to affect other devices on the board.
The standard also allowed for user definable function extensions to
be layered on top of the test infrastructure.
Why is there interest in IEEE 1149.1 now?
The increasing complexity of device packaging technology makes obsolete
the test techniques that detect failures related to interconnect faults.
Boundary-scan facilitates rapid and automatable detection and isolation
of defects related to these common failures.
The pervasiveness of boundary-scan as a foundation for in system programming
of CPLD’s and FPGA’s has further fueled the popularity of the technology.
It is significant that all PLD vendors now support boundary-scan based
access to their devices for all in-system programming operations.
These two applications, test and programming, based on a single standard
interface (IEEE 1149.1) have further enabled the development of tools to
execute remote testing and field upgrade for entire systems.
Who will be able to use the Java
API for Boundary-Scan?
The Java Boundary Scan API is targeted at semiconductor vendors, ATE
manufacturers, third party tool vendors, programming platform vendors and
OEMs as well as other developers of boundary-scan applications who require:
-
small footprint resource limited solutions.
-
multi-platform portability.
-
a standard, fully supported development environment.
-
rapid application development.
-
broad support for development, test and debug of developed applications.
-
instant access to widely distributed programming and test data for system
update and debug
Will the Java API for Boundary-Scan
be an industry standard?
The Java API for Boundary-Scan will be developed using Sun Microsystems
Open Development Process (ODP). This rigorous process has been used by
Sun to develop more than 30 other industry standard API’s. API’s developed
using the ODP evolving with input from the producers and consumers of the
API. In the case of the Java API for Boundary-Scan many members of the
semiconductor, automatic test equipment, third party boundary-scan support
industry and end-users will be involved.
Who will support this as an industry
standard?
The Java API for Boundary-Scan was presented to the JEDEC JC42.1 committee
meeting on June 1 for consideration. Several automatic test equipment manufacturers,
semiconductor manufacturers, third party boundary-scan software developers
and potential users are exploring participation in the evolution and development
of this API.
How does this proposed industry
standard differ from others for this applications, like Altera's JAM?
The Java API for Boundary-Scan will be developed using Sun Microsystems’
Open Development Process. This ensures equally assessed input from all
concerned parties including end-users, manufacturers and application developers.
Because the Java API for Boundary-Scan is based on Java it affords immediate
access to the expertise, reference material, development and debug tools
already available for Java. Because this API is expected to be based on
JavaCard, it will be migratable to any of the Java platforms (Card, Embedded,
Personal and Enterprise) so as to match the resource requirements and features
of the intended target system.
What are the expected minimum environment
requirements for the Java API for Boundary-Scan?
The Java Card virtual machine requires approximately 10 Kbytes of code
space. The complexity of the Java API for Boundary-Scan is such that it
should require no more than an additional 8Kbytes. The amount of Java Native
Interface code should not exceed 1Kbyte. The total required code space
should therefore not exceed 20Kbytes.
What are the anticipated Java language
features required by the Java API for Boundary-Scan?
It is expected that the Java API for Boundary-Scan should require the
Java language features supported by today’s Java Card, as follows:
-
Boolean, byte, short and int data types
-
all Java object-oriented scope and binding rules
-
all Java flow-of-control statements
-
all Java operators and modifiers
-
unidimensional arrays of supported data types
-
exceptions
-
threads
Can you use traditional Java development
environments to develop applications based on the Java API for Boundary-Scan?
Yes. It is the Java API for Boundary-Scan is designed for use with any
Java development environment. After developing code in one of these environments,
if the developer is targeting the Java Card-style Virtual Machine then
the resulting code will be run through a special post-processor to ensure
that the code will run correctly and adheres to the Java Card Java Language
subset. The Java Card post-processor is currently available from Sun Microsystems.
If the developer is targeting Personal, Embedded or Enterprise Java
then the original code can be run unmodified on any of these platforms. |
