A Flexible Evaluation Tool
for Sensor System ASICs

While standard IC evaluation tools provide little help in fully testing ASICs, this customizable tool can readily evaluate the many facets of ASICs, from first silicon through installation—and you can download it free through Sensors Online.

Eric Jacobsen, Motorola, Inc., Imaging Systems Div.

Application-Specific Integrated Circuits (ASICs) are becoming increasingly pervasive in sensor-related systems, as they are in other electronic systems. This is particularly true for high-volume products that have specialized requirements not addressed by standard ICs. But while their inclusion can help a product achieve performance, functionality, and cost targets, ASICs' specialized nature rules out use of cost-effective tools that are available to help IC designers and R&D engineers characterize and test circuits from first silicon onward.

Standard tools can test the ASIC only after the rest of the system design is complete, and even then they do not allow isolation to help determine which component (ASIC or other) is problematic. The only tool typically available to perform ASIC evaluation is expensive back-end test equipment designed to inspect final ASIC products, which almost certainly cannot debug an ASIC once it resides in a product. Because this equipment is used primarily on the ASIC's manufacturing lines, time on it is expensive and limited, making it impractical for engineers who must examine the ASIC carefully to ascertain problems and verify adherence to a customer's specifications.

What ASIC designers and OEMs' R&D engineers need is a portable and flexible tool that can readily evaluate the ASIC's many facets at first silicon, again before the other system components are available, and then after it has been placed into the product. This article examines just such a tool, which happens to be cost effective, too. Though it uses specific components to address the needs of a particular ASIC family, its blocks are generic enough to apply to many other types of ASICs.

Let's look at the tool's architecture using general examples to explore its design philosophy (which involves establishing flexible and modular hardware platforms that are easily software configurable) and discuss architecture-related details (e.g., communication protocols, system partitioning, and interdevice connectivity) that may not be readily apparent. These discussions should provide a framework that you can use verbatim or apply to the design of another evaluation tool. We'll finish with an example of how the tool can be used to characterize, calibrate, and evaluate a smart sensor module. The Visual Basic and Assembly Language code for these and other examples are available here.

Figure 1. The ASIC evaluation tool consists of three core modules: the Visual Basic GUI, which provides a user-friendly environment to evaluate the ASIC; the CDI, which performs low-level digital control as directed by the GUI to exercise the ASIC's on-chip functionality; and the DUT module, which contains the ASIC and control circuitry that is required to evaluate the ASIC.

  • The Visual Basic Graphical User Interface (GUI) module that provides a user-friendly medium.
  • The Common Digital Interface (CDI) module that performs the low-level control functions necessary to obtain data from the ASIC and transmit it back to the GUI for further processing.
  • The Device Under Test (DUT) module that contains the ASIC, its supporting circuitry, and any circuit blocks that are desired to test the ASIC's functionality.

The GUI facilitates evaluation of an ASIC from a notebook PC using the power and ease of programming in an object-oriented language. It transparently handles all low-level commands and command protocols required to evaluate the ASIC. Because the GUI displays data and options in a straightforward manner, you need to know only the ASIC's functionality and capabilities, and not be bothered with complexities.

The GUI exchanges commands with the CDI using Serial Communications Interface protocol (SCI, also known as RS-232). The data stream, consisting of three control and protocol bytes followed by any number of data bytes, is then sent to the CDI via the following protocol:

Byte 1: Establishes the number of bytes to be received by the CDI (including the first byte)

Byte 2: A general control byte that specifies which control functions the CDI needs to perform. This general control byte is composed of eight bits that determine the required function:

Bit 7: Set to dynamically reprogram the Complex Programmable Logic Device (CPLD)

Bit 6: Set for PWM signal control

Bit 5: Set for Serial Peripheral Interface (SPI) communications control

Bit 4: Set for microcontroller General Purpose I/O (GPIO) control

Bits 3­0: Available for future platform enhancements and expansion

Byte 3: CPLD control or specific instructions for controlling the functions available via the general control byte. Because the CPLD manipulates high-speed ASIC-specific functions, this third byte is required to send specific instructions and options not contained in the general control byte. The amount of data and the various options contained within each serial transfer to the ASIC can vary. Thus, the eight bits of the third byte are defined as follows:

Bit 7: Set to repeat a sequence of serial transfers to the ASIC

Bit 6: Set to continuously repeat a single serial transfer "back-to-back"

Bits 5­3: Available for future platform enhancements and expansion

Bits 2­0: Indicate the number of data bytes (1­8) to be sent per serial transfer

The protocol for returning the data stream to the GUI for display, processing, storage, etc., is straightforward:

First byte: Number of bytes (including the first byte) to be received by the GUI.

Data bytes: The required data bytes for the required function. Since the GUI originally sent the control and data bytes to the CDI, the GUI knows what data to expect and how to process it. For example, when reprogramming the CPLD, data is sent in packets of 40 bytes. After receiving each packet, the CDI responds to the GUI: the first byte it sends is an "02," indicating two bytes to receive, followed by an $AA (hex) data byte, which confirms that the data and byte programming was successful and that the CDI is ready to receive another packet.

Once the GUI receives the data, it processes it and provides the option to save it as a text or Microsoft Excel file for future processing. Thus, the GUI is the "brains" of the evaluation tool. And because the intelligence is software-based, commands and processing of data can easily be changed, expanded, or adapted to multiple platforms. With some careful thought and planning, you can tailor the GUI's look and feel (while reusing much of the underlying Visual Basic code) to the requirements of many ASICs within and among families.

Figure 2. One Visual Basic Control Panel provides a user-friendly interface to update four PWM signals. The PWM signals use the same user-modifiable frequency base (up to 8 MHz), but each one's duty cycle can be adjusted independently. The PWM signals are useful for many functions, including switching loads, controlling motor drive circuitry, and generating multipurpose clocks.

Figure 2 shows a sample GUI screen that is used to control the CDI's four PWM signals, whose duty cycles and generator frequency base can be adjusted for a variety of applications including load switching and actuator control. The Visual Basic code required to generate the appropriate data stream to send to the CDI to update/enable the PWM signals is available here.

Another example that demonstrates how to manipulate the microcontroller's GPIO is shown in Figure 3. From the GPIO control panel, you can configure 29 GPIOs as inputs or logic-level high or low outputs.

Figure 3. This Visual Basic control panel allows independent and flexible control of the 29 GPIO ports, each of which can be configured as logic-level one, logic-level zero, or as an input. By adding multiple GPIO "commands" to the table, you can use a sequence of GPIO configurations to generate different logic patterns and sequences, such as user-defined serial or parallel interfaces.

The underlying Visual Basic code performs all the necessary calculations to update the GPIO states. The control panel also contains features and functionality enabling you to generate sequences and repeating sequences (loops) of GPIO configurations and then save these configurations to or load them from a data file. Thus, complex or irregular GPIO configurations can be created, stored, and loaded as needed, and then executed from the GPIO control panel. In fact, the SPI described later in this article can be implemented using four GPIOs and the sequencing capability of the control panel.

Figure 4 shows a block diagram of the CDI topology, including the critical connections.

Figure 4. The CDI is the digital liaison between the GUI and the DUT. The CDI consists of a microcontroller for general-purpose digital control and interface capability; a Flash memory­based CPLD for high-speed, ASIC-specific digital control; and FSRAM for data storage during high-speed data transfers to and from the ASIC. The CDI's topology provides maximum flexibility for evaluating the many different functional blocks and families of ASICs.

The first main component of the CDI is Motorola's MC68HC908XL36 microcontroller (36 KB bytes of Flash and 512 bytes RAM). The microcontroller connects to the GUI via RS-232, and to the CPLD via a 12-pin parallel port; these connections enable the microcontroller to dynamically reprogram and communicate bidirectionally with the CPLD. Four of the parallel port's 12 pins control the dynamic reprogramming of the CPLD (for further understanding of this four-pin interface, refer to details on the ispLSI series of CPLDs in the Lattice Semiconductor Data Book), and the remaining eight pins use a simple serial protocol to enable communication between the microcontroller and the CPLD. Note that the communications protocol is designed with the microcontroller as the master and the CPLD as the slave (in SPI-like terms). For other applications and their requirements, this protocol may be serial, parallel, or simply a parallel group of eight control lines where the CPLD already contains data that is to be sent to the DUT module.

For the microcontroller-CPLD connections in this topology, the eight connections are defined as follows:

Bit 7: Serial data out of XL36 (idle state is logic-level low)

Bit 6: Serial data in to XL36 (always an input, idle logic-level low)

Bit 5: Reset (resets the CPLD, idle state is logic-level high)

Bit 4: Write CPLD chip select (idle state is logic-level high)

Bit 3: Read CPLD chip select (idle state is logic-level high)

Bit 2: CPLD finished. Indicates that the CPLD has completed its functions and is available for additional commands, e.g., to send data back to the microcontroller. (Always an input to XL36, idle logic-level high)

Bit 1: Fast read/write CPLD chip select for fast single data transfers to and from the ASIC, such as high-speed ADC sampling routines (idle state is logic-level high)

Bit 0: Serial clock, generated by the microcontroller (idle state is logic-level low)

The microcontroller's remaining GPIO, PWM signal lines, and SPI communication signal lines connect with the ribbon cable to allow flexible and extensive control over the DUT module.

The microcontroller's code is written generically (as a low-level driver) to support general functions rather than particular ASIC requirements, and thus it requires modification to accommodate multiple ASICs only when functionality expansions are desired. The code can then be manipulated at the GUI level as needed to provide a distinct look and feel. Additionally, the microcontroller performs all slow (less than a few megahertz) functions such as controlling DUT-located serial or parallel interfaced D/As and A/Ds, switchable loads, actuators, and actuator control circuitry. The assembly code for the PWM and GPIO control examples is available here.

The second main component in the CDI is Lattice Semiconductor's ispLSI1032E CPLD (with an equivalent gate count of 6000), which performs all high-speed (up to 32 MHz for this topology) functions required to evaluate the ASIC. These functions include high-speed serial transfers to the ASIC using custom communication protocols, fast A/D sampling and D/A manipulation, real-time data collection and manipulation, and other functions that the microcontroller cannot perform. Typically, these high-speed functions are specific to one ASIC, and because of the CPLD's gate count limitation, the CPLD is dynamically reprogrammed via the GUI (through direct control from the microcontroller) for each ASIC to be evaluated. As with all low-level commands and control, the reprogramming of the CPLD is transparent to the user, except for a short programming delay.

The CPLD interfaces to the CDI's third main component, Fast Static Random Access Memory (FSRAM). Motorola's MC67A618 64 KB by 18-bit FSRAM, which serves as a cache for data to be exchanged with the ASIC, is especially useful for storing data that must be manipulated quickly by the CPLD and ASIC interface. For example, while the CPLD can be configured to interface with an ASIC using a high-speed serial ADC with a sampling period of 6 µs; it would be difficult if not impossible to return this data to the microcontroller or the GUI between ADC samples. Thus, the CPLD obtains the data from the ASIC's ADC every 6 µs and stores the data in FSRAM. When enough samples have been taken (or the microcontroller can interrupt the ADC sampling via a GUI-based command), the data stored in FSRAM transfers through the microcontroller to the GUI for additional processing.

Consider the example of an ASIC with a custom high-speed serial communications interface, other miscellaneous digital control and diagnostic circuitry, analog circuitry, ADCs, and H-bridge and unipolar motor drive circuit topologies. Evaluating such an ASIC requires a DUT module capable of sending commands to it and receiving data from it through a high-speed (2­8 MHz) serial interface. The DUT module must also include motors and motor connectors to test the power output drivers; resistive and inductive loads that can be dynamically controlled via the CDI are useful. Testing the ASIC's ADC for such characteristics as Integral Nonlinearity (INL) requires that the DUT board have a high-resolution DAC controllable via the CDI to input various voltages. ADC characterization may be implemented in a variety of ways:

1) For slow ADC sampling rates, you can control the DAC with the microcontroller's GPIO pins using the GPIO control panel, and upon changing the DAC's output value, read the ASIC's ADC using the CPLD. The CPLD then sends the data back to the GUI via the microcontroller.

2) For fast ADC rates, you can control the DAC's output value and read the ASIC's ADC using the CPLD.

3) Using the IEEE-488 communications protocol (also known as GPIB), Visual Basic can control lab instrumentation offering the GPIB option. Thus, you can control a precision power supply (which replaces the precision DAC) as the input voltage to the ASIC's ADC, as well as a Digital Multimeter (DMM) to verify the voltage output from the supply. (The DMM can be used to verify the output of the precision DAC in methods 1 and 2 above for yet more means of ADC characterization.) The CPLD then makes the ADC sample and returns it to the Visual Basic GUI via the microcontroller. Upon receiving the required number of samples, Visual Basic formats the ADC data and saves it to an Excel spreadsheet for further processing and analysis. (The GPIB communications capability requires a GPIB interface board for desktop PCs or a PCMCIA card for notebook computers, plus GPIB cables, the appropriate software drivers, and the Visual Basic Standard Modules for GPIB control. All these items are available through National Instruments and other sources, although you must be careful regarding compatibility of the GPIB software driver and Visual Basic as they are not all identical.)

Following are the key features of the smart sensor module:
  • SPI with MISO, MOSI, CS (active low/idle high signal), and SCLK connections
  • Pressure and temperature sensors within the module
  • Analog voltage outputs for the pressure and temperature sensors
  • Digital outputs via the SPI for the pressure and temperature sensors
  • Embedded command set for calibrating the temperature sensor
  • Embedded command set for calibrating and temperature compensating the pressure sensor
  • Embedded command set for making pressure and temperature measurements via SPI

Beginning at the lowest level of software design, the Verilog hardware description language (a C-like language used to describe the functionality of digital logic circuits) can use the SPI protocol to communicate with the smart sensor module. Verilog programming time is minimized since the communication protocol between the microcontroller and CPLD can be reused from other ASIC evaluations for this smart sensor application. And because making fast measurements (i.e., more than a few thousand samples per second) in this system is not required, there is no need to program the CPLD to manipulate the FSRAM.

Developing the Assembly Language software for the microcontroller beyond its current implementation is not required. By adhering to the protocols that interface the GUI to the microcontroller and the microcontroller to the CPLD, you can use the software without modifications.

As an alternative to using the CPLD as the interface to the smart sensor module, you can use the SPI port of the microcontroller. In this case, no Verilog programming is required. Additionally, instead of sending "request pressure" and "request temperature" serial commands to the smart sensor module, the evaluation tool can leverage the 8-bit ADC of the microcontroller within the CDI to make A/D measurements of the smart sensor module's analog temperature and pressure outputs directly. This capability can be useful for debugging and evaluating the module's various performance characteristics.

By adhering to the GUI-microcontroller interface as the foundation for the Visual Basic software, you can alter the rest of the code using artistic freedom, i.e., design the look, feel, and functionality of the GUI as desired to calibrate, compensate, and make pressure and temperature measurements with the smart sensor.

Finally, using the GPIB lab instrumentation and control capabilities within the GUI helps you create a cost-effective automated test and calibration station for smart sensors consisting of very little hardware: a GPIB-compatible pressure source, pressure reference, and oven (or similar GPIB-compatible means for changing temperature); and the evaluation tool modules (PC for the GUI, the CDI, and the smart sensor module).

Home | Contact Us | Advertise © 2009 Questex Media Group, Inc.. All rights reserved. Reproduction in whole or in part is prohibited. Please send any technical comments or questions to our webmaster.