Siemens unveiled a validation environment that should forestall endless iterations when designing an SoC for autonomous vehicles
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 a 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.
In Fritz’ mind, to mimic the example of a smartphone chip design environment, automotive AV/ADAS SoC designers need a platform that lets them do “rigorous pre-silicon validation.” PAVE360 can offer that, he said.
$12.4 billion investment
Siemens was able to develop a complete simulation platform because of several strategic acquisitions. Siemens made its newly acquired tools work with existing simulation models by stitching them all together.
Prior to Siemens acquisition of Mentor Graphics in 2017, the German company bought LMS International, a provider of test and mechatronics simulation software. Siemens later acquired TASS International, a global supplier of simulation software. TASS also offers engineering and test services for the automotive industry.
“No other companies, as far as we know, have made this much investment ($12.4 billion in total including Siemens’ acquisition of Mentor) to build such a comprehensive simulation platform as PAVE360,” claimed Fritz.
Car OEMs developing their own AV SoCs?
Last month, Tesla unveiled its home-grown AV SoC, calling it a “Full Self Driving” computer.
Asked if other car OEMs are designing their own AV SoCs, Fritz affirmed that “Tesla is not alone.” He noted, “When the future value of a vehicle for consumers is in AI, algorithms, software and silicon, I don’t see why car OEMs wouldn’t want to control their own future.”
McGregor confirmed that many auto OEMs are considering "custom SoC designs." But he added, “Not all are planning to go down the same road as Tesla by hiring a SoC design group. Many are working with existing semiconductor vendors and/or design houses.”
He observed, “This doesn't necessarily lock out Nvidia, NXP, Renesas, Intel, and others. But just like smartphones, game consoles, and cloud service providers, auto OEMs are considering custom silicon solutions tailored to their application and workloads.”
Magney concurred. “While many find great performance in accelerated computing solutions, lots of developers are trying to optimize their instruction sets by tightly coupling their algorithms to their processors.” Magney, however, cautioned. “For many, this may not be practical though. You don’t need to reinvent the wheel unless you have something really special going on.”
For a car OEM, PAVE360 could become effective, for example, when it decides to combine its favorite ECU for brake control with a new ADAS SoC. Using an open interface, the OEM can plug that ECU in to PAVE360 and simulate how the ADAS SoC performs in a vehicle.
How do you validate AI?
Siemens claims that PAVE360 “enables capabilities for full, closed-loop validation of the sensing/decision-making/actuating paradigm at the heart of all automated driving systems.” The company says this principle applies to validation of both deterministic (rules-based) and non-deterministic (AI-based) approaches.
But when designers don’t even know how AI algorithms deployed in a vehicle decided to take a certain action, how can they validate that it was an accurate choice?
Fritz explained that the input for an AV SoC should not be “signals” in terms of ones and zeros. The input should instead be “a scenario” – road contours, weather conditions and other factors in a geographical context. As for the outcome, “You can only verify AI’s decisions in the context of a whole vehicle,” he noted.