Altera Excalibur: Altera doesn't try to hide the fact that its Excalibur is a large programmable logic device (PLD)—up to 1 million gates—with some fixed components tacked on one side of the array (Fig. 6). Of course, this doesn't detract from the fact that the processor is a 200-MIPS ARM9. It includes ARM's trace support plus a JTAG interface for debugging. The ARM9 works with the ARMv4T instruction set, including the 16-bit Thumb extensions. The processor has 8-kbyte data and code caches and an MMU.
Some other fixed components are a UART and some timers, an interrupt controller, and an external memory interface that supports flash, SRAM, and DDR SDRAM. Just add some flash memory to get this system up and running.
One interesting aspect of the design is a mixture of dual-port and single-port RAM. They're linked to the AMBA bus to the processor. The second port of the dual-port RAM is dedicated to the PLD.
Take The Plunge: One great thing about reconfigurable SoCs is that it doesn't cost a bundle to try them out. Developer kits often run a few hundred dollars. They let complete designs be implemented and tested on boards that come with the kit.
I have worked with a number of these kits, and they're relatively easy to use. The major investment is the time it takes to learn what peripherals are available and how they're selected, placed, and configured. Simple peripheral configurations are easy, but more complex configurations take a while to design and debug.
Learning about the core processor and fixed peripherals isn't a quick process either. Many designers will already have expertise on standard processor cores like the 8051 or ARM found in some reconfigurable SoCs. Others will employ custom CPU architectures, so a C or C++ compiler will have to be available to hide the architecture from developers. Otherwise, additional time will be needed to learn the architecture and its idiosyncrasies.
Development kits enable a designer to be up and running within a day. Relatively sophisticated systems can start operating within a week. This permits more time for application development versus the fine tuning of a hardware design that must then be committed to a custom SoC.
Reconfigurable SoCs can be more complex to use than custom or standard SoCs if dynamic runtime reconfiguration is used, as noted earlier with the MP3 player/recorder example. Care must be taken when reconfiguring the system. Outputs must be controlled properly and other parts of the programmable matrix have to be retained, assuming that only part of the system changes at once. Usually, the development tools simplify this chore. But changing hardware can lead to some interesting debugging problems that wouldn't occur in a fixed-hardware environment.
Usually, the matter of implementing reconfigurable SoCs boils down to the price of the chip. This cost can be easily compared to custom and standard SoC alternatives, as well as the option of using a standard microcontroller with external peripherals or an FPGA to employ the necessary custom logic. While the costs may not be justified for large-scale production runs in the millions, reconfigurable SoCs fare well in limited production runs, prototyping, or beta testing.
Keep in mind that configurable SoCs can also provide an upgrade path. Many system designs won't use 100% of the configurable logic, so new hardware-based features can be added in the future by making use of unused reconfigurable logic. Alternatively, lower-cost versions of a reconfigurable chip with just enough memory and peripheral logic can be used in production if they are available.