For decades, many embedded designs used separate processors for handling the signal and control processing. Part of the reason for using separate and different types of processors is that the data and processing characteristics of control and signal processing are different enough to warrant different implementations. Control processing is characterized by frequent context switches as the control software must handle different asynchronous events so as to minimize the latency between when an event occurs and when the controller responds to that event. Microcontroller architectures that specialize in control processing usually include circuitry that enables them to detect and respond to interrupts quickly and deterministically.
In contrast, signal processing is characterized by very few context switches. Rather, signal processing exhibits relatively repetitive and predictable processing – however, the amount of computing that must be performed at each data point is usually substantial and overloads traditional microcontroller architectures. Signal processing architectures trade-off efficient context switching for efficient loop processing via special loop instructions and data handling via additional buses.
Because controllers and signal processors differ so much at the architectural level, the skills required to program them are different and the tools to develop with them are different. Managing two different processors simplifies partitioning the processing tasks, but it also increases the complexity of integrating between the two processing systems for the design team.
Within the last decade, a hybrid processing architecture emerged that combined control and signal processing into a single instruction stream. The most recently used label for such processors is digital signal controllers (DSC) which acknowledges its combined architectural trade-offs. DSCs are able to perform context switching like a microcontroller, but they are also able to process light weight signal processing tasks better than a microcontroller. However, they are not capable of handling heavy-lifting signal processing as well as dedicated signal processing architectures.
Hybrid architectures and the development tools to work with them have matured. Hybrid architectures allow a development team to use the same processor architecture throughout each part of the design which supports using the same instruction set and same development tools. However, the interface between the controller and signal processing tasks is limited to the architectural trade-offs that the processor architect made. If the trade-offs that were made match the needs for the project it is being used in, then all is well, but any mismatch will affect the development team’s implementation options.
When is using the single instruction stream benefit of a DSC or hybrid architecture better than using the multiple instruction stream approach of multiple and different types of processors in a design? Have you made this trade-off decision with any of your designs? When did you choose one over the other and why?
Processor Tracker
All Entries RSS Feed
I think MCU applications are so defined right now, that semiconductor vendors are putting out devices very adequately tailored to them. This, in turn, pushes design choices to those devices. Example: very small and low cost DSCs are available now to perform control functions and very little of anything else (for example, communications, maybe some buttons and lower priority comms to ASICs via IIC or SPI). Why? This makes sense in motor control, where power domains are a concern and having an apps processor do the control and other functions may pose a big hardware layout challenge. There is also the problem of distributed processing over a bigger area. In this case, a main processor with several “control slaves” is the norm, this is why smaller DSCs will frequently include CAN and UART communications interfaces.
On the other hand, there are control or signal processing applications that do not have this distributed or power domain problem like controlling smaller motors, audio applications, valve control, etc. In this case bigger DSCs are a good choice, but there is also the trend of turning MCU into almost-DSC devices. A great example: the Cortex M4 core. This is an ARM microcontroller core that can easily handle an RTOS but will also do real-time processing with DSP instructions, while outputting a stream of data through the Ethernet port. It is not entirely a DSC as it lacks some of the thing that make it a “formal” DSP core, but it does have the DSP instructions, easing the big signal processing problem to a great degree.
This is exactly what we’re examining for our current project. We previously separated DSP and microcontroller, and are looking to combine them for increased power efficiency and overall simplicity of board architecture.
The questions for us will be around the cost/benefits of combining the two, partitioning our DSP software architecture so that it can be pre-empted by the RTOS for device context switches in support of UI and I/O. Our DSP previously used power management to go to sleep when not in action; we will need to do some benchmarking to compare the results when folding that functionality into an DSC.
TI and Freescale have some families that combine DSP with a context-driven CPU, sometimes using floating point co-processor, sometimes not.
It is really depends on how sophistic of the project is. We have been designed products with DSP + microcontroller, but when more features are added to the project and more processing speed is required, it couldn’t be handled by this architect, so we have to go to FPGA to do signal processing and microcontroller to do management.
It is good to have RTOS used in MC, especially for multi-channel I/O management. RTOS could minimize totally response time for each channel, it is better than a big loop. The big loop MC code is only good for very simple system.