An increasing amount of system-on-chip design activity today seems to target field-programmable gate arrays (FPGAs) rather than application-specific ICs. Often this is simply an intermediate target to produce a hardware verification platform or software development prototypes. Or it may be for production: Not many forecasts right now can justify a million dollars in nonrecurring-engineering charges for an ASIC.

Nominally, FPGAs are large enough to contain an entire system-level design. But in practice, designs usually will have to be partitioned among several FPGAs. The really big parts are still stunningly expensive, unless your name has Cisco in it. Several smaller devices can be cheaper than one big one. And you will need some external components anyway, unless you happen to be integrating a subsystem that has no microprocessor or DRAM.

But integrating a system into several FPGAs can create an interesting partitioning problem. In a purely microprocessor-centric design this may not be a big issue, because the entire system may naturally organize itself into peripheral blocks on the MPU bus, and the mapping to a couple of bus-connected FPGAs may be obvious. But in less centralized systems the partitioning problem can be quite a perplexing one.

These days FPGAs, particularly the large ones, have lots of I/O, so in theory they should be relatively insensitive to partitioning decisions. Yes, an interchip path will have more delay and more skew than an on-chip path, and may not be handled gracefully by the design tools. But wait, as they say, there's more.

As independent FPGA guru Mike Dini pointed out in a presentation at the recent SoC Online conference, those big ball-grid array packages with huge numbers of pins come with their own issues. It can be nearly impossible to route to all those sites on the circuit board. Folks at one system vendor with whom I spoke recently described having to go to a 16-layer circuit board with more than 700-Gbit/second-class traces to accommodate the big BGAs. "The circuit designers had to sit with the pcb layout folks for weeks," they said.

But there's an alternative. Courtesy of the mostly defunct networking business, most of those big new FPGAs also have high-speed serial I/O pins and on-chip serdes blocks. So with a little planning, buffering and attention to latency requirements, it may be possible to implement most or all of the interconnect between FPGAs with a few low-voltage differential-signaling pins. That not only saves active pins and avoids routing nightmares, but it can save a great deal of power.

http://www.eet.com/