硬核DSP简介及其实现

Title: Hard Core DSP – What it is and how to make it happen

Author: Lynn Patterson

Title: VP Product Development

Date: 6/11/98

OVERVIEW

In recent years Digital Signal Processing technology has been applied to a variety of types of processing applications. Generally these can be classified as non-real time, soft real-time and hard-core real-time applications.

Non real-time DSP refers to applications where the huge FLOP capacity of the DSP is put to work on historical data. The data was collected and archived for processing at a later time. The data is stored on some type of mass storage media and job processed in a compute center. Some examples are seismic evaluation, image enhancement and intelligent signal extraction applications.

Soft real-time DSP refers to applications where data arrives to the system from a “sensor” as it is sampled, an algorithm is applied to that data and results are posted. This process repeats continuously. In a “soft” system, the processing node may not be able to fully process all data without some tuning of the system. This on-the-fly adjustment can be implemented in several ways.

1. The data source can be throttled – that is there is some handshaking mechanism

from the processing back to the source that triggers the source to slow the rate at

which it delivers data to the system for processing.

2. The system employs the elasticity in the system buffers to hold the additional data

samples over the steady state rate. Essentially, one or several blocks of data are

queued up while one block requires longer for processing than the time line alotted .

The ability to allow for oversized buffering space is typically difficult and typically the

worst case scenario can not be accounted for.

3. Data is dropped. If the processing node can not accept the samples or block of

samples, it is dropped and is not retrievable.

4. Additional processing nodes are applied to the data stream. This requires the system

to have a real-time dynamic architecture.

5. The algorithm applied to the data adjusts to require a reduced processing load under

peak conditions. Depending on the nature of the adjustment, this may or may not

differentiate an application as soft or hard real-time.

In all of these cases the “performance” of the system may vary over time but the system does not fail. Consider the case ff the system throttles itself, the overall performance drops since the system does not run at full speed. For the case of elastic buffers, dropped data may ultimately result if the processing can not “catch up”. Therefore, for cases 2 and 3, if data is dropped, the algorithm has a reduced set of data to work on and it should be expected that the quality of the result is decreased. The fourth case is rarely possible in real-time systems. However, if the system did accommodate this, it is reasonable to assume that the additional processing is taken from another system task and the overall performance of the system is reduced due to that. The final case also implies a decrease in the quality of the result since a reduced algorithm was implemented.

Consider an example of an image inspection system, if throttling is implemented, the full algorithm is applied but the rate of inspection for the system is decreased and hence the performance of the product. If data is dropped, less frames are averaged and the quality of the image is reduced. I will assume additional processors can not be employed as this is an