The idea certainly isn’t new, but the utilization of these platforms certainly is; some pieces are still missing.
By Cheryl Ajluni
System design is hard. That should not come as a surprise to anyone these days. With design geometries shrinking and device complexity on the rise, this fact is not likely to change anytime soon.
One concept for easing that burden for system-level designers is the virtual platform. Granted, the concept itself is nothing new, but today it is being employed in ever more creative ways to bring about the desired end result – hardware/software co-development at the electronic system level (ESL). Given the increasingly technology-driven world we live in, and taking into consideration Moore’s Law, it was inevitable that the traditional serial design flow eventually would fall short. After all, the “hardware design, then software design, followed by integration” process simply does not scale for today’s large design systems.
Figure 1. Virtual platforms are software models of complete systems. They provide software engineers with high-speed, pre-silicon development environments months before hardware is available. Source: Synopsys
Virtual platforms were suggested as a way to address the problem. A virtual platform, which is based on software simulation, is an architectural-level model of real system behavior that can include processor(s), hardware peripheral components and even models of mechanical subsystems that are part of the overall system (Figure 1). It enables fast and accurate architectural exploration and optimization at the electronic system level (ESL).
The virtual platform provides a common, executable specification (virtual system prototype) that is used to drive hardware and software development in a concurrent system-design process. It is used in place of a hardware prototype. Real silicon hardware is not used until final integration. Since both the hardware and software development are completed using a virtual platform, the final integration stage is typically much easier and shorter then it would be in a traditional serial design flow.
There are many benefits of this design approach, including faster time-to-market, less risk during integration and lower cost. While the virtual platform is far from widespread mainstream adoption, it is being used today. Evidence of that can be found in the slew of case studies and technical articles available on the Internet that detail how companies such as Freescale, Infineon, STMicroelectronics, and others use virtual platforms.
Large-scale adoption of the virtual platform for use not only in hardware and software development, but for true electronic system development, will require an infrastructure that can support it. That infrastructure will demand not only the availability of tools, libraries, and even pre-assembled virtual platforms for different products, but also industry standards.
One reason why standards are critical to moving the virtual platform forward is that today’s engineers use a diverse set of languages (e.g., standard C and C++) to create the models on which virtual platforms are built. Using a standard language likely will speed the propagation of a virtual platform methodology, and it definitely will ensure that users have a wide choice of vendors from which to get their solutions. Additionally, it will ensure a high degree of portability and reusability among different vendor’s tools. But what should that standard be?
Some are looking to SystemC, a C++ library from the Open SystemC Initiative (OSCI), and OSCI’s interface standard TLM 2.0 to pave the path to system-level modeling of virtual prototypes. As Ralph von Vignau, senior director at NXP, explains, “The system development of new products at an abstract level using SystemC is constantly growing at NXP. It is critical for successful deployment that aspects such as interoperability between models are supported. Both the use of third-party IP, as well as the necessity to design faster, push the requirements for standards providing interoperability. Coupled with the globalization of the electronics market there is also an increasing awareness that interoperability of IP and tools is the way forward. At NXP we believe the TLM 2.0 standard addresses these issues and are deploying it in our company.”
OCSI’s original interface standard, TLM, is a methodology based on SystemC that provides SystemC model interoperability and reuse at the transaction level. TLM 2.0 was completed in mid 2008 and was designed to address the real-world interoperability of transaction-level models. Focusing on the modeling of systems based on memory-mapped busses and on-chip communication networks, it provides a framework for standards-based ESL design; whether architectural analysis, software development, software performance analysis, or hardware verification.
Of course, SystemC and TLM 2.0 are not the only modeling interface efforts underway. One effort is the Simics SystemC Bridge, which allows users to include unmodified SystemC device models in a Simics virtual platform setup. Another effort hails from the SPIRIT Consortium. Its ESL-based specification, IP-XACT 1.4, expands the range of IP that can be used in an IP-XACT Design Environment and provides support for transactional and mixed modeling styles, as well as advanced verification methodologies (Figure 2). The specification also includes a tight generator interface (TGI), which promotes portability of program modules (generators) that process XML data into meaningful data for a design.
Figure 2. The IP-XACT specification is an XML databook that documents many different aspects of IP modules. Source: SPIRIT Consortium.
For today’s system-level designers, the virtual platform can be a useful tool for performing fast and accurate ESL level architectural exploration and optimization. While many in the industry currently employ virtual platforms in one fashion or another, widespread adoption demands ESL standards and a firm infrastructure as opposed to what is available today – a fragmented collection of standards and internal and third-party tools offering various approaches to higher levels of abstraction.
There also must be a compelling reason for engineers to adopt virtual platforms. Multicore or multiprocessor SoC design may be just the motivation, especially when it comes to software development. Because virtual platforms are based on software models, they can be very effective for developing and debugging multicore designs.
Whatever the motivating reason, it is likely that systems-level designers will be benefitting from the use of the virtual platform for a long time to come.
Regardless of your intended use of the virtual platform, there are numerous resources available today on which you can draw. While not all inclusive, the listing below will provide you with a small sampling of those resources:
Leave a Reply