Configurable Application-Specific Signal Processors Speed Design and Development
USE OF EXTERNAL CHIPS
One decision in architecting a configurable ASSP is whether or not to tie it to specific external chips. Although there's nothing wrong with a chip set, going that route may restrict the range of designs that can use the configurable ASSP for two reasons. The first is cost. The second is flexibility: generally speaking, by requiring the configurable ASSP to be used in conjunction with other specific chips, we limit our flexibility to do exactly what we would need to do to design the product.
However, the use of external memory may not be an issue. DSPs with large internal RAMs tend to be quite expensive, so that it may actually be more cost-effective to use a DSP with a smaller RAM in conjunction with an inexpensive external RAM. Ideally, the design should allow us to select the type of external RAM. In doing so, the resulting configurable ASSP takes away little to no flexibility.
BOOTLOADING
Since a configurable ASSP is the combination of a general-purpose DSP and application-specific software, we need to get the software running on the DSP. This is accomplished by bootloading, which can be done a number of ways.
The simplest way is to program the DSP's ROM with the application program. The advantage is that the DSP is a stand-alone device that doesn't require external intervention in order to bootload. The biggest drawback is that ROM-enabled chips don't lend themselves to software upgrades. Also, not all DSPs have ROM on-chip, and those that do tend to require a significant investment and lead time for production.
Another way to boot a DSP is to have an external microcontroller download the DSP application via a parallel interface, such as a host port interface (HPI) or PCI. Two others are to boot from external memory or to boot via a serial port.
INTERFACE
A configurable ASSP generally needs two types of interface, control and real-time data.
The control interface sets up the configurable ASSP for the intended application both at system power-up and at run time. It tends be implemented by passing messages between an external controller and the DSP via shared memory or a host port interface. To simplify the interface, it's useful to provide an API to the host controller so that the details of the messaging can be abstracted using simpler function calls. That enables the programmer of the host controller to make C function calls to control the configurable ASSP and poll it for status.
The real-time data interface can operate via a number of ways including serial, video, USB, and Ethernet port, as well as through the same host port used for the control I/O.
Previous Page | Next Page
1 | 2 | 3 | 4 | 5 | 6
If you found this page useful, bookmark and share it on:
If you are familiar with RSS feeds, you can also sign up for our free blog feed. Our RSS feed is updated in real-time while our newsletter is updated daily.
