Published on October 09th, 2009
Increasingly, products must be further differentiated after a system-on-a-chip (SoC) has been shipped to customers. Software has therefore become more critical as a means to enable this differentiation on embedded processors. In addition, embedded-software content has become a significant portion of many semiconductor companies’ overall project efforts. Today, the most critical defects being found and removed are occurring at the interface where hardware and software meet. As illustrated in Figure 1, development teams are adopting three basic categories of solutions to deal with hardware/software development and debug issues. They also are creating representations of the target hardware to enable the advanced development of associated software. The three solution categories are: software-based development methods, which are often referred to as virtual platforms; hardware-based development methods like emulation and field-programmable-gate-array (FPGA) prototypes; and actual silicon-based development methods that use chips from previous projects or silicon prototypes (once engineering samples are available).
Figure 1: These techniques can advance the parallel development of hardware and software.
When comparing the different development methods for software prior to silicon availability, eight specific parameters need to be considered:
Within the category of software-based development methods, users have three basic options. The first is to develop virtual platforms using loosely timed transaction-level models (TLMs). With software development being the main target use model, the first versions of virtual platforms can be made available four to six weeks after specifications are frozen. Virtual platforms execute very quickly—typically between 20 MIPS and 50 MIPS for complex platforms and north of 100 MIPS for less complex designs. They offer excellent execution control and debug insight with the ability to stop all components in simulation in a synchronized manner and provide full debug access to all aspects of the design. The production cost for virtual platforms is fairly low, making it easy to replicate them for all members of the software team. In addition, virtual platforms offer a variety of system interfaces, which allows them to be connected to USB, Ethernet, SATA, etc. However, the accuracy of loosely timed virtual platforms is limited to functionally and register-accurate representations. They won’t reflect all timing aspects of the target hardware. In addition, assembling a virtual platform from a library of TLM components or even developing new TLM models may be considered overhead (i.e., a high bring-up cost by the hardware team if the models aren’t directly usable for verification as well).
The second option is to develop approximately timed virtual platforms. With the modeling of more design detail, they address the timing-accuracy issues of loosely timed virtual platforms, thereby enabling architecture exploration. Because they require more development effort, however, these platforms are available later in the project. They also execute the target hardware more slowly than loosely timed virtual platforms (typically in the range of 100 KIPS to 10 MIPS).
The third option is to develop cycle-accurate virtual platforms. For complex designs and components, cycle-accurate modeling can take just as much time as the actual register-transfer-level (RTL) development. As a result, the industry is moving away from specific C/C++-based cycle-accurate modeling and is adopting RTL for cycle-accurate software-based representations. Cycle-accurate virtual platforms are available fairly late during a project—when RTL is stable. Often, they execute the target hardware very slowly—in the range of 100 IPS to 100 KIPS.
Within the category of hardware-based development methods for software development, emulation and FPGA prototypes are the main alternatives. Generally, emulation and FPGA prototypes are available much later in the design flow after RTL is stable. This can take up to 70% of the time from requirements to tapeout. Given the substantial time it takes to produce engineering samples after tapeout, they still offer significant time advantages over using the actual silicon engineering samples. Both methods reflect the RTL accurately but vary in execution speed. Emulation is typically limited to the low MIPS range while FPGA prototypes execute much faster—in the range of 10s of MIPS. In exchange, the bring-up effort for emulation is typically less than it is for FPGA prototypes—a fact that’s offset by much higher production costs for emulators. This makes it more difficult to provide affordable replications for software-development teams. Debug insight and execution control is pretty good in emulation. While they’re not as advanced as emulation when it comes to debug, FPGA prototypes provide much better insight into the hardware than the actual silicon engineering samples. Both emulation and FPGA prototypes offer solid real-world interfaces that connect to the target system environment.
Software-development methods that use real silicon utilize silicon from a previous project and actual engineering samples once they’re available. While previous chips are available immediately at project start, they don’t accurately reflect the new target silicon. Changing register interfaces and the lack of new hardware functions, which are only available in the new design, limit this method to high-level software development. While both types of actual silicon can be executed at real-time speed, engineering samples are available very late in the project. Thus, there is little parallelization of the hardware and software efforts. In addition, while on-chip instrumentation and on-chip debug have improved over the years, they are costly due to their silicon overhead. In addition, they don’t offer the same level of control and visibility that users can find in software-based and hardware-assisted development methods for software development.
Clearly, none of the development methods for embedded software development in the context of hardware comes without disadvantages. As a result, hybrid solutions are emerging that allow “system prototyping” of systems and SoCs. They combine the advantages of software-based and hardware-assisted development methods (see Figure 2).
Figure 2: System prototyping combines the advantages of
software-based and hardware-assisted software-development efforts.
Three technology components are required to enable system prototyping:
System prototyping enables five different use models:
While software-based, hardware-assisted, and real silicon-development methods have found adoption in their own right, system prototyping allows engineers to mitigate the disadvantages of these individual methods. System prototyping, at last, allows design teams to capitalize on the combined advantages of software- and hardware-based development methods. In doing so, it enables early and productive software development.
As director, product management at Synopsys Inc., Frank Schirrmeister is responsible for the System-Level Solutions products Innovator, DesignWare® System-Level Library, and System Studio with a focus on virtual platforms for early software development. Prior to joining Synopsys, Schirrmeister held senior-management positions at Imperas, ChipVision, Cadence, AXYS Design Automation, and SICAN Microelectronics. Most recently, he served as VP of marketing at Imperas, a provider of solutions for multicore software development. At Cadence, he served as group director of verification marketing in the Design and Verification Business Unit and was instrumental in the market introduction and proliferation of innovative products like Virtual Component Co-Design, Verification Cockpit, and Incisive.