Those heady days have been followed by years of sobriety, however. Today, increasingly, design teams are looking at highly integrated off-the-shelf ICs as a route to meeting their design goals. As one designer put it recently, "If there is a standard part out there that will do most of the job, you use it."

The resurgence of large, complex standard-product ICs has come about through a number of trends. One, certainly, has been the disappearance of the resources necessary to do an ASIC design. Another has been the increasing complexity and cost of any sort of chip design, but especially cell-based ASIC design. You have to take a good look at what's out there before you commit $20 million to developing a chip, especially if it might be 80 per cent duplicated by something you could buy for $20 in volume.

But another factor has been the proliferation of large, functionally rich off-the-shelf chips. There is still enough venture money out there that every major opportunity for a highly integrated product attracts a number of fabless semiconductor startups. In some cases, such as the network processor business or the 802.11 radio market, an opportunity creates far too great a flock of startups, driving chip prices to such levels that it makes no sense to design in-house.

Traditionally, standard-product ICs were general-purpose. There was no one particular application for a quad NAND gate or a 32-bit MIPS CPU, or, for that matter, an Ethernet controller. But as integration rises, the number of functions you put onto the chip goes up, and the chip necessarily becomes more specific to a particular application. Assemble some gates with a MIPS core, a lot of memory, some packet-inspection hardware and four Ethernet interfaces and you have a packet-processing engine, not a general-purpose IC. Hence analysts have coined the term application-specific standard product for chips in this category.

For our purposes, an ASSP is a highly integrated chip-typically containing processor, signal processing, memory, interface and specialized functional elements-that is so specific in its purpose that it is unlikely ever to be used outside the end application envisioned by the chip designers.

There are generally no additional tools, and usually even the hardware-dependent layer of software for the intended application comes with the chip, often for a moderate license fee. Unless the chip requires some sort of test instrumentation that the design team doesn't already have, there aren't really many other front-end costs.

The other significant component of standard-product cost is, of course, the price of the chip itself. Being a standard product, the chip will have its development cost amortized across all its customers. And since these ICs are usually designed with a cell-based methodology, sometimes with the addition of custom cells or hand-crafted analog blocks, the die size will be much smaller than that of a functionally equivalent FPGA, and quite possibly even smaller than that of a cell-based design the user could expect to do for himself.

Hence, only unique technology and the absence of alternatives could keep the off-the-shelf part from being considerably less expensive per unit than the alternatives.

Estimating this time in a project schedule can be quite tricky. It depends on the complexity of the ASSP, obviously, and on the quality of documentation and technical support. It also depends on the familiarity of the design team with the functions the chip performs, and on much less tangible factors: the similarity in nomenclature between chip vendor and design team, and how nearly the intended use of the chip matches the use that the designers had in mind.

Much of this getting-acquainted time will be spent on differences in assumptions between the chip and system design teams. And those differences will be discovered only during the design process. One of the costliest assumptions is that what I'm doing with the chip is exactly what the chip designers had in mind. It is important to realize that in some undocumented way it will be different.

But the intangibles are important, too. It is essential that the design team have the application knowledge to understand what the ASSP designers were trying to accomplish, and that they at least be able to pick up the vocabulary and thinking patterns of the chip designers. That will avoid any costly misunderstandings about the essential function of the chip.

Further, and even less easy to predict-except from experience-it is vital that the design team have a close working relationship with the ASSP vendor's support organization.

It is fairly easy to use a USB hub or an 8-bit microcontroller without close cooperation from the vendor: The functions are defined by standards or are transparently simple. That is not the case with a multimillion-gate, software-executing, highly configurable ASSP.

Another factor that has to be considered is the potential loss of differentiation. If you use an ASSP, so can a lower-cost competitor. The presence of an ASSP chip in an application area can have the effect of simply driving down the average selling price of products built from it.

To counter that, ASSPs are often used with customer-specific chips like smaller ASICs or FPGAs to provide differential advantages in either features or performance.

But this complicates the analysis by combining the lower costs and risks of a standard product with those of an ASIC or ASSP.

The rewards of adopting the ASSP approach are many: potentially much faster time-to-market, little initial investment, low unit costs and few risks. But those rewards are only valuable if there is sufficient differentiation elsewhere in the system-either in the overall architecture, in other modules or in other chips surrounding the ASSP-to prevent price competition from destroying the value of the design.