Improve Productivity at the Hardware-Software Interface Using System PrototypingBy combining the advantages of software- and hardware-based development methods, system prototyping enables early and productive software development.
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:
- Time of availability: Once the specifications for a specific design are frozen, the time that it takes for a software-development method to become available directly determines how long software developers will have to wait before starting on the project.
- Execution speed: Ideally, the chosen development method provides an accurate representation of how quickly the real hardware will execute. For software regressions, execution that is faster than real time can be beneficial.
- Accuracy: The type of software being developed determines how accurate the development method must be to represent the actual target hardware. In doing so, it ensures that the issues identified at the hardware/software boundary aren’t introduced by the development method itself.
- Production cost: The cost of a development method comprises both the actual cost of production and the overhead cost of bringing up hardware/software designs within the method. The production cost determines how easily a development method can be replicated to furnish software-development teams.
- Bring-up cost: Any required activity needed to enable a development method outside of what is absolutely necessary to get to silicon can be considered overhead. Often, the intensity of the pressure faced by software teams to get access to early representations of the hardware determines whether or not the investment in bring-up cost is considered in order to create positive returns.
- Debug insight: The ability to analyze the inside of a design (i.e., being able to access signals, registers, and the state of the hardware/software design).
- Execution control: During debug, it’s important to stop the representation of the target hardware using assertions in the hardware or breakpoints in the software—especially for designs with multiple processors, in which all components have to stop in a synchronized fashion.
- System interfaces: If the target design is an SoC, it’s important to be able to connect the design under development to real-world interfaces. For example, if a Universal Serial Bus (USB) interface is involved for verification and software development, it’s important to connect the development method to real USB protocol stacks. Similarly, for network and wireless air interfaces, connection of the design representation to real-world software is important to the execution of software development.
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:
- Physical interfaces must be available to connect the actual hardware prototype to the workstation running the simulation. Here, PCI Express is a common solution.
- Data must be transported using an agreed-upon protocol between the software and hardware worlds. Most hardware-assisted technologies offer proprietary interfaces. SCE-MI has become a standard in this domain, having been developed under the umbrella of Accellera.
- For conversion from the transaction-level model to the transport interface, transactors are needed to translate high-level protocols like AXI, OCP, and AMBA into the actual signals driving and observing the blocks that are executing in emulation or FPGA prototypes.
System prototyping enables five different use models:
- RTL reuse and architecture verification: Mitigating the bring-up effort for virtual platforms, existing RTL from previous projects can be mapped into FPGA prototypes to avoid the modeling effort of potentially complex intellectual-property (IP) blocks. The cycle-accurate execution in FPGA prototypes also increases overall fidelity and allows the replacement of virtual models with RTL to verify that architecture decisions are correct. This mitigates the slow execution of cycle-accurate software models.
- Accelerated software execution: Software typically runs more quickly on workstations and virtual processor models than in FPGA prototypes. System prototyping with processor models on the workstation allows faster overall execution while maintaining the accuracy of accelerators and peripherals. Thus, it combines the execution-speed advantages of the various development methods.
- Virtual platform as testbench for FPGA prototype: System prototyping mitigates the late availability of hardware-assisted development methods. In doing so, it enables the efficient re-use of early system-level development efforts for RTL verification and post-silicon validation purposes. The virtual platform acts as a testbench for RTL, which avoids duplicate efforts while enhancing model re-use.
- System environment connections: Virtual platforms already provide real-world and virtual I/O for popular interfaces like USB, Ethernet, and SATA. Daughtercards in FPGA prototypes provide real-world I/O with interfaces to real-life streams like the wireless physical interfaces. System prototyping with hybrids of virtual platforms and FPGA prototypes allows real-world stimulus to be used where it’s most appropriate—at both the transaction and signal levels.
- “Virtual in-circuit emulation (ICE)” connected to FPGA prototype: Software developers often dislike development boards on their desks. Instead, they prefer a development environment that combines a keyboard, screen, and their familiar software debugger. Re-use of the virtual development environment allows better access to FPGA prototypes while decreasing setup time. System prototyping allows the FPGA prototype to be kept remote. It also increases development-environment familiarity for software developers.
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.