The battle to serve up information and entertainment for one of the main “hubs” in our lives—the vehicle and, in particular, its entertainment system—is on. The atmosphere at the International Consumer Electronics Show in January 2014 in Las Vegas, as well as the Detroit Auto Show, was nothing but optimistic, with production expected to reach all-time highs after the already great 84M cars and commercial vehicles produced in 2012. One of the key questions for developers is the choice of the right hardware/software combination. As in other areas of our life, the main battle is fought between Apple, Google, and open-source Linux. Apple had announced its “iOS in the car” initiative in June last year. Google announced in January 2014 an Open Automotive Alliance with Audi, GM, Honda, Hyundai, and NVIDIA to ease integration with Android and standardize Android IVI systems. In 2009, the GENIVI Alliance was formed as a non-profit industry alliance committed to driving the broad adoption of an In-Vehicle Infotainment (IVI) open-source development platform. And then there’s Microsoft with Windows Embedded Automotive OS and QNX as part of Blackberry.

The defining characteristic for all these initiatives is a user experience for consumers that is completely separated from their implementation by way of an Operating System (OS) that serves as an abstraction layer for the hardware. This results in two challenges: obstacles for software validation in the context of the hardware it executes on, and the very specific needs of how different developers in the design chain interact.

The design chain

In general, the consumer electronics design chain contains five primary company types that are involved in the development of electronic systems. First, IP providers deliver to semiconductor companies some of the building blocks such as processors or graphics cores, peripheral blocks to connect to chip interfaces, and on-chip interconnects. For example, USB and Ethernet with specific automotive capabilities in themselves are not differentiating for a chip developer and are better licensed as pre-defined blocks as opposed to using valuable development resources that could be directed toward efficient differentiation of a chip design.

Second, semiconductor companies provide the silicon that is at the core of the sensor in our cars, at our wrists counting our steps, in our cell phones, inside the servers holding our information, and in the networks that transmit data either wirelessly using our phones, built into car phones, or wired using Ethernet in the car.

Third, system companies build the actual devices involved in this chain – wristbands, cell phones, and the servers that hold information. In this particular case, the system company providing your wristband to collect movement and sleep behavior may run the servers holding the information to run Big Data analytics as well, either themselves or using the commercial infrastructure of a cloud-based service provider.

Fourth, independent software vendors contribute to the software powering this scenario with the tools running on top of Android, Linux, or commercial OSs, such as iOS and Windows Mobile.

Finally, there is the necessary wireless and wired infrastructure run by network providers that are on the top of the chain and interact directly with the end users by enabling the devices empowering the interactions described above.

Figure 1 outlines the additional intricacies in the automotive design chain. The systems are so complex that there are two kinds of system houses – the actual OEM that produces the car and the Tier 1 suppliers that take semiconductor components (that also contain licensed IP and SoC subsystems) and integrate them into subsystems at the board level (Electronic Control Units (ECUs)).

Figure 1 also outlines the relative ownership of software development. Automotive OEMs that provide the actual car focus more on applications and user experience. Tier 1 providers and sub-system integrators focus on task-oriented middleware, while Tier 1 providers focus on standard services, ECU abstractions, and complex drivers. As part of their semiconductor deliverable, semiconductor companies need to provide basic abstraction layer software such as the MCU abstraction MCAL. Driven by the need to be able to flexibly port software between different MCUs and ECUs, standards like AUTOSAR (AUTomotive Open System ARchitecture) have been developed to provide a basic infrastructure to enable the component-based development of automotive software, user interfaces, and management for all application domains.

Development techniques for automotive

There is not one single chip and system development engine, neither hardware-based nor software-based, that serves all required use models and user requirements for hardware and software verification. Often only a combination of engines will help users meet their verification and software development challenges most efficiently. Before an actual implementable representation of the chip at the Register-Transfer Level (RTL) is developed, virtual prototypes can allow software development based on transaction-level models of the hardware. For RTL execution, users can use simulation, emulation, and FPGA-based prototyping before the actual chip is available.

The hardware-software dependencies can be intricate and heavily influence time to market from the unit level to the system level. After all, time to market is getting shorter in automotive as well, while automotive systems need to be compliant with standards like ISO 26262 and tested appropriately at various levels. The dependencies also span across the different layers in the design chain – semiconductor IP needs to comply with and work within an SoC environment and the system environment together with software drivers accessing it within the OS running on the integrated processors.

Consider, for example, testing of a full-featured 10/100/1000M Automotive Ethernet MAC. Users will request features such as embedded real-time clock, time stamp units, and hardware support for Audio/Video Bridging (AVB), including priority queuing and traffic shaping, which makes Ethernet applicable for automotive electronics. They will need different interfaces including RMII, RGMII, and SGMII to connect to off-chip PHYs and to AHB or AXI4 compliant DMA bus master on-chip interfaces for control. When acquiring the IP, users will expect the appropriate software, such as the software stack including drivers as well as a Transaction-Level Model (TLM) for virtual prototyping to be available.

In order to test that the software and hardware interact correctly, virtual and RTL-based environments can be mixed to utilize the best of both worlds – speed for software execution and accuracy for RTL. Hybrid TLM/emulation environments allow for mixing the accurate RTL for all blocks running on emulation with firmware running on a virtual processor model like an ARM Cortex-R4 core integrated in a virtual platform. The TLM and RTL worlds are connected using Accellera’s SCE-MI standard. All the MACs are configurable via the ARM processor, priority queues can be set up, and the sending and receiving of data traffic between MACs can be compared using a variety of data checks. Due to the high level of controllability, test code and test packets can be preloaded into the design on the fly with debuggers such as Lauterbach T32 if ARM DS-5 Development Studio is connected. All signals and buses can be traced at runtime at full speed, and the trace data is written to the console and/or files, allowing efficient testing pre-silicon.

In addition, companies like Broadcom and NVIDIA have shown that the same mixed environment – TLMs for software execution on processor subsystems and emulation executing the rest of the hardware – is very suitable to expose accurate hardware to software development teams. This allows up to 60x faster bring-up of OSs and 10x faster software execution, all well before the actual silicon is available.

Figure 2 shows the sweet spots of some of the pre-silicon software development environment, including the TLM/emulation combination that allows IP providers, semiconductor providers, Tier 1 suppliers, OEMS, and their software developers to bring up the OS and software well before commitment to silicon. Such environments not only allow much more efficient interaction within the design chain and much earlier and more efficient software bring-up, they can also significantly increase functional safety for which testing processes can be defined according to standards like ISO 26262.

Efficient automotive system design

Successful automotive development across the design chain relies upon effective and efficient hardware/software co-design. Methodologies such as a TLM/emulation flow enable OS and software bring-up before the hardware environment is set in stone. Such a process eases time to market pressures and also results in designs that meet the functional safety requirements so critical to the automotive industry.

Frank Schirrmeister is Group Director, Product Marketing, System Development Suite at Cadence Design Systems.

Cadence Design Systems

www.cadence.com

Twitter: @cadence

LinkedIn: http://www.linkedin.com/company/cadence-design-systems

Google+: http://opsy.st/CadenceGPlus

YouTube: http://www.youtube.com/user/CadenceDesign