By today's standards, early microprocessor-based systems were simple, not least because they typically employed only a single processor (possibly with a few co-processors, such as a floating-point co-processor) with a relatively simple instruction set running at low clock frequency. This processor communicated with a small number of comparatively simple memory and peripheral devices by means of a single 8-bit or 16-bit data bus with a simple read/write and signaling protocol.
Those days have long gone. There is currently a tremendous growth in the development of systems that involve tens or hundreds of complex processors and hardware accelerators in closely coupled or networked topologies. In addition to tiered memory structures and multi-layer bus structures, these supersystems which may be executing hundreds of millions to tens of billions of instructions per second feature extremely complex software components, and this software content is currently increasing almost exponentially.
Aggressive competition makes today's electronics markets extremely sensitive to time-to-market pressures. This is especially true in consumer markets such as cell phones, where the opportunity for a new product to make an impact can sometimes be as little as two to four months. However, a recent report showed that more than 50 percent of embedded system developments run late, while 20 percent either fail to meet their requirements specifications or are cancelled in their entirety.1
The problem is that, in conventional system development environments, hardware design precedes software development. This sequential process simply cannot support the development of today's supersystems. This article first introduces examples of supersystems and outlines the problems presented by increasing system size and complexity.
The concept of architecture-driven design based on the use of virtual system prototypes (VSPs) is then discussed as a potential solution. Finally, a productivity, development time, and risk comparison is made between the back-end engineering resource loading associated with the conventional environment and the front-end loading resulting from the architecture-driven, VSP-based methodology.
In some respects, the term "supersystem" may be misleading, because it may cause some readers to imagine a physically large implementation. Actually, a supersystem is often realized on a single system-on-chip (SoC) device.
For example, a modern cell phone may contain an SoC comprising several general-purpose central processing units (CPUs), and one or two digital signal processing (DSP) units, controlling 40 or more peripheral devices providing control functions, multimedia functions, 2D and 3D graphics functions, crypto functions, camera interfaces, and a variety of other interfaces such as WiFi and USB.
The DSPs with associated accelerator devices provide a variety of base band processing, filtering, modulation, and decoding functions. Having multiple cores allows a broader range of processing traffic to be handled in real-time, which is a critical requirement for many of today's applications.
Moving away from the handheld portion of the wireless network, the base stations controlling wireless communications systems are themselves a hierarchy of closely-coupled multi-processor systems. For example, a typical base station capable of executing billions of instructions per second can comprise five to 20 major subsystems and more than 100 individual processors.
In addition to multiprocessor implementations, today's supersystems employ tiered memory structures. Some of the memory elements will be tightly coupled to individual processing engines by means of dedicated busses, other memory subsystems may be local to a cluster of processing engines, and yet other memory units may be shared between multiple groups of processing engines. Each of these memory subsystems may have different speed requirements, different bus widths, and use different clock domains.
In today's supersystems, different processing engines can have separate buses for control, instructions, and data, and each of these complex buses can feature a wide variety of structures and protocols. In addition to the general-purpose processor buses, there may be a variety of dedicated peripheral buses, tightly-coupled memory buses, external memory buses, and shared memory buses.
Many of these buses will feature pipelined structures with multiple transaction requests and responses scheduled in the pipeline. The bus system also may employ sophisticated cross-bar switches that can attempt multiple read and write operations simultaneously.
Even the average modern car contains from 20 to 80 processors performing a huge range of tasks and executing several hundred million to several billion instructions per second (Figure 1).
Figure 1 The electronics content of automobiles is growing at an ever-increasing rate2