Fax +49-9131-85-8699
Abstract
A new approach towards remote hardware control in Design and Test Environments
will be described. Remote access to test hardware can reduce time-to-market and
development costs.
While, to date, the design of integrated circuits (ICs) is based on powerful
CAD tools which also support "workgroup computing" and "concurrent
engineering", the test phase of ICs has been lacking comparably powerful tools.
Because design and fabrication / test of an IC are often located in different
countries, it has always been a costly and time-consuming task to bring the
designer to the test site for silicon debug and failure analysis.
The availability of remote access to test equipment will, therefore,
significantly reduce time-to-market. It was our goal to develop a gateway
server that enables HTTP access to an electron beam testsystem which allows for
chip-internal imaging and signal measurements. Based on XMosaic 2.x, the
designer gets insight into the circuit's behavior and surface structure
acquired at a very distant location. The system allows for remote control of
imaging and measurement parameters, pan and zoom of the image itself, and
investigations on the IC's behavior. Measured waveforms are displayed under
Mosaic as well. A gateway to the design database allows the designer to view
the circuit's layout in order to ease on-chip navigation. The application
described in the paper is a new step towards distributed engineering:
using the World-Wide Web not only for information retrieval, but also for the
control of engineering tools and devices.
Introduction and Motivation
The current amount of computer assistance in Electronic Computer-Aided Design
(ECAD) is rather high, whereas in Computer-Aided Testing (CAT) of ASICs it is
still at a low level. This has been caused by the concentration on the
development of design tools for many years, while the test phase has been
neglected for a long while and has begun to receive comparable support only
recently. However, the "over-the-wall approach" [1],
where designers and test engineers work at different locations and communicate
to each another, if ever, over the dividing "wall", is still existing. With
current chip technologies offering complexities of several million transistors
integrated onto a single chip, this approach cannot be accepted any longer, as
it slows down prototype debug and failure analysis cycles and therefore
increases time-to-market. It is absolutely necessary to close the gap between
design and test, not only by means of Design for Testability
approaches, but by pulling design and test engineers together.
Fig. 1: Principle of Remote Test System Control
Throughout this paper, we will focus onto the prototype debug and failure
analysis phases during an ASIC development cycle. The prototype debug phase
closely follows first silicon, which is the first time the ASIC can be
"physically" investigated in order to check whether or not it meets the
functional and electrical specifications. It must be noted that, at this stage,
it is not sufficient to perform simple go/nogo investigations, as the
design has not proven correctness yet and each detected fault has to be tracked
down in order to exclude design errors. It is obvious that with current ASIC
complexities in the multi-million transistor range, this task is related to the
designer, who is familiar with all details of the design, and not to the test
engineer. While the test engineer operates the test equipment, the designer has
to conduct the failure analysis using his in-depth knowledge of the design.
Unfortunately, design and test equipment is, in many cases, located at
different locations. If it were possible that the designer performed key
investigations on the device under test (DUT) remotely, debug and verification
time could be shortened and thus costs could be kept low. To develop such a
Remote Control Interface (RCI) to a commercially available Electron Beam
Testsystem (EBT), we have chosen XMosaic 2.x, HTML and HTTP as a suitable
basis. Their multimedia capabilities have already proven their usability for
investigating internet-connected machines. While former
applications only granted read-only access to internet resources, the developed
CGI gateway also allows for the complete control of EBTs by a remote operator
through the extensive use of the HTML form capabilities.
Fig. 2: ADVANCE System Overview
Distributed vs. Concurrent Engineering
Although the developed system enables concurrent investigations on a DUT (i.e.
several users), the prime goal of our development has been to enable the
utilization of engineering resources located in different places, may they be
hardware or software. By concurrent engineering we mean computer-assisted
collaboration of several engineers, whereas the key concept of distributed
engineering is the use of distributed resources by one engineer. By
means of telecommunication and data transportation, our world is becoming
smaller and smaller, and we find design and test departments of big companies
scattered across the globe. There are always resources which aren't available
where they are needed. To overcome this problem, the resources should be made
accessible from any remote location, preferably by the use of telecommunication
and multimedia facilities. The latter we call distributed engineering: the use
of the global datacommunication internetwork, better known as World-Wide Web.
Our development uses these services not only for information exchange and
retrieval, but also for the control of engineering resources, tools and
devices.
Integrated Test System Structure
The developed CGI server is part of the ADVANCE Integrated Test System
[2,3], which consists of both a VLSI and an Electron Beam Testsystem for chip-external
and chip-internal investigations of the device under test. Several software
modules are integrated for additional tasks like selection of nets under
investigation, accurate positioning of the probing electron beam and rating of
measurements (cf. fig. 2).
For the ADVANCE project, the testsystem hardware control software was extended
by an interface in order to allow for the complete control through the Test
Supervisor. This interface also enables the control of a testsystem by a
remote user through a CGI server.
Fig. 3a: Electron-optical image of the device under test - Fig. 3b:
chip-internal measurement
Basics of the Electron Beam Test Principle
An Electron Beam Testsystem (EBT) is, basically, a modified scanning electron
microscope (SEM). A primary electron beam scans the device under test, causing
low-energetic secondary electrons to be emitted from the circuit's surface. The
kinetic energy of these secondary electrons depends on the DUT's topology (the
angle between the chip surface and the probing electron beam), the DUT's
material (through the material's specific work function) and the electric
potential at the circuit's surface. The secondary electrons are collected by
appropriate electromagnetic fields and analyzed by energy, resulting in an
electron-optical microscopic "electric potential image" of the circuit, where
negatively charged areas are displayed bright and positively charged ones dark
(cf. fig. 3a). By pulsing the primary electron beam, time-resolved measurements
of the circuit's potential, similar to a sampling oscilloscope, can be
performed (cf. fig. 3b). Achievable resolutions are in the range of 0.1 um
(spatial), 10mV (voltage) and 50ps (timing). While first-generation EBTs very
closely resembled the SEMs they were derived from, modern EBT systems are
completely controlled by workstations running graphical user interfaces, which
display the electron-optical image as well as the measured waveforms. Links to
the design database (i.e. schematic and layout data) support on-chip navigation
[4-6], systems using a CAD-linked EBT for automatically tracing back detected faults
to their origin are on the way [7-10].
Remote Electron Beam Test Control: Key Concepts
For the development of a Remote Control Interface for a commercially available
EBT, several constraints and requirements had to be respected:
- There should be unlimited availability throughout the internet, which of
course had to be limited by appropriate access control mechanisms to save
confidential data and ensure undisturbed work.
- The software at the client site should be kept as simple as possible, which
means that the EBT's input and output data must be translated from and to
common data formats. There should be no additional hardware required at the
client site.
- Slow lines between client and server should be taken into account, therefore
real-time imaging, although desirable, is not a primary goal.
During the work using an EBT there are several tasks which require the presence
of an engineer, like loading the DUT and supplying the appropriate input
signals. For this reason, there has to be a test engineer present at the EBT
site which prepares the EBT for remote use and fixes hardware problems, just
like he would if the designer were there.
From these constrains and requirements, the key concept of the remote test
control was derived:
- HTML and HTTP have been chosen as data format and transport protocol.
- The user submits data and commands through HTML forms and imagemaps.
- The electron-optical image and the measured waveforms are converted to
inlined gif images. The measured waveform should be available in binary form as
well.
- A CGI server accepts the user data, controls the EBT's hardware and generates
a new HTML page on the fly which includes the actual hardware settings as well
as the new image or waveform data. Although every forms-capable HTML browser
should be suitable, the system has been developed for and tested exclusively
with XMosaic 2.x.
- As there is no real-time imaging, the user has to rely on his exclusive
access to the EBT - there is no way except requesting a redisplay to detect if
another user has moved the probing beam to a different location. Therefore, a
locking mechanism has to be included to prevent multiple users from sending
different commands at the same time.
- While only one user at a time can control the EBT's hardware, "read-only"
access is allowed for multiple users.
- A test engineer (an "operator") must be available at the EBT site in order to
prepare the DUT and the EBT for remote control. Therefore, only the basic
functions needed for investigation of the DUT have to be controllable remotely,
whereas functions needed only once to setup and adjust the EBT are controlled
locally. The operator can control the EBT at any time, regardless of the
current access lock which is valid only for remote users. The remotely
controlled functions include:
- pan and zoom of the image
- image parameter control: brightness, contrast and focus
- measurement parameter control: time and voltage resolution, time and voltage
offset, beam pulse width, trigger level, number of averages
- measurement at a certain location
There should always be an extra communications channel open between the
operator and the remote user (voice or data, e.g. "talk"). The remote user
conducts the investigations, while the operator ensures correct operation of
the EBT equipment.
HTML Form and WWW Gateway Internals
The CGI gateway converts HTML form requests to actions of the EBTs hardware and
the results to a new HTML document. The two operating modes of the remote EBT
control are imaging and measurement mode. In the imaging mode, possible
requests are pan and zoom of the electron-optical image as well as adjustment
of the imaging parameters (brightness, contrast, focus). In the measurement
mode, requests include adjustment of measurement parameters (time and voltage
resolution, time and voltage offset, beam pulse width, trigger level, number of
averages) and measurements at certain positions in the actually displayed area
of the DUT. While a request in the imaging mode results in a new image of the
DUT's surface, a measurement request results in a new measurement curve
image.
The CGI server has been implemented to accept data from both GET and POST
request methods. While GET is used for initialization and reload, the form
itself is implemented as a POST request. To keep the server-generated documents
as similar to "normal" HTML documents as possible, a document reload request
not only reloads the current document, but also requests a new image from the
EBT. The HTML BASE tag is used by the server to submit a query URL as the
document base, which is used for reload and thus enables the server to keep
internal data like the current lock state between reloads. Using the same query
URL as POST request server (FORM ACTION tag) for the form avoids "hidden" input
fields for internal data, as the query string is passed to the server in a POST
request as well. The server, therefore, gets internal data via the QUERY_STRING
environment variable in addition to the user-supplied input via its standard
input stream. There are several buttons which require immediate action when
activated, and therefore a single SUBMIT-type input field was not sufficient.
As multiple submit buttons are not supported yet, these buttons were
implemented as IMAGE-type inputs, where the mere presence of the button.x and
button.y fields in the query data denote that the user has clicked on the named
button. The GIF images for the image and the measurement curve are generated on
the fly from the raw EBT data and stored as temporary files. It would have been
possible to inline these images directly from another CGI program without
temporary storage, but as (at least) XMosaic2.x ignores the HTTP
Expires: directive, such images are cached and (without a prior flush of
the image cache) never reloaded, which prevents getting up-to-date images.
When called, the server first checks its REQUEST_METHOD and QUERY_STRING
environment variables to determine initalize, reload or query
(normal) operating mode. During initialize (request method=GET,
string=""), the server looks for the measurement curve retrieved latest,
connects to the EBT, loads the current hardware settings and requests an
up-to-date image from the DUT's surface. The generated HTML document contains
links to the surface and measurement images as well as a number of input fields
of various types for controlling the EBT's hardware, with the current hardware
parameters as default values. For a reload request (request method=GET,
string!=""), the server's actions are similar, but it doesn't have to look for
the latest measurement curve as its name is taken from the query part of the
URL and kept (as only an image reload is requested, there is no need to perform
a new measurement). A query mode request is denoted by a POST request
type. The server scans the submitted data in order to detect which button has
been clicked by the user, and initiates the appropriate actions of the EBT.
The HTML page (or form) is divided into three main sections:
- an image section, where the electron-optical image and the measured waveforms
are displayed,
- a navigation and image parameter panel with buttons to change the EBT's area
of view (pan, zoom) and adjust the imaging parameters (brightness, contrast,
focus) and
- a measurement parameter panel.
Pan, zoom and measurement requests are submitted mainly by clicking into the
displayed EBT image. Three modes of operation (pan, zoom, measurement) can be
selected which determine which action is performed after the user clicked into
the image. The zoom factor can be selected separately. A button row at the
bottom of the navigation panel is used for autofocus, lock, unlock, submit and
help requests. While the imaging parameters are transferred only on a submit
request, the measurement parameters are set every time a measurement is
requested. All actions which result in a change of the DUT image (pan, zoom,
image parameter submission) cause an image reload, a measurement request
results in an updated measurement (curve) image. The actual hardware settings
are transferred back from the EBT each time a request is made.
Security Aspects and Multi-User Access Coordination
For obvious reasons, we cannot grant public access to laboratory equipment
worth millions of dollars. Unrestricted access to microscopic images and
internal signals of an integrated circuit would be a major security risk for
confidential and proprietary design data. It is, therefore, absolutely
necessary to implement an access restriction mechanism to prevent unauthorized
access and ensure work which is undisturbed by other networked users. While the
former is sufficiently guaranteed by means of the generic HTTP authentification
mechanism, the multi-user access coordination has to be implemented separately
in the CGI server. The main aspect has not been the restriction of unauthorized
users, as this is already done by the HTTP daemon, but the prevention of
several users issuing different requests at the same time. As there is no
real-time imaging, the user in control of the hardware has to rely on the fact
that the position of the probing electron beam is kept constant between two
requests. Therefore, while it is desirable to allow for "read" access to the
EBT for several users concurrently, only one user at a time may issue requests
which change the EBT's hardware settings or beam position. To achieve this, a
locking mechanism has been implemented which enables only one user at a time to
use the EBT completely - all other users may only issue read requests to get
the latest hardware settings, image and waveforms. The initial locking state of
the EBT remote control is "unlocked", and every authorized user may lock the
hardware for exclusive use. Once the locking state has changed to "locked", the
name and host of the user controlling the hardware is kept and displayed to
every other user which connects to the server. To allow for another user to
control the EBT, the user currently having full control has to free the lock
first. In a concurrent engineering environment, this procedure should be
accompanied by another open communications channel between all users for
successful collaboration.
Results and Conclusion
The Remote Testsystem Control is a new tool for industrial applications. During
the development and test phase, it has been found that the WWW approach is
sufficient for convenient use, as the typical image sizes of about 50 kB result
in moderate data transfer times even over slow lines. The average system
response time to a navigation request (which results in a new DUT image) is
about 30 seconds, the response time to a measurement request depends mainly on
the number of measurement averages, but is in a similar range. The current
bottleneck for the response times is not the data transfer over the network,
but the image data transfer from the EBT's hardware to the CGI server via a
GPIB connection. To overcome this problem, additional frame grabbing hardware
for real-time image digitizing could be used. The system has been tested both
locally over the Institute's LAN and over the German Science Internetwork (WIN
- "Wissenschaftsnetz") with no significant performance differences. It can,
therefore, be stated that the applied approach is suitable for laboratory
telepresence, remote use of test and measurement systems and distributed
engineering via the World-Wide Web. The use of the HTML standard and XMosaic2.x
at the remote site enables access even for designers not familiar with the
operational details of an EBT. Future developments will include real-time
imaging using the multimedia capabilities available through information
superhighways.
System properties
- Electron-optical image:
- GIF, 256*256 pixel, 8 bit/pixel (256 greyscales)
- Measurement image:
- GIF, 256*256 pixel, 2bit/pixel (4 colors)
- Navigation control:
- Zoom (Top View, 2/4/8 times in, 2/4/8 times out)
- Pan by mouse,
- Pan by button (up-left, up, up-right, left, right, down-left, down, down-right)
- Imaging control:
- Brightness
- Contrast
- Focus
- Autofocus
- Autostigmator
- Imaging mode (Static, Stroboscopic, LSM Line, LSM Area)
- Beam scan frequency (15.6 kHz - 1 MHz)
- Measurement control:
- Position by mouse
- Timing resolution (beam pulse width)
- Time/Division
- Volts/Division
- Curve points (125, 250, 500, 1000)
- Trigger level
- Signal offset
- Timing offset (Predelay)
- Number of Averages
References
- Wolz, W., et al.: "CAD Environment for Fast Fault Localization", Euroform
Training Session "Contactless Testing of ICs", 1991, Duisburg (Germany)
- Scharf, R., et al.: "A Distributed Environment for Automated CAD Data based
Fault Localization", 2nd European Symposium on Reliability of Electron Devices,
Failure Physics and Analysis (ESREF), 1991, Bordeaux (France)
- Helmreich, K., J. Herre, and K.D. Müller-Glaser: "Fehlerlokalisierung
durch entwurfsdatengesteuerte Signalverfolgung an einem
Elektronenstrahltestsystem: Ein Beitrag zur Integration von Entwurf und Test",
ITG/GI-Workshop "Testmethoden und Zuverlässigkeit von Schaltungen und
Systemen: Herausforderung der 90er Jahre", 1989, Grassau (Germany)
- Goldbach, M.: "Aufgabenorientierte Verarbeitung und Verwaltung von
Layoutdaten für die chipinterne Navigation mit einem Elektronenstrahl
Testsystem", Internal Report, 1994, University of Erlangen-Nürnberg,
Institute of Computer-Aided Circuit Design
- KLA Knights Excalibur: "Merlin's Workbench, Users Manual", 1988
- Scharf, R., et al.: "Reliable EBT Fine Positioning Using Correlation-Based
Window Adjustment", 3rd European Conference on Electron and Optical Beam
Testing of Electronic devices (EOBT), 1993, Zürich (Switzerland)
- Noble, A.C.: "IDA: A Tool for Computer-Aided Failure Analysis",
International Test Conference (ITC), 1992, Baltimore/MD (USA)
- Scharf, R., et al.: "CAPT/IVE: Computer Aided Prototype Testing using an
Integrated Verification Environment", Northcon/91, 1991, Portland/OR (USA)
- Melgara, M., et al.: "Automatic Location of IC Design Errors Using an E-beam
System", International Test Conference (ITC), 1988, Washington/DC (USA)
- Marzouki, M., J. Laurent, and B. Courtois: "Coupling Electron-Beam Probing
with Knowledge Based Fault Localization", International Test Conference (ITC),
1991, Nashville/TX (USA)
The Authors
- Ronald Scharf
- Born in 1966, he received his M. Sc. (EE) from
Erlangen-Nürnberg University in 1990 and is currently finishing his Ph. D.
on "Contributions to computer-aided characterization and fault localization
through chip-internal contactless probing" at the Institute of Computer-Aided
Circuit Design, University of Erlangen-Nürnberg. His interests are focused
on CAD-linked test and measurement systems (especially electron beam
testsystems) and their integration into ASIC design environments. He is also
working on distributed multimedia systems and is generally interested in all
internet topics.
- Stefan Hartmann
- Born in 1961, he received his M. Sc. (EE) from
Erlangen-Nürnberg University in 1988 and is currently working on CAD
framework tool integration at the Institute of Computer-Aided Circuit Design,
University of Erlangen-Nürnberg. His main interests include UNIX system
internals, heterogenous networks and network protocols.
- Werner Wolz
- Born in 1953, he received his M. Sc. (EE) in 1978 and his Ph. D.
in 1986 from Erlangen-Nürnberg University. He is currently leading the
Test and Testsystems Division at the Institute of Computer-Aided Circuit
Design, University of Erlangen-Nürnberg. His main interests are focused on
ASIC test in general, with emphasis on design and test links, high-speed mixed
signal testsystems and high-level test description languages.
scharf@lrs.e-technik.uni-erlangen.de (Ronald Scharf)
