Choosing the Right Central Logic Device for Your Portable Design
Finding the perfect balance of power consumption, size, functionality, flexibility and cost is no easy matter.
Most portable applications have a central logic device: field array programmable gate array (FPGA), digital signal processor (DSP) or microprocessor. Deciding the right device for your design is pivotal to the application capabilities and involves some important questions.
What options do you consider? Which factors are important? Some designers look at component count, form factor and future roadmaps of the device, while others are solely interested in system performance requirements and power consumption. At the same time, economic parameters such as non-recurring engineering (NRE) investment, BOM cost, time-to-market and project risk are equally important.
Another factor is the familiarity level of the design team with the chosen technology. In some cases, the design team may have a strong skill-set in FPGA systems and little DSP or microprocessor background, or vice-versa. In such cases, the design would benefit to include an FPGA in terms of time-to-market and project risk.
When designing a portable application, the tradeoffs that come with portability trump the tradeoffs between devices. So when designing a portable product, choosing the right device comes down to tweaking the perfect balance of power consumption, size, functionality, flexibility and cost. These tradeoffs are largely dependent on the application and have to be weighed on a per-project basis. There are no hard and fast rules to choosing a device, and the best way to get a better grasp of the process is through examples.
FPGAs in Portable Applications
FPGAs provide various options for designers to create custom logic/hardware for widely parallel, high computation rate algorithms. For applications that can be implemented with a lower cost off-the-shelf ASIC, having the flexibility of customization is a traditional advantage of using an FPGA. In one of Nuvation’s handheld global positioning system (GPS) designs, for example, two FPGAs were chosen to implement the varied functionality. One FPGA implemented an LCD controller, which offered a lower cost and higher refresh rate than an originally targeted off-the-shelf ASIC. This FPGA received pixel output from a microprocessor and wrote to a frame buffer in a SRAM. A second parallel process in the FPGA pulled data from the frame buffer and sent it to the LCD screen. Further into product development, we discovered we could improve the GPS RF quality by carefully tuning the frequency of the LCD refresh rate away from the GPS harmonics. This would not have been as simple without the FPGA solution.
In a portable design like a GPS unit with multiple controls and buttons, a device to handle disparate functions – all inside one chip – is extremely beneficial. The second FPGA in the handheld assumed the roles of the DRAM controller, keyboard controller, PWM for buzzer and partial power conditioner in addition to hosting various other bits of glue logic. Such functionality is best implemented with an FPGA.
In this example, the FPGA’s very low leakage power best met with the product's low power requirements. As a handheld device, it had to provide power for a full working day of heavy GPS and datalogging functionality on a single charge.
Usage of the programmable logic provided several engineering methodology advantages. It accelerated schematic capture by allowing the board designer to route various digital logic to the FPGA and then write the FPGA code while the board was in layout, fab and assembly. If previous discrete digital logic was used, this engineering design would have been required to be completed prior to release to layout. Further, it was determined early on that the efficiency of the DRAM controller would be a combination of engineering effort. An early release of the DRAM controller used three wait states and enabled a rapid release for integration with an overseas software team. While the unit was being shipped, a faster 0 wait state design was coded, and the new, faster hardware was e-mailed to the remote software team.
While the unit was in overseas integration, a high pinout connector was used to hook to an emulator. The connector was only intended for development and was somewhat fragile. Unexpectedly, one of the memory connector traces broke during software integration. Rather than send the hardware back for repair, or try to coach the software team to repair it remotely, we worked out a development patch in the FPGA DRAM controller that rerouted requests to an area of memory that was still properly connected.
So using FPGAs provided not only lower cost, lower power and higher functionality, but it also accelerated the development schedule and increased product flexibility. That increased flexibility allowed us to "e-mail" new hardware to an overseas software team and saved at least one board spin, ultimately protecting the product’s scheduled release date.
Splitting the functionality between two FPGAs also allowed for more flexibility in subsequent upgrades and revisions. A study of the situation achieved further cost savings by combining the two FPGAs into a single, larger FPGA as the second generation of the product. This allowed for a controlled, risk-free growth of the product roadmap.
DSPs in Portable Applications
The core of a DSP is designed to optimally execute signal processing algorithms for which the principle operation (multiply-and-accumulate) is similar. Similar to microcontrollers (MCU), DSPs are packaged with many peripherals and different types of memory in the same device. In a sense, DSPs concurrently offer all flexibilities and functionalities offered by most MCUs in addition to being optimal for signal processing applications for low and medium performance applications. Therefore, DSPs are the device of choice for system architects for a large range of applications given the combination of MCU functionality, optimal signal processing and bundled on-chip peripherals in the same package.
An example here would be a portable voice-playback application. In that project, a DSP was optimal for power, cost and functionality. FPGAs lacked the needed integrated ADCs (analog to digital converters) and DACs (digital to analog converters) internally, and developers achieved that functionality through a DSP instead. The device selected for portable voice-playback also needed to be capable of being upgraded to newer voice codecs over time. An arbitrarily configurable FPGA may have provided more flexibility; however, Nuvation reduced significant development time by selecting Texas Instruments’ TMS320C54x DSP with integrated signal processing functionality. The DSP had some limitations on I/O options, which resulted in some extra design work. However, due to the portability of the application, the very low power dissipation of this particular DSP outweighed the device I/O complexity.
As designers move from developing plugged-in products to creating truly portable applications, they will need processors that can provide lower power, higher performance and even high precision floating-point capabilities. TI's newest low power DSPs and applications processors, for example, offer systems designers a broad range of low power processors to meet the growing shift in the marketplace for not only more battery life but also maintaining the same if not higher performance.
DSP & Microprocessor Application Example:
Nuvation IP Camera PoE Reference Design
Figure 1: Nuvation IP camera reference design
With the growth of video surveillance, machine vision and video teleconferencing, Nuvation recently released a low-cost IP camera PoE (power over ethernet) reference design, the newest addition to our video product line. This design allows Nuvation clients to achieve rapid time-to-market with minimum NRE, while allowing modification of the design to customize it for a specific target application. Nuvation provides the following specifications for the Nuvation IP camera reference design (Figure 1):
- Small Form Factor IP Camera
- Power over Ethernet
- Standard optics (CS Mount) with wide dynamic range (WDR) imaging
- Low power with PoE support
- Low BOM cost
- DFM/DFx including RoHS compliance and obsolescence risk mitigation
- Full embedded Linux, real-time
- TCP/IP and/or analog video output
- H.264, MPEG-4, MJPEG encoder flexibility, up to D1 at 30 fps
- Support for custom or licensed video analytics software
- Field programmable
Nuvation engineers chose TI’s TMS320DM6446 digital media processor in response from success in previous designs. This device, which is based on DaVinci technology, is a high performance system-on-chip (SoC) targeted at high-end video applications. This dual processor device contains a TMS320C64x+ DSP core for accelerated video processing and an ARM9 microprocessor core for co-processing tasks and peripheral management.
The DM6446 DSP is the principal device in the IP Camera PoE reference design and is responsible for acquiring video data, encoding it into the desired format and outputting it via Ethernet and TCP/IP. As a dual processor device, the DM6446 processor allows designers the flexibility of implementing the signal processing algorithms in the C64x+ DSP core while simultaneously executing various other tasks such as packet assembly for streaming media and peripheral management in the ARM9 microcontroller core, offering developers the best of both worlds.
Another benefit of using the DM6446 DSP is the existing Linux distribution for ARM9 microprocessor, which provides system designers to take advantage of the existing firmware in the open source community and quick integration of third party libraries. Ethernet ports, video ports and the DM6446’s small footprint and affordable power consumption were some other deciding factors for choosing this device for the Nuvation IP Camera PoE reference design. In brief, the DM6446 DSP made it possible to meet all outlined design requirements while minimizing the NRE costs.
As we have seen in our projects, selecting an appropriate central logic device for a portable application is determined by the unique set of requirements for each specific project. The choice between an FPGA and DSP depends on many parameters including power, cost, size, flexibility, NRE, time-to-market and functionality. An exact formula does not exist because it is a question of tradeoffs. Understanding these tradeoffs can guide a designer to choose a platform that best suits a specific system for performance, BOM cost and risk. In this article, we highlighted design examples with unique requirements and discussed which kind of device was best suited for the job. We hope you can use our experience to develop your own method to analyzing requirements, prioritizing parameters, weighing tradeoffs and choosing the appropriate device for your design.
Nuvation Research Corp.
San Jose, California
This article originally appeared in the August, 2008 issue of Portable Design. Reprinted with permission.