Enabling the Automotive Design Chain with Virtualization

Frank Schirrmeister, Director, Product Marketing, System-level Solutions, Synopsys Inc.
Mark Williams, Director, Solutions Marketing, Synopsys Inc.

As recent headlines clearly indicate, the automotive industry is struggling to manage the exploding growth of electronics content and complexity. Already, 40 percent of vehicle cost is attributed to electronics and software, and 50 to 70 percent of electronic control unit (ECU) development cost is due to software. As a result of this dramatic increase in software content and complexity, meeting quality and reliability standards today requires analysis and diagnosis of complex hardware/software problems and a change in development methodology.

In addition, the automotive industry is challenged by an increasing need to reduce design cycle times and cost. Results from a 2008 Dupont study showed that 32 percent of respondents indicated that "cost reduction" was the number one challenge facing the automotive design and engineering community. When asked what improvement would be needed to strengthen the industry, an overwhelming 53 percent of users responded with "increase[d] collaboration across the value/design chain."

When combining these results with the increasing amount of electronics content in vehicles and the dominance of processor-based electronics within that content, software becomes the central issue to which the challenges of cost reduction and collaboration must relate.

The Automotive Design Chain

Figure 1 shows a simplified diagram of the automotive design chain. It is comprised of hardware intellectual property (IP) providers, semiconductor vendors, sub-system suppliers and system integrators. All of them interact with software suppliers of IP and tools, and have specific technical and business concerns when it comes to collaboration and interaction amongst them.

Figure 1. Automotive Design Chain

Hardware IP providers are focused on component architecture analysis and feature definition. The main objective is to get "designed in" by semiconductor houses. To achieve this, hardware IP providers must seek early feedback from their customers and perform early architecture analysis for hardware/software systems. While hardware IP providers have traditionally only focused on hardware, today, they need to ensure that their components—like processors—interact appropriately with the software that's executing on them early in the process, or even provide essential software support.

Semiconductor suppliers have similar concerns in terms of conducting component architecture analysis and improving the likelihood of being "designed in" by their customers—the subsystem suppliers. Even more so than hardware IP providers, they are expected to take full responsibility for device drivers and operating system (OS) porting to their chips. As a result, they are increasingly concerned about delivering software as early as possible. They are seeking new ways to advance software development to earlier project stages and to increase software development productivity.

Sub-system suppliers are mostly concerned about the quality, reliability and cost of their sub-systems. Given the large percentage of ECU cost contributed by software development, early start of software development and its productivity are of special concern to sub-system suppliers. Before committing to semiconductor providers, they like to validate the architecture of ECUs and their semiconductor content. Overall, sub-system suppliers have the following concerns: reducing product development cycle time; improving quality by testing as much as possible and using more systematic test methodologies; improving software development productivity and reducing cost by shortening bench time; and reducing the need for hardware prototypes.

Finally, system integrators are concerned about software development productivity, quality, reliability and cost. They must do software integration often across multiple communicating ECUs. The earlier they can get access to software development environments with models representing what the supply chain will provide to them, the better!

Virtualization—Dealing with Embedded Software

Mechatronic systems, or systems with interaction between mechanical components, electronics and software, represent the most complex, daunting challenges in the automotive design chain today. The interaction between all of these domains and the resulting number of variants that must be analyzed make it impractical to wait for a true prototype to start the verification process. Virtual platforms have been used for some time to allow for the early development of software on a virtualized version of the target hardware.

A virtual platform is a fully functional computer model of a hardware design that encompasses a single- or multi-core system-on-chip (SOC), peripheral devices, input/output (I/O), mechanical components and even the user interface. The virtual platform runs on a general-purpose PC or workstation, and is detailed enough to execute unmodified production code, including drivers, the OS and applications, all at a reasonable simulation speed. Users have articulated the need for virtual platforms to not 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.

Not all areas of automotive electronics require the same level of accuracy. Figure 2 outlines the different types of automotive electronics: information systems such as navigation and Internet access that require fault-tolerant operation, body electronics such as air conditioning, door and light modules that are required to be fail-safe, and essential driving and vehicle dynamic functions that are required to be fault-functional.

Figure 2. Different Types of Automotive Electronics

Source: Alberto Sangiovanni Vincentelli, Berkeley, Paolo Giusto, GM

Likewise, when developing software on virtualized models of the target hardware, the different areas of automotive electronics require different levels of accuracy. For information systems, typically, pure functional models are sufficient. For more timing-critical elements, the virtual models of the hardware need to reflect increased timing detail. For the essential functions such as drive by wire, only part of the software functionality can be developed using virtual models of the hardware that are not fully timed. In these cases, users usually require fully cycle-accurate models of the hardware and, ideally, formal proof of accuracy for the hardware/software functions.

With increasing processor and SOC complexity, both driven by increased silicon integration, it is becoming more difficult for cycle-accurate models to be faster and easier to develop than the actual chip implementations in register transfer level (RTL) language. Consequently, users increasingly demand to use the actual physical prototype or to utilize models automatically derived from the RTL when using virtualization.

Standardization Enables Virtualization

Virtual platforms can be developed based on written design specifications. Various environments exist to develop, analyze, debug and deploy virtual platforms and models. Software development platforms typically support the SystemC TLM 2.0 interface Application Programming Interface (API) standard and include a SystemC simulator. Similarly, mechatronic style platforms typically utilize the very high-speed IC hardware description language-analog/mixed-signal (VHDL-AMS) and OpenMAST standards. Models from various sources can be used, and the resulting virtual platform is exported as a self-contained executable. The hardware/software validation platform and developed models run on any SystemC TLM 2.0-compliant simulator and can be reused in a hardware verification context.

Models can be provided in various source formats, including pre-defined libraries and SystemC models created by algorithm development tools. In addition, models can be imported from custom C, C++ and SystemC, which may be created by third-party authoring tools. Figure 3 illustrates an example of a virtual platform for a simple ECU.

Figure 3. Virtual Platform of an ECU Complete with Virtual Engine Model

In this example, all the models are coded using a loosely timed (LT) modeling style, and the processor model is instruction-accurate. The peripherals are modeled in complete functional accuracy with precise register interfaces, so the software image developed on the virtual platform will run without modification on the actual target hardware.

Summary

Virtual platforms help accelerate software development by allowing for validation at a much earlier stage in the design flow, thus increasing development productivity. While less-accurate virtual platforms are sufficient for non-real-time embedded systems, more accurate platforms are required for timing-critical applications and real-time systems. Virtual platforms can be used as a vehicle for participants in the design chain to efficiently interact with early models of the target hardware for software development, early assessment of functionality and architecture exploration. In combination with the tools for mechanical design and simulation, they are part of an interoperable tool chain for mechatronic design.

About the Authors

As director of product marketing at Synopsys Inc., Frank Schirrmeister is responsible for the system-level solutions prototyping products for virtual and field-programmable gate array (FPGA) prototyping with a focus on early software development, architecture exploration and verification. Prior to joining Synopsys, Frank held senior management positions at Imperas, ChipVision, Cadence, AXYS Design Automation and SICAN Microelectronics. Most recently, he served as vice president of marketing at Imperas, a provider of solutions for multi-core software development. At Cadence he served as group director of verification marketing in the design and verification business unit, and was instrumental in market introduction and proliferation of innovative products such as Virtual Component Co-Design, Verification Cockpit and Incisive. You can reach Frank Schirrmeister at fschirr@synopsys.com.

Mark Williams has over 20 years of senior management electronic design automation (EDA) experience in the areas of marketing and research and development (R&D). He has extensive knowledge in marketing, sales and development of AMS solutions for the IC and systems industries. Since joining Synopsys in 2003, Mark has been director of marketing for the Saber product line and director of solutions marketing for the AMS product line. Prior to Synopsys, Mark was director of product marketing for custom IC simulation tools at Cadence Design Systems. Previously, Mark managed product marketing activities at Celestry Design and held R&D positions at Cadence, Harris Semiconductor and A.B. Associates. He holds B.S. and M.S. degrees in electrical engineering from University of South Florida and has published a number of papers on various simulation topics. You can reach Mark Williams at mcw@synopsys.com.

Back to Articles Home