|
Editor's Note: This three-part article is abstracted from Chapter 7 of the book Embedded Hardware Know It All with the kind permission of the publisher.
See also Part 1.
The book features a "360 degree" view from best-selling authors Jack Ganssle, Tammy Noergaard, Fred Eady, Lewin Edwards, David J. Katz, Rick Gentile, Ken Arnold, Kamal Hyder, Bob Perrin, and Creed Huddleston.
The Newnes "Know It All" series takes the best of what their authors have written over the past few years and creates a one-stop reference for engineers involved in markets from communications to embedded systems and everywhere in-between.
Embedded Hardware Know It All provides: "The ultimate hard-working desk reference with all the essential information, techniques, and tricks of the trade in one volume."
Building custom peripherals with FPGAs
While you are evaluating different chips for your application, you are likely to find yourself tempted by specialized system-on-chip devices offered by various manufacturers. These chips will have interesting peripherals specific to various applications – for example, dedicated motion compensation and colorspace conversion hardware for digital video playback or discrete cosine transform (DCT) engines for image compression, typical in devices intended for the digital camera market. Unfortunately, these are usually precisely the sorts of devices that are unobtainable to the hobbyist or small-scale developer. They are usually only available with solid, up-front quantity commitments, and often nondisclosure agreements are also required. In some cases, just to view the data sheet for a part, you will need to pay large fees to join some kind of specialized industry cartel. (DVD/DVB playback hardware can be like this, for instance, because of the numerous patents in the field and vested copyright interests at stake.)
Because of this annoying fact, one of the most useful money-saving skills you can acquire is experience working with synthesizable hardware design language (HDL) code on CPLDs and FPGAs. Using such devices, you can design your own custom peripherals, optimized for your specific application, and avoid the trouble of trying to source a rare ASSP. FPGAs are available off-the-shelf in many different packages and complexities, and in many cases the manufacturers supply free development tools.
In fact, there are now products available, such as Altera's Nios and Excalibur devices, which consist of a high-performance RISC core "wrapped" in an FPGA, all on the one chip. Nios is a proprietary microcontroller core; Excalibur is built around a high-performance ARM922T core. With a part like this, you can effectively create your own custom ASIC; it is an extremely powerful tool and it seems likely that we can expect to see many more such devices in the future. ARM and other vendors also supply some cores in soft form, so you could in theory build your own entirely customized system-on-chip using a generic FPGA device. However, because of the hefty licensing fees involved, the per-unit breakeven point is only reachable with very large production volumes.
If you plan to use FPGAs, much as with microcontrollers you will find that the manufacturer recommended evaluation boards and commercial development tools can be very expensive.
Trenz electronic (www.trenz-electronic.de) is one possible source of lower-cost FPGA boards. However, you might not even need an evaluation board – FPGAs are, after all, fi eld-programmable, and the interior functionality is controlled by the firmware you upload to them, so you can be fairly confident about dropping an FPGA directly onto a first-run prototype PCB and debugging your design in-circuit. If you've never used FPGAs before, however, I would advise getting a small evaluation board with which to experiment. Connect the I/O lines to pushbuttons, LEDs, or perhaps an RS232C level-matching IC like the Maxim MAX232A and play with the device to see what you can achieve with it.
Since I'm talking about field-programmable logic, I should also mention Opencores (www.opencores.org), an invaluable resource of free, open source intellectual property ready to be compiled into your FPGA. If you need a core of some sort – a UART, for example, or a DRAM controller – then before starting to write your own, you should visit Opencores to see if there is already a free core available for you to adapt. Opencores is something like the Linux of hardware; at the time of writing, there are free cores for SDRAM controllers, UARTs, cryptographic hardware, microcontrollers, a VGA/LCD controller and many others.
Whose development hardware to use – chicken or egg?
The textbook development cycle recommended by chip vendors is as follows:
- Choose a microcontroller from the vendor's selection matrix.
- Buy the vendor's evaluation board for this part.
- Buy one of the commercial compilers and possibly a hardware debugging module
recommended for the evaluation board.
- License one of the operating systems recommended for the evaluation board.
- Develop your application in vitro on the evaluation board.
- Develop your hardware.
- Port the operating system and your known-good application to the real hardware.
One of the driving ideas behind this methodology is that the software team doesn't have to wait for the hardware team to finish designing and debugging the circuit. Unfortunately, as with most textbook descriptions, the cycle described above ignores some important realities, not the least of which is that in many small shops, the job of both the software and hardware "teams" will be performed by a single person.
The evaluation board and software tools recommended by the chip manufacturer are usually expensive, for reasons touched upon in the introduction to this book. Additionally, if you intend to use complex off-chip functionality, it can be extremely difficult to attach this to an evaluation board. For instance, if you intend to implement a PCMCIA socket in your appliance and the microcontroller evaluation board doesn't include one as an option, it could be hard to hand-build a PCMCIA interface board and harder still to graft it onto the evaluation board. The majority of 32-bit parts are quite closely targeted at specific applications; evaluation boards tend to have all the hardware required to demonstrate the maximum possible bells-and-whistles configuration of the CPU's intended application, and this can get in the way of adding your own peripherals to the evaluation board. For example, I was once evaluating a chip targeted at the PDA market. The appliance I intended to build wasn't a PDA, so I didn't need most of the hardware on the evaluation board – audio I/O, Ethernet, color LCD, touch screen, USB interface, etc. Not only did I have to pay for all these peripherals (this particular evaluation board is US$1500, and the microcontroller itself only costs about US$12), but I had to cut several dozen traces, remove a 160-pin surface-mounted chip, and add literally a couple of hundred patch wires in order to be able to bolt on my own peripherals.
Finally, and following on rather neatly from that anecdote, you should remember that the time required to understand the memory map and any special quirks of the evaluation board, and to get its specific combination of hardware running, is time that you are "stealing" from the task of getting your own circuit debugged. This is an acceptable price when you have a large team working simultaneously on the hardware and firmware of the final product, but in a smaller or even one-person environment working on a tight time budget, it is often more efficient to design your own circuit and start working directly on your own hardware.
There are three major ways around these problems, in roughly increasing order of difficulty:
- Locate a third-party demonstration platform for the part of interest.
- Locate a consumer appliance based on the chip that interests you and reverse-engineer it enough to load your own firmware and patch on your own hardware.
- Design your own PCB and have it etched and populated either locally or (if this is a commercial project) by your factory; develop your firmware on this board while debugging the hardware at the same time.
|
