Matrox Imaging - News & Events - Feature Stories Archives

What do TI C80-Based Image Processing Developers Really Want?

by Laura Robinson, Matrox Imaging

Original article featured in Advanced Imaging, February 1997

C80-based hardware/software vendors target a wide range of applications; but as a developer, you expect tools which help solve your application, match your performance requirements, and fit with your programming expertise. So what's the solution?

Texas Instruments' TMS320C80 DSP made its mark in imaging last year as C80-based hardware became a platform of choice for developing scientific and industrial imaging applications. The promise of C80-based PCI products is a new price/performance level, allowing high-end applications (many of which have relied on proprietary technology) to take advantage of lower cost, mainstream, desktop computer technology. The challenge facing C80-based hardware/software vendors is the age-old problem: how can commercial off-the-shelf (COTS) technology meet specific needs?

What developers have in common

Matrox is one of the board vendors which introduced new C80-based technology last year. (Matrox Genesis was launched in July '96.) In designing this technology, we addressed the following set of common needs:

real-time performance

Of course real-time is relative. In inspection, you might be checking labels on 20,000 bottles an hour or doing color grading of produce on-line. In medical imaging, you might be doing large kernel convolutions on high-resolution images at 30 fps. The bottomline is the need for speed.

optimized C80 processing

If you' re paying for an on-board DSP, you'll want to use it - which means squeezing out the highest performance possible.

fast time-to-market

No matter what your application, you have tight development schedules.

easily scalable performance

A single C80 might offer enough power for some applications; but others need to use multiple processors. Even if a single C80 solves it now, you're likely looking for "room to grow" which can mean employing multiple processors in the future. If you are developing a line of products, you need a range of performance levels. Ideally, it would be nice to scale down, so that the same code could run on a C80 platform and a host processor; with the host-based systems filling the lower end of your product line.

Design goals So the trick is to find a way to meet the common needs and at the same time make provisions for each developer's uniqueness. This was our approach:
concentrate on three application areas, supplying a set of pre-built software functions extensive enough to have most of the "right" functions for most of the target applications;
include high-level functions which, for certain applications, eliminates the need to write your own vision algorithms;
provide flexible functions; having multiple parameters with a variety of settings and options;
support a wide range of data types: packed binary, integer, floating-point, and RGB packed;
design an open software architecture so custom functions can be written if necessary;
provide three programming levels: a device-independent 'C' library, a board-specific 'C' library, and a DTK for developing native C80 code;
implement a hardware design that can achieve the required real-time performance;
perform rigid testing for the optimization of every software function; and
provide for efficient inter-processor communication for working in a multi-processing environment.

Target applications

The three areas that we focused on were machine vision (quality control and inspection), medical imaging (image reconstruction and visualization), and image analysis (microscopy such as cell analysis). These types of applications share enough fundamental operations to make it feasible to build a common set of tools. As well, collectively they represent a critical mass of developers, so it is worthwhile to make the significant investment in R&D.

The software is organized into modules such as image processing (point-to-point, statistics, filtering, morphology, and geometric transforms), pattern matching (hierarchical search using normalized grayscale correlation), and blob analysis (counting and measuring connected regions or objects). If you're removing noise from an MRI image, you'll mainly be interested in the enhancement operations. For surface mount assembly inspection, you would find pattern matching useful. An automated cytology system would employ blob analysis to look for abnormal cells.

Fully parameterized

Library functions have multiple parameters. You can instruct a general function to perform an operation in a specified way and with specified results. For example, to do a convolution, you select an appropriate kernel, how the operation handles the borders of an image (overscan or not), and whether the results will be saturated or not, etc. For a pattern match, you define a model (with select tolerances), set the positional accuracy, set the rotation angle, and specify the acceptance levels for match scores, etc.

Supported data types include binary (1-bit per pixel), 1-band and 3-band (color) integer including 8-, 16-, or 32-bit (signed or unsigned), floating point, and RGB packed. Different data types meet different application requirements. For example, if you need to detect the presence/absence of a part on an assembly line, using binary data will not only speed up the processing, but also maximize the use of storage space. (And the system doesn't need the greater bit depth in order to see the fine details of the part.) If your system is examining tissue samples for lesions, you may use 16-bit integer data for the extra precision provided by the greater dynamic range.

Each module of functions addresses a category of applications but there is a lot of crossover and you likely won't restrict your selection of functions to one module. No matter how many functions we include however, almost every application needs something unique, so the libraries are user extendible.

Three programming levels

Specifically, the levels are: the Matrox Imaging Library (MIL), the Matrox Genesis Native Library and the Matrox Genesis Developer's Toolkit (DTK) (in .pdf format). MIL is a set of high-level 'C' commands that works with a VGA and Matrox imaging hardware. Programming at this level will suit your needs if you want to build a portable application. (Since MIL has been available since 1993, some developers simply ported their MIL code to the new board.) Using MIL requires little knowledge of the hardware.

One of the primary design goals for the Native Library was that it accelerate MIL functions. MIL can use the host processor to execute imaging operations, but if a system has a Matrox Genesis installed, MIL transparently uses the C80 DSP (and the optional neighborhood operations accelerator (NOA), if present). As well, a MIL command will return the same result whether it runs on the host or C80. The libraries have been built to work together; MIL commands make calls to the Native Library commands.

Basically, the Native Library is a set of stub routines, one for each supported opcode. Native Library commands are initiated by the host and make remote procedure calls to the actual processing functions on the C80 (the Native Library "Shell" resides in the on-board SDRAM processing memory). This software was developed in concert with Matrox Genesis hardware; so that there is an intimate relationship between the two. For example, Native Library commands know how to make the most of the board's resources; dividing up the task between the multiple processors automatically (the C80's PPs and the NOA). There is a "back door" however, if you want to control the use of the processors, a set of commands is provided. Programming at this level does not require extensive knowledge of the C80 or DSP programming.

The two libraries' functions generally have a one-to-one correspondence; however, the Native Library has additional commands which take advantage of the board's specific architecture. (A device-independent library, by design, cannot completely exploit the special features of a processor board.) If portability is not a requirement, you may choose to develop the entire application with the Native Library. If you want mainly portable code, you can write the majority of the application with MIL commands and by using MIL's native mode programming, implement Native Library commands for certain tasks.

Chip-level programming

To extend the Native Library and develop your own custom functions, you would use the DTK in conjunction with the Texas Instruments' C80 software development tools. Programming the MP in 'C' does not require detailed knowledge of the C80, and you have access to all of the usual Native Library functions. This allows a host application to be ported easily to the MP so that the host does not have to be involved in real-time control. For programming the PPs, you'll need some knowledge of the internal architecture of the C80, including the workings of the Transfer Controller and the Parallel Processors. It usually also requires programming in assembly language in order to achieve maximum performance.

The DTK is designed to remove much of the complexity of the lowest level. It presents a model for writing new processing functions that behave exactly as existing Native Library functions. By following this model, you can concentrate your efforts on the heart of the function - the relatively small amount of PP assembly code that implements the algorithm (the so-called critical loop).

Most developers won't need to program at the lowest level, and can stick with MIL and the Native Library. Of course providing flexible and easy-to-use software tools is all for not with a C80-based platform, unless the hardware/software design can indeed achieve real-time processing performance.

Working in real-time

For real-time simultaneous acquisition, processing, and display of high speed video; solving the I/O demands is a large part of ensuring maximum performance. Matrox Genesis sustains high throughput I/O by using a custom video interface ASIC (VIA), as well as dedicated high speed buses for performing transfers on/off board. Also, the NOA was built to complement the processing power of the C80, by accelerating operations such as large convolutions or correlations. Depending on the function, NOA is up to 20 times faster than the C80.

Matrox Genesis software exploits these features of the hardware architecture. And the software itself has been designed to be extremely efficient. Optimization testing is rigorous; a function's measured performance must return the correct result in a time frame as close as possible to the theoretical performance. Accordingly, measured performance for the Native Library functions can be as low as only 1 to 2 % over theoretical calculations.

Using multiple C80s

To meet the need for scalable processing, the Matrox Genesis Main Board (which has acquisition, processing, and display) works with a Processor Board, which contains an additional one or two processing nodes (each with a C80/NOA, the VIA and SDRAM). You can add up to six Processor Boards in a system and use the power of multiple C80s. ("Scaling down" performance is achieved by using MIL to develop the real-time application on the C80-based platform and porting it to a host processor.)

To simplify programming in this multi-processing environment, Matrox implemented a hardware mechanism for efficient inter-processor communication. The VIA allows one C80 to have access to the host memory and the memory bank of every other C80 in a multi-board configuration. Otherwise communication between processors would require more host control and increase latency.

Scalable processing is a common requirement for imaging applications because a migration path protects the investment in software development and ensures system longevity. Ultimately, to meet common needs and accommodate individual needs, C80-based technology must be flexible. Developers are looking for programming tools that not only deliver significant performance gains but also tools which will help them use the processing power for their particular application.

For more information, contact our Media Relations Team.