Emulation makes it possible to stay on the road to autonomous vehicles

By Richard Pugh |  No Comments  |  Posted: October 7, 2019
Topics/Categories: Digital Twin, EDA - Verification  |  Tags: ,  | Organizations:

Richard Pugh featured image SSD expert insightRichard Pugh is the Product Marketing Manager for Mentor's Emulation Division. He holds an MSc in Computer Science and Electronics from University College London.

Given the large number of articles delivered when the words “autonomous vehicle” are googled, the topic is not only hot, but very relevant to growth in the semiconductor market.  With a little research, it becomes clear that autonomous vehicles will demand complex systems-on-chip (SoCs), and each SoC must be verified in the context of the entire vehicle. This places demands on the silicon design and verification flow that go beyond the methodologies and tools currently used in traditional automotive design and verification.

Autonomous vehicle functional verification needs to prove the predictable behavior, safety and security of complex SoCs and their associated software, sensors and actuators. This forces an expansion of the traditional approaches, and the most dramatic change is the regular inclusion of hardware emulation as the center of the verification strategy.

A hardware emulation-centric verification platform is required for autonomous vehicle verification to ensure predictable, safe, secure, working SoCs. Hardware emulation delivers the high performance needed to put any automotive design through all of the tests to assure high confidence in the verification results.

New verification challenges arise from the unique set of requirements that autonomous vehicles present. After all, each subsystem will be a sophisticated combination of hardware, comprising multiple CPUs, image processors, and artificial intelligence (AI) engines. Elaborate software applications will be executing on that hardware. The hardware and software must both be verified, separately and together. And it’s not enough for them simply to work correctly; they have to be secure, given the connectivity that these cars will have, and they must meet the safety standards set forth in ISO 26262.

Future vehicles – whether autonomous or not – will have mechanical systems replaced with electrical ones. That means more systems for the battery to support. As a result, all of those systems and subsystems will need to minimize their energy consumption. So extensive power verification of all of the SoCs used in the vehicle will be important.

Meanwhile, each of those SoCs will have an interface for access by other circuits in the car. Each interface must be verified to ensure that it provides the access intended – and, for security’s sake, no more than the intended access. Likewise, the access will be made through a variety of protocols running on the in-vehicle network. Each SoC must be able to prove that it can communicate effectively using those protocols.

Finally, we’ve seen that we need to verify hardware and software, but what if we find an issue? How do we know the root cause of the issue? Debug capabilities – and visibility into all of the inner workings of an SoC – will be crucial to correcting any problems quickly.

Complicated automotive SoCs will be designed starting with a high level of abstraction and refining the design as we move from behavioral descriptions all the way down to physical placement of transistors. Verification follows a similar path, gradually moving all the way to detailed timing and power. And, design and verification teams must be able to move through these different phases smoothly, with no time wasted on reworking the design with each move.

The paper Emulation Fills the Pre-silicon Verification Gap for Autonomous Vehicles defines the pre-silicon verification gap and explains how to close that gap by:

  • Providing verification applications and resources specific to the automotive domain
  • Giving extensive visibility into the design for efficient debug of hardware and software
  • Ensuring effective communication between all tools in the design and verification flow
  • Allowing a smooth transition between MiL (model-in-loop), SiL (software-in-loop), and pre-silicon HiL (hardware-in-loop)
  • And much more…

Author

Richard Pugh is a product marketing manager in the Emulation Division at Mentor, a Siemens Business. He has more than 30 years of experience in electronic design automation, working in IP, ASIC, and SoC verification with positions in application engineering, product marketing, and business development at ViewLogic, Synopsys, and Mentor. Pugh holds an MSc in Computer Science and Electronics from University College London and an MBA from Macquarie Graduate School of Management, Sydney.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

PLATINUM SPONSORS

Synopsys Cadence Design Systems Mentor - A Siemens Business
View All Sponsors