Verification environment leverages digital twins for automotive SoC design
The development and validation of complex SoCs for robocars and advanced driver assistance systems (ADAS) is territory littered with landmines.
Every little anticipated or unanticipated variable – either inside a vehicle or resulting from an infinity of road conditions — poses a conundrum. Often after completing an intricate automotive SoC design, chip designers realize they must go back and re-spin it – sometimes repeatedly – before they get it right.
This kind of iterative design process is every SoC designer’s worst nightmare.
“In developing and validating an automotive SoC,” David Fritz, global technology manager, Autonomous and ADAS at Siemens AG, explained, “The input [designers must deal with] is ‘the whole world’ – including whatever weather and road conditions a vehicle must operate in. And the output that must be verified is that their new SoC/vehicle is not running over anyone.”
In other words, there’s a lot to take in and digest, while the outcome is safety-critical.
Against this backdrop, Siemens unveiled this week a pre-silicon autonomous validation environment called PAVE360.
Siemens’ Fritz called PAVE360 “the first platform that allows a multi-division, multi-enterprise project” in designing an AV/ADAS vehicle. The platform lets multiple suppliers of vehicle components, software and subsystems to collaborate while designing a highly automated vehicle.
Jim McGregor, principal analyst at Tirias Research, told us, “You can design a custom SoC today in a simulation environment, but not at the level that PAVE360 allows.”
He explained that with PAVE360, “you can design and test a virtual SoC surrounded by virtual components in a virtual car that is driving in a virtual city under virtual environmental conditions.” It’s possible, he noted, to “design and test the SoC all the way through the vehicle operation,” and one can “change the vehicle components, design, or operating conditions to test or even redesign the SoC if necessary in close to real time.”
Phil Magney, founder and principal advisor of VSI Labs, explained challenges facing automotive SoC designers: “You have an explosion in the volume of data coming in from the various environmental sensors coupled with massive amounts of data coming in from other ECUs that ultimately affect the performance of the vehicle.”
Calling PAVE360 “pretty unique,” Magney said, “I have not yet heard of a simulation environment that is so complete.” The foundation of Siemens’ PAVE360 is a concept called the “digital twin.” A digital twin is a duplicate (simulated) version of the real world. Magney said, “For developers of vehicles or components, this literally means they can fully simulate their targets at any scale whether it is a chip, software competent, ECU or complete vehicle.”
McGregor added, “I would have killed for something like this when I was working on rockets for General Dynamics.”
Smartphone apps processors vs. Automotive SoCs
In the broad-brush outlook, smartphone apps processors and automotive SoCs are two very different animals, given the differences in chip complexity, required computational power, size and power consumption.
Stringent requirements for functional safety put extra pressure on SoC designers to get their automotive SoCs right. When automotive SoCs fail, people can die. Apps processors used for smartphones don’t pose a similar danger.
Curiously, though, while the sophistication required for automotive SoC designs is far greater than specs for smartphone app processors, the current design approach common in the automotive industry appears less refined than in the smartphone industry.
Siemens’ Fritz, who previously worked at Qualcomm and Nvidia, offered a prescription for change.
Automotive design engineers first lay out requirements [for an ADAS or AV SoC] and break them into various functions. This sets up verification for each functional block. The big challenge, however, is a growing number of variables. Each functional block might be verified to be working correctly. But when certain ADAS features are consolidated, when a different combination of sensors is deployed, or when an ECU from a different supplier is plugged in, all bets are off. The vehicle could suddenly take on a whole new behavior pattern. This radical variability could send automotive SoC designers into an endless cycle of re-verifying, re-validating and re-spinning their SoCs.
Recalling when he worked as senior director at Qualcomm, Fritz explained how greatly smartphone SoC development environment differs. In the smartphone world, designers of apps processors don’t start designing an SoC unless they’re sure they can meet all requirements imposed by company X whose silicon solution goes into company Y’s handset. Requirements range from benchmarking to power consumption. They can’t exceed a certain threshold and they must be able to satisfy the vendor’s so-called “use-case proof points.”
Everything – including software validated by the software team – must be completed well before chip development begins. The result is a highly accurate SoC that works in a smartphone.
>> Continue reading page two of this article originally published on our sister site, EE Times: "Robocar SoCs: Designers' Worst Nightmare."