At the 45th Design Automation Conference in June 2008, the Open SystemC Initiative (OSCI) announced the ratification of the TLM-2.0 standard, enabling interoperability for transaction-level models (TLMs). This pivotal announcement for the electronic design automation (EDA) industry marked the beginning of an era of interoperable SystemC-based virtual platforms for embedded software development, verification, and architectural exploration. During the draft proposal process earlier in the year, OSCI received and incorporated feedback from major companies representing the chip, software-development, and design-tool communities. The next steps after ratification were to formalize a TLM-2.0 language reference manual (LRM) and eventually contribute the LRM to IEEE for further standardization once complete.
Arguably, the magnitude of this standardization can be compared to the introduction of Verilog in the late 1980s, which hastened the demise of proprietary hardware-description languages (HDLs) such as HiLo, DABL, UDL/I, and others. Today, the new SystemC TLM-2.0 specification finally includes the transaction abstractions that enable all virtual platform components to communicate with each other and interoperate. The ultimate result will be the obsolescence of proprietary languages and techniques as a means to assemble virtual platforms for early embedded-software development, verification, and architecture exploration.
THE PROBLEM ADDRESSED BY TLMs
Since the late 1990s, the importance of software to the overall success of chip-development projects has been highly debated. Case in point: in IEEE Spectrum’s 1999 EDA trends article, Wilf Corrigan, then the executive officer of LSI Logic Corp., was quoted as saying that the most pressing need for new EDA tools is a better methodology “to allow software developers to begin software verification more near the same time that chip developers begin to verify the hardware.”
Since 2007, Synopsys and IBS Inc. have confirmed the importance of software development over the course of 12 customer projects with a variety of characteristics (Fig. 1). The overall software-development effort was found to average 45% of the total effort, and in extreme cases reached 62%. Another notable fact about this project analysis was that hardware intellectual-property (IP) reuse was shown to be well over 50%, and even the reuse of software reached almost 40%.
When diving into more detail on these projects, other frequently debated issues were also resolved. First, RTL verification, including qualification of IP, dominated hardware development both in terms of overall effort and in elapsed time. Second, software development dominated projects overall—again, both in overall effort and elapsed time. Third, the actual elapsed time required to develop the software was longer than that needed to get from the hardware requirements stage to tapeout.
As a result of these findings, and with confirmation of the increased importance of software, the focus has now shifted to determining a) how to optimize software development so that it starts as early as possible in the project process on representations of the hardware under development, and b) how to increase software development productivity.
With respect to starting software development earlier, project data makes it clear that relying on RTL-dependent methods to enable software development will not be enough (Fig. 2 a, b). Getting to verified RTL alone makes up over 50% of the elapsed time from requirements to tapeout of the hardware. Adding in the elapsed time for RTL development and efforts on IP qualification, stable RTL is often achieved after almost 60% to 70% of the time to tapeout has progressed. This still leaves plenty of time before actual silicon becomes available, but demand is high for methods that allow hardware-dependent software development even earlier.
Development productivity surveys typically point to “debug” as the biggest issue plaguing hardware/software development. As a result, enhanced insights into the hardware and software debugging process are required.
THE SOLUTION: VIRTUALIZATION
As the above data shows, a purely sequential approach-–developing software after the hardware becomes available—is a good recipe for missing market windows and reducing profits. The development of software takes almost as long as that of hardware, and a sequential flow almost doubles the development time. Once RTL is available, hardware-assisted techniques like emulation and FPGA prototyping can be employed. While these techniques allow bring-up before silicon becomes available, their dependence on RTL delays their availability until after 70% of the time to tapeout has already gone by.
The effective solution to overcoming the time-to-availability issues—virtual platforms—has been extant since the late 1990s. Virtual platforms are fully functional software representations of a hardware design that encompass a single- or multi-core system-on-a-chip (SoC), peripheral devices, I/O, and the user interface. A virtual platform runs on a general-purpose PC or workstation and is detailed enough to execute unmodified production code, including drivers, the operating system (OS), and applications at reasonable simulation speed. Users have articulated the need for virtual platforms not to be slower than one-tenth of real time to be effective for embedded software development. The achievable simulation speed depends on the level of model abstraction, which also determines the platform’s accuracy.
Reprints
