Until recently, this memory would have been mainly in one large array: a big cache, a frame buffer or a big scratchpad. But increasingly, the memory is broken into much smaller pieces. It's scattered around on the die so that it is adjacent to the functional blocks that need it, and organized not as simple SRAM, but in any number of more specialized configurations.

While this creates a lot of labor for SoC designers using ASIC or COT flows, it is not a huge technical problem yet. Designing and placing lots of specialized blocks kind of plays to the strength of current chip design methodologies. There are some emerging issues, such as efficient manufacturing test and soft-error resistance, but for most designers they are not major issues yet.

The picture changes considerably when you look not at ASIC or COT flows, but at an FPGA design flow. The proliferation of specialty memory blocks strikes at a major weakness of FPGAs -- namely, their inability to predict how much of a given resource you will want where on the die.

When FPGAs were much smaller and large, or fast memories were implemented as external chips, this wasn't an issue. Most vendors provided means of converting a logic cell into a rather ad hoc SRAM. These could be grouped together using the ordinary programmable interconnect to form flexible, if quite slow, memory arrays.

The inadequacy of these became apparent as FPGAs moved up into the size where it was necessary to incorporate relatively high-performance memory arrays on the chip. In response, FPGA architectures evolved dedicated small blocks of SRAM scattered around on the die. These were usually surrounded by a certain amount of dedicated configuration logic, so that a given array could be set up as a single-port or dual-port in a variety of widths and depths without putting the slow programmable logic cells in the data or address paths.

But the inevitable rule of not-fully-configurable things is that you never get exactly what you want just where you want it. Getting good utilization out of the pre-defined blocks was a matter of luck. And assembling the small RAM blocks into larger blocks or into unanticipated configurations resulted in plummeting performance.

The most recent attempt to overcome this problem is Altera's new FPGA family. This design provides not only the usual scattering of small and medium-sized configurable RAM blocks, but also one or more quite large blocks placed strategically on the chip. The notion, of course, is that if there are enough entrees on the table you can satisfy nearly everyone. But the fixed placement of the large RAM blocks and the discrete nature of the smaller ones will still leave the user with some very interesting placement and routing problems, with which automatic software can be only so helpful.

A different approach is suggested by the platform-based design enthusiasts. For a given class of applications, it ought to be possible to plan the system's memory requirements quite accurately -- not only in terms of size and function, but in location in the chip's floorplan. If it's not possible to please everyone with a single family of chips with a single floorplan, it might just be possible to delight everyone within a certain application category with a single, application-specific floorplan based on a general agreement about dataflow.

This notion may presume the existence of either gurus or tools that can turn a detailed dataflow diagram into a clear set of memory requirements and a relatively accurate floorplan, even before the details of the functional block implementation is known. But that may prove to be a solvable problem.

Ron Wilson is editorial director of ISD Magazine and a contributor to EE Times. He has covered chip-related matters for 15 years for various industry publications, and was once, in the distant past, a designer himself.