•  
• EDN Europe MAGAZINE
•  
• Free SUBSCRIPTION
• Subscription Renewal
• View Media Kit

• EDN
• EDN Australia
• EDN Asia
• EDN China
• EDN Japan

The Prototype Comes of Age

A radical change is about to happen in the typical development of an electronic system. The hardwaredevelopment flow will no longer be the center around which everything else revolves.

AT A GLANCE

Hardware and software developers, architects, and verification teams all need system models. Using the hardware-implementation model for multiple purposes may be unfeasible because it requires designers to make too many compromises. Prototypes can exist before, during, or after the development of the hardware-implementation model at the virtual, the rapid prototyping and emulation, and the silicon levels, respectively. Successful deployment of a prototype must consider the costs, usage scenarios, team skills, and many other factors.

Over the past few years, interest in prototyping electronic designs has grown. The rising size and complexity of systems and the limitations of using a single-purpose model—the hardware-design model— have fueled this growth. Engineers have traditionally modeled the hardware-design model at the RTL (register-transfer level) and then performed a number of refinement steps until that model becomes the implementation model. This single-purpose model has in the past found use only in hardware design, although engineers are now considering its use for other purposes. The EDA industry has developed tools, such as equivalence checkers, to ensure that the functionality of this evolving model stays consistent during these transformations. In an ideal world, all modifications would apply to the single model at the start of the chain, and changes would propagate throughout the chain. In the real world, however, engineers make changes to the subsequently derived models, potentially leading to departures between the original high-level model and the final implementation. This area has always been regarded as a risk in the development cycle, and that risk increases as additional independent models are generated throughout the flow.

The single hardware-design model can no longer provide all of the functions users demand. The rapid increase in software content means that its development, debugging, and integration cannot be left until first silicon comes back from the fab. The RTL model is too slow for the effective performance of these tasks because it contains implementation details that software execution does not require. Engineers have used emulation to speed the RTL model, but this approach is still too slow, and it is often too expensive for manufacturers to make available to software-development teams. Engineers need faster and cheaper prototypes that are available much earlier in the design flow.

Time for change

Among the changes now taking place in this area is the migration to higher levels of abstraction for hardware design. Driving this change is a desire for increased productivity in the hardware that provides unique value in a product. The ability to derive several implementations from a single highlevel description is also desirable. Once you develop this block at an abstract level and verify it, you can then use it to generate several microarchitectures or target implementation technologies, each with characteristics such as low power or small size. High-level synthesis is helping in this area. As a by-product of high-level synthesis, verification teams have discovered that their process can become more efficient when they use abstract models. As systems become more concurrent, it is no longer possible to analyze the throughput, latency, or other aspects of a system architecture using static methods, so the role of verification is also increasing to include system-level concepts.

Another change affecting hardwareand software-development teams is that more functionality is being provided by reuse—either internal or acquired from third parties. The size, sophistication, and number of these blocks are increasing, and the verification approach for these blocks differs from the approaches you would use for new blocks. Many hardware blocks now come with sophisticated software stacks, and they also must be integrated into the software flow. These changes have led many development teams to the conclusion that they must develop additional models to enable aspects of a system’s design or verification to be performed that are not on the hardware-development path. This new approach in turn signals a radical change in the make-up of a development team. Hardware development is no longer the central hub around which everything else revolves. Instead, the system becomes the focus, and hardware development becomes one of the contributors. The prototype becomes the way in which contributors share information.

Roles of a prototype

The first step in choosing a prototype is to understand the needs and expectations associated with the prototype. Who will create the prototype? When will it be created? For what purpose is it needed? You must fully understand the costs, responsibilities, maintenance, verification, and values of the prototype; otherwise, it will not receive the necessary time and attention. Teams who see a prototype as an unnecessary distraction are setting themselves up for failure, and in many cases this is because the developer of the model and the user of the model will be in different groups—one bearing the cost and the other receiving the value. This situation requires management to take a systems approach to budgeting and staffing rather than viewing each discipline separately.

You can consider prototypes before, during, and after the RTL phase of the hardware implementation. Virtual prototypes are those prototypes that you create before RTL; rapid prototypes are those created during RTL development; and physical, or silicon, prototypes are those systems that emerge after the availability of first working silicon (Figure 1).

The increased use of IP (intellectual property), the need for additional productivity, increasing verification complexity, and the desire for microarchitectural exploration are some of the changes affecting the hardware developers. Abstraction is important for productivity and exploration, but cycle accuracy is still important for detailed verification. Meanwhile, software development, debugging, and bring-up were traditionally performed when first silicon came back from the fab, putting it on a critical path. When problems were discovered in the hardware or the software interface, it was usually the software that was expected to change. This situation is no longer acceptable. The earlier that software development can begin, the more likely it is that developers will achieve success. Software requires speed, and silicon and virtual prototypes are the ideal platforms on which to perform this task. However, when detailed visibility into both hardware and software is required—such as when working on device drivers or diagnostics—rapid prototyping provides the necessary features.

Inefficiency and the growing ineffectiveness of constrained random verification techniques have exacerbated the need for verification, a critical-path function for hardware development. This step requires longer and more complex sequences to verify functionality because of both growing system complexity and increasingly large data packets (audio, pictures, low-resolution video, high-definition streaming video over wireless). Abstraction is a key element of speeding the execution of these test cases, but you cannot ignore cycle accuracy for sign-off verification. Further, most hardware developers are becoming system architects. Those developers not working on the implementation of high-value blocks are stitching together IP blocks, making sure that data can move around the system in a timely manner, and looking for ways to reduce power consumption.

Prototypes available

Many development teams plan for more than one chip spin because they may want to provide a platform for software bring-up during hardware optimization. Alternatively, they may be using a previous generation of the chip with some surrounding hardware that enables the addition of new capabilities. They may want to map these capabilities into FPGAs. Typically, a custom board accommodated all of the necessary hardware, ensuring the maximum possible execution speed.

The price of developing this type of prototype includes the board cost. If the prototype uses new silicon, it will be available late in the development cycle, and, in most cases, problems that developers find in software integration cannot influence the hardware. If the developers base the prototype on earlier silicon, it may be available earlier in the development flow so that software can influence the current design. These prototypes are generally the fastest in execution, but they have limited visibility and controllability. When problems are found, they can be difficult to diagnose or repeat. The primary developer is the hardware group and may require some unique skills, such as board design. The primary user is the software group. The cost of creating several instances is relatively small and incremental.

Rapid prototyping is the most mature of the group of processes. Hardware, verification, and firmware may use these prototypes, which are cycle-accurate and execute faster than a logic simulator. They coarsely divide into emulation and FPGA prototypes, even though a continuum exists between the categories. Confusion arises because some emulators employ FPGAs, and others don’t. To decide between them, you must weigh how much work the user must do versus what tasks the tool flow automates and how much visibility the tool provides into the hardware. Emulators place an RTL design on the hardware with minimal user intervention and provide controllability and visibility similar to that of a simulator. FPGA prototypes usually require more assistance from the user, which may include modification to the RTL, partitioning, mapping, and the design and creation of a board onto which to mount the FPGAs (Figure 2). Emulators are more expensive than FPGA prototypes.

The hardware team, initially for its own benefit, usually develops these prototypes. Verification often requires the use of rapid prototypes due to the length of simulation runs. An emulator can turn a multiweek simulation run into minutes, and an FPGA prototype is even faster. However, the emulator still executes at a fraction of real-time speed and is often too slow for software development, except for low-level firmware. Replication cost is high for emulation. FPGA prototypes can be inexpensive if developers use custom boards, but they still cost more than silicon prototypes after amortization of the initial design costs.

Engineers model the emerging family of virtual prototypes at a higher level of abstraction. They are not cycleaccurate because there is no notion of this concept at this stage of design. The prototype need not model all of the functions. The applications for virtual prototypes are software development, hardware-architecture exploration, and verification. An architectural prototype is usually the least complete of the prototypes. In some cases, the prototype models only the bus or the interconnect infrastructure, the memory subsystem, and the generic computation blocks. Traffic generators often feed this prototype to find out how well data moves through the system, to identify bottlenecks that may exist, and to compute throughput requirements for the components. It is rare for this prototype to be used for other purposes.

When high-level synthesis first appeared, it represented an attempt to increase the productivity of the design team. The secondary benefit was an increase in execution speed for verification. The productivity gain of the verification team has been measured to be larger, however, than the gain that the design team experiences. In some companies, the verification team develops the entire prototype and uses it as the comparison model for the hardware. Other teams may then use the same model for software development, and it will remain in sync with the hardware.

Another prototype targets software development, and two variants exist. One can run the same object code as the final target, whereas the second, an SDK (software-development kit), requires recompilation. Developers use SDKs when they do not need to understand anything about the hardware. An example would be an SDK for an iPhone, which allows an application developer to write and debug software without executing it on the device (Figure 3). Within the context of chip development, it is more likely for a developer to construct a binary-compatible model, which may also have built-in hardwareand software-debugging capabilities.

The biggest problem today with the construction of virtual prototypes is model availability. Many suppliers of IP do not yet ship abstract models, and, when internal reuse happens, abstract models for those blocks must be created. This step adds to the time and effort necessary to create the prototype.

Almost all emerging design flows employ one or more prototypes, some of which may connect to the hardwaredevelopment flow; some, to the verification flow; and some, to software development. Development of these prototypes is key to system-level success, and this success requires a change in team dynamics so that everyone is working toward the same goal.

Author Information
	You can reach Contributing Technical Editor Brian Bailey at brian_bailey@ acm.org.