Virtual platforms that suffice for early driver development can be made available within four to six weeks of availability of a stable hardware architecture specification. Even at the beginning of a SoC design flow, the system architecture can be defined to a level of detail that enables an unambiguous executable specification. Virtual platforms can be used to develop and integrate the software, which can in turn be used to refine the hardware architecture in an iterative process. It’s sufficient to allow a “just-in-time” delivery in phases, i.e., starting with an instruction-accurate version and delivering timed versions later.
SYSTEMC STANDARDS END PROPRIETARY MODELING STYLES
When virtual platforms first emerged in the late 1990s, there were as yet no modeling standards. Thus, the pioneers in virtual platform technology—AXYS Design Automation, VaST Systems Technology, Virtio Corp., and Virtutech—had to develop proprietary modeling solutions. At the time, EDA companies such as CoWare, Synopsys, Mentor Graphics, and Cadence were focused less on enabling software development and more on architecture exploration and verification. This was directly reflected in the early days of SystemC and limited its applicability, as it failed to provide virtual platforms that were fast enough for embedded software development.
In 2006, early adopters of virtual platforms had turned to proprietary offerings; these stalwarts were willing to sacrifice flexibility, model interoperability, and standards compliance to get a working solution. But the mainstream adoption of virtual platforms was stymied by the incompatibilities between TLMs generated by these various proprietary offerings. These incompatibilities had to be resolved to make sure that a user’s investment in modeling was paying off.
In early 2007, Synopsys donated key technologies to the OSCI TLM working group. The resulting TLM-2.0 API standard, focusing on the interoperability of TLMs, now offers standard techniques for model interfaces. This includes a standard transaction payload, temporal decoupling, direct memory interfaces, and timing annotation, which introduces the loosely timed (LT) and approximately timed (AT) modeling styles to enable various levels of accuracy.
Specifically, the blocking interface for LT modeling supports temporal decoupling. Models can block simulation to execute their functionality, or they may return immediately (i.e., not block simulation) with an optional annotation of timing. The LT modeling application programming interface (API) was designed for ease of use and doesn’t require a backward path. For virtual platforms, an estimated 90% of all cases can be dealt with by using a combination of immediate return and timing annotation.
The non-blocking interface for AT modeling supports multiple phases and timing points using an extensible scheme. It requires a backward path. The SystemC TLM-2.0 API also introduces sockets that support backward- and forward-path TLM communication, and keeps LT and AT modeling interoperable via shared mechanisms for sockets, payloads, and extensions.
VIRTUAL PLATFORM USERS AND THEIR REQUIREMENTS
Consider the example of a simplified diagram of the wireless design chain (Fig. 3). It consists of hardware intellectual-property (IP) providers, semiconductor vendors, and system integrators. All of them interact with software suppliers of IP and tools. All design-chain partners have specific technical and business concerns when it comes to collaboration and interaction among them.
Hardware IP providers are focused on architecture analysis and feature definition for their components. The main objective is to get “designed in” by semiconductor houses. To achieve that goal, hardware IP providers seek early feedback from their customers and must be able to perform early architecture analysis for hardware/software systems. While traditional hardware-IP providers have focused on hardware only, today they need to ensure early in the design process that their components, such as processors, interact appropriately with the software executing on them, or even provide essential software support.
Semiconductor suppliers have similar concerns—they, too, need to perform architecture analysis of their components and improve the likelihood of being “designed in” by their customers, who are subsystem suppliers. Even more than hardware IP providers, semiconductor suppliers today are expected to take full responsibility for device drivers and OS porting to their chips. As a result, they’re increasingly concerned about delivering software as early as possible. They seek new ways to advance software development to earlier project stages and increase software development productivity.
Finally, system integrators are concerned about software-development productivity, quality, reliability, and cost. They often must perform software integration across multiple, communicating processors in the SoC and require the earliest possible access to software-development environments representing what the supply chain will provide to them.
Reprints
