Nick is chief scientist at Altera and can be contacted at nickt@altera.com.
With the invention of the integrated circuit, TTL (transistor-transistor logic) displaced the transistor in embedded-system designs because TTL components increased the designer's efficiency. Similarly, in the 1980s, microprocessors began displacing TTL. In the coming years, however, microprocessors themselves will be displaced by programmable-logic devices (PLDs) in many embedded-system designs. From both a hardware and software perspective, this transition will have significant impact on the design and implementation of embedded systems, and designers need to prepare for this inevitable change. To determine when this transition will occur, it's useful to examine the development of the microprocessor itself.
Figure 1 illustrates the conceptual design difference between TTL and a microprocessor. TTL designs use a catalog of TTL macro functions. The state sequencer and data unit are wired directly into the implementation.
A microprocessor system, on the other hand, implements a standard design, such as that illustrated on the right side of Figure 1, and implements the algorithm in a program in memory. Figure 2 illustrates the conceptual mapping of the application into a microprocessor design. The algorithm must take into account the instruction set of the microprocessor (it wouldn't do to pick an algorithm which depended heavily on floating-point instructions if the microprocessor didn't implement them). The algorithm is then mapped into a high-level language (HLL). The HLL description of the algorithm is translated to object code by a compiler. The compiler must have access to the computer architecture to know what binary codes to generate for the high-level language instructions. The object code implementing the algorithm runs on the computer to manipulate the data and produce a result.
This introduces considerable complexity in the conceptual model of the implementation. In TTL implementations, the state sequencer and the data unit are fixed in the hardware. This gives low cost and excellent performance for a single application. In microprocessor implementations, the state sequencer is a program driving a general-purpose data unit. This gives low cost and adequate performance for a broad range of applications. Improvements in process technology have led to a proliferation of TTL components. A TTL catalog contains hundreds of part types (corresponding to hard macro functions available to the designer). Individual TTL-style designs are customized for individual applications. As the TTL parts catalog grew, system manufacturers were forced to stock an increasing variety of TTL components. Those same improvements in process technology led to the development of the microprocessor. Instead of a custom design of selected TTL parts, the microprocessor design consisted of a smaller variety of standard components: microprocessor, memory, and I/O components. A single, basic design could be used for a large variety of applications by changing the program in memory. Since the microprocessor and its associated components could be used in a range of designs, the microprocessor attained high-production volume, leading to low cost--a basic requirement for embedded-control applications.
Simple designs, such as those in consumer appliances, drive the vast majority of component sales. For these designs, problem size is small and performance isn't an issue. Cost is the driving issue. Figure 3 illustrates my guess for the position of the bubble representing the majority of component dollars in the performance and problem-size domain. Most of the volume in the four-billion-unit microprocessor market lies in the overlap between the "Zillions of Component Dollars" and the "Embedded Microprocessor" bubbles.
In the zillions-of-component-dollars bubble in Figure 3, PLDs compete with TTL and microprocessor designs. At the very low end of the problem-size and performance scale, process improvements benefit PLDs, but TTL devices are stalled for cost and performance improvement as they become pad limited. Programmable logic offers the same performance and component cost, but there are fewer component types to stock and fewer components in the final design.
As Figure 4 shows, PLDs offer a more-direct solution than microprocessors for some applications. Fewer components means a cheaper, more-reliable design. The same process-technology improvements driving the expansion of the embedded-microprocessor bubble drive improvements in programmable-logic devices.
Figure 5 is the conceptual view of PLD implementation. The PLD implementation is less direct than the TTL and transistor implementation of Figure 6 and more direct than the microprocessor implementation in Figure 2. The application is mapped to an algorithm which is compiled directly into a processor design.
Because there is a compiler in the design process, components fit a large range of applications, which drives down component cost. The PLD design has the same advantages over the microprocessor design that the microprocessor-based design had over the direct implementation--it is cheaper, uses fewer components, and is more reliable. As Figure 7 illustrates, PLDs occupy the lower-left corner of the performance and problem-size domain, somewhere directly underneath the zillions-of-component-dollars bubble, guaranteeing them gigantic volumes necessary to drive process improvements in the technology. As process technology improves, the PLD bubble expands away from the origin, encroaching on the TTL domain and the embedded-microprocessor bubble.
What's needed for rapid expansion of the PLD application bubble in Figure 7 is a compelling development environment that includes sophisticated compilers (see the compiler bubble in Figure 5). Will that happen?
As much as we would like to believe otherwise, our industry isn't driven solely by logic. Like the fashion, toy, and other pop industries, high-tech is swept by fads, too. Fads determine how press attention, R&D dollars, and individual enthusiasm are channeled. Dollars and enthusiasm drive the industry forward. Press attention complicates the process by creating a feedback loop. Predicting the future for programmable logic in the presence of this feedback loop is dangerous. But we have been in the midst of a similar development cycle for the microprocessor since 1971. An analogy with the history of microprocessor development should help us predict what will happen in the programmable-logic industry.
The history of the microprocessor hasn't been completely rewritten yet, so I'll give a rendition that suits my purposes. The microprocessor was invented for embedded control. The first commercial microprocessor, introduced by Intel in 1971, was derived from a calculator design. The original design proposal called for seven custom chips to implement a calculator. Ted Hoff countered with a four-chip proposal, the central component of which was the precursor to today's microprocessor.
Even though computers used a microprocessor as the CPU much earlier, the introduction of the IBM PC in 1981 clearly split microprocessor applications into two categories: embedded control and CPU. In about 1982, the RISC fad began, and further split the CPU branch of the taxonomy into CPUs for PCs and CPUs for workstations and other computers.
Today, the total microprocessor market should be about four billion units. Almost four billion of those microprocessors will end up in embedded-control applications. About 50 million microprocessors will become the CPU in a computer system. Almost all of those 50 million microprocessors will become the CPU in a PC. Fewer than one million microprocessors will become the CPU in a workstation or other computer. Microprocessors used as the CPU in a computer system, therefore, represent less than 2 percent of the unit volume. Microprocessors used as the CPU in a workstation or other computer, excluding the lowly PC, represent less than 2 percent of the CPU unit volume, making them an almost invisible percentage of the total microprocessor unit volume.
Computers solve very large problems for which a direct TTL solution is not practical. The computer has two cost-reducing advantages: Its hardware can be multiplexed (that is, it can iterate to solve a problem), and the same hardware can be shared across many applications. As performance requirements increase, however, computers lose ground. In these cases, a TTL solution may be possible, but prohibitively expensive.
Zillions of research dollars will be spent on process development, which benefits PLDs, computers, and microprocessors, but not TTL. Many dollars will also be spent on computer development, which includes the development of high-end microprocessors. A lot of the money will be spent on microprocessor development, so performance will improve, but microprocessors are facing a barrier because the new superscalar designs are able to exploit the available parallelism in the instruction stream. Future microprocessors may be able to issue six or eight instructions per clock tick, but existing code contains a branch about every five instructions. Address and data dependencies (an operand or address for the current instruction is calculated in a preceding instruction) further reduce available parallelism. Additional improvements in the microprocessor will not return much additional performance for the research investment. Instruction execution is the bottleneck. Researchers are studying exotic alternatives to superscalar microprocessors, such as very long instruction word (VLIW) processors and parallel processors.
Meanwhile, in the PC marketplace, operating systems and applications grow more sophisticated. The operating system increasingly isolates the applications from the underlying hardware. Applications no longer directly manipulate system resources and instead, simply request services from the operating system. This leads to the system model in Figure 8, with applications talking to the operating system and the operating system talking to the hardware.
Since instruction execution on the microprocessor is a major bottleneck in the system, it has led to the development of application accelerators, as in Figure 8. These application accelerators intercept service calls from the applications and execute the function directly, avoiding low-level instruction execution on the processor. There are, for example, Windows accelerators for the PC from about 100 manufacturers. Likewise, there are accelerators for Adobe Photoshop and other applications. The effort to improve performance by avoiding instruction execution could lead to a proliferation of custom accelerator cards. A PLD-based accelerator card, however, could be configured to accelerate Windows and then reprogrammed to accelerate Photoshop or AutoCAD. Eventually, this reconfigurable hardware could migrate onto the microprocessor itself, intercepting and directly executing high-level function calls between applications and the operating system.
If their development follows the same path as microprocessors, PLDs have great potential for long-term growth. The microprocessor has had outstanding long-term growth because gigantic volumes at the low end continuously reduce cost, while at the high end, process and component R&D ensure the future.
PLDs can expect to achieve the gigantic volumes at the low end necessary to continuously reduce cost because they are a superior solution to TTL and embedded microprocessors in regions where they compete. Many R&D dollars will be spent on reconfigurable hardware, which is based on PLDs. I predict PLDs will grow at the expense of both TTL and the microprocessor and will also absorb the growth in system complexity.
Figure 1: For some designs, microprocessors offer a more efficient solution than TTL.
Figure 2: Mapping an application into a microprocessor.
Figure 3: The low end of problem size and performance is the largest component market.
Figure 4: The PLD is a more-direct solution to some design problems than a microprocessor.
Figure 5: Mapping an application into a PLD.
Figure 6: Mapping an application into hardware using TTL or transistors.
Figure 7: Low-end PLD applications expand as the underlying technology improves.
Figure 8: Application accelerators intercept service requests to avoid instruction execution.
Copyright © 1995, Dr. Dobb's Journal