Automotive Drives Novel IP Demands

In the past the automotive industry was a bit sleepy when it came to technologic innovations. Clearly, this is no longer the case. The automotive segment is now driving interesting capabilities and an unprecedented level of creativity by the IP and SoC engineering teams targeting this now-dynamic sector.

Historically, electronics for automotive was very different from those aimed at consumer devices, but things are changing here, Cadence Fellow Chris Rowen pointed out.

“It is converging in two important ways. One, it is getting to be really interesting technically, especially with the advent of ADAS (advanced driver assistance systems), vision systems, autonomous driving, more and more cloud connected information services in the car. It has many more characteristics of a mobile and IoT platform, but on steroids because the computational demands, for example, in these safety-critical vision systems are enormous. And it’s really pushing the envelope on some of the most computationally challenging problems. It’s reflected in more interest, more growth, more dynamism in the business of automotive, which has historically been just a little bit sleepy if you look back over time. It’s rarely been considered cutting-edge, in part because of the design cycle but in part because it was last year’s electronics but over wider temperature range and with longer product lifecycles. [Now], it feels less like that and more like a hot and exciting place. That change in tone is important.”

He noted there is a set of technical requirements that are really interesting, some tied to the computational demand in that. For example, in a vision system at HD resolution or Ultra HD resolution, there are potentially trillions of operations per second required, and this is driving fundamentally new architectures. “It’s been a hell of a long time since we’ve been able to say, ‘Oh yeah, automotive, it’s making more intense demands on digital architectures than mobile or cloud or server or consumer electronics,’ and that’s pretty interesting.”

Still, the computational demands fall within a pretty strict power limitation, and the design task is very much about efficiency.

Of course in absolute terms, Rowen said, the power budgets are larger than in a cell phone because there is a bigger battery at least, but there is still much constraint in packaging for heat and cooling mechanisms. As a result, “you do tend to find you’re putting the electronics into extreme temperature range situations with very high density packaging without conventional air cooling, and those things mean that you have to watch the energy efficiency, particularly in the compute-intensive things, almost as hard as you do in the cell phone/mobile space. On top of that, you have some of the special requirements that come from functional safety, like ISO 26262 compliance and other quality demands that come from people that want to deploy something that might be in the field for 20 years or more. It’s a very demanding environment in terms of engineering discipline — much more so than the typical mobile space.”

Paul Garden, product marketing manager for ARC processors at Synopsys, said that some engineering teams care more about power consumption than others, generally speaking, for different kinds of applications. “But with the amount of electronics that go into a car now, they are starting to care more and more about lowering power consumption because nearly everything is electronic. When you compare what’s in a car today compared to what was in a car 10 years ago, a lot of the systems that were maybe somewhat mechanical before are now electro-assisted or electronic in nature. That in turn has increased the number of electronic modules or systems in the car, which increases the power drain or potential power drain on the battery. It is definitely a concern for customers to keep power down.”

How do these issue manifest for the IP developer targeting the automotive space?

Aveek Sarkar, vice president of product engineering and support at Ansys-Apache, observed that there are multiple different markets under the hood of the car. One involves infotainment chips, which are like an application processor where you are looking it from the perspective of an SoC integration team putting IPs together. There also are microcontrollers, analog, radio circuits, and many others. From the perspective of the application processors, for example, “If you are designing an IP for the mobile market, and you’re expecting the same chip to go into a car, the reliability requirements are the first and foremost thing that changes. Reliability means electromigration, because cars typically will last an order of magnitude longer than a cellphone, so the lifetime requirements for the chip — and we are talking about infotainment chips that particularly tend to be on somewhat more advanced technology nodes — they are designing these IPs for these advanced technology nodes, keeping in mind the extended lifetime of the cars.”

He explained that the electronics don’t need to survive this long. “Obviously you can change it, but you don’t want to change it at the time the car is being driven. With redundancy you can take care of some of that, but still it imposes certain requirements on the IP providers to make sure the IPs they create — even basic things like standard cells — because most of the checks that [engineering teams] do for electromigration typically stop at the gate level. But the IP provider goes down to the transistor level and provides abstracted views of the standard cells to their end customers. The end customers typically don’t worry about what has been done inside the cell. That is the IP provider’s responsibility.”

In most cases, the IP providers don’t really worry too much about standard cells, especially 28nm and earlier technologies, “but if you’re looking for longer lifetime,” Sarkar added, “you’re looking at operating under much range of temperature conditions, so now you have to worry about whether the geometries used to design the cell were optimized for an automotive application. I’m talking about simple inverters, NAND gates, registers and things like that. If you go into a more complex memories like flash, then the problem complexity increases.”

Overlap happens
While there has been a lot of crossover with other market segments — infotainment and consumer comes to mind — automotive is unique and over time with further sophistication, this will change.

Rowen noted that infotainment makes the experience plusher but doesn’t change the nature of driving. However, “advanced driver assistance systems that move incrementally toward autonomous driving are utterly transformative and require technologies which are quite different from what you’re going to find in the rest of the electronics world. It’s true that consumer electronics has gesture recognition and social media has face recognition and things like, that but this kind of real-time, safety-critical, very sophisticated video analysis is something that is driven much harder by the automotive application than it is by any of the others — by either user interface or security applications, or other adjacencies, so there absolutely are a set of unique applications and demands.”

In addition to processor performance, automotive demands translate to IP development as far as energy efficiency.

“How do you deliver those hundreds of billions of operations per second in a watt or two? That’s a pretty significant challenge,” he asserted. “From differences in the design flow and the deliverables associated with the processors because of the quality to functional safety requirements, like ISO 26262, engineering teams have to be able to show that the safety considerations have been taken into account at every step along the way, and that certain particularly critical kinds of features are supported. Now, different applications have different requirements but you may have a lot more protection against transient errors — so error correcting code (ECC) becomes more important. You find that there are applications where you need lock-step execution in the processors where you have multiple processors and they’re checking one another on a cycle-by-cycle basis in order to ensure robustness.”

These are the sorts of things that might only have been found in the most mission-critical reliable server applications, Rowen added, “and we’re now finding what amounts to a low energy consumer electronics like platform — in the sense that its very multimedia based. It also plays into the variety of different processors you find such as for vision processing, voice processing, audio processing to manage sound within the cabin, and wireless processors for reliable vehicle-to-vehicle communications and safety. It comes down to a combination of computation and reliability, and that plays into what you put in the processors.”

All of the Big Three EDA companies recognize the opportunities in automotive across a wide swath of tools, IP, software, and in Mentor Graphics case, even wire harness design and real-time OS development. For Cadence, ADAS has become a focal point for IP, packaging, modeling the packaging, building of analog interfaces, as well as integration between analog and digital circuits that are operating across wide voltage and temperature ranges. And Synopsys is coming at the market from
platform IP, cores, software, physical IP, libraries, non-volatile memories and other technologies.

Synopsys’ Garden confirmed the huge uptick in hardware and software requirements to meet ISO 26262. “There are hardware features put in the EM SEP processor—things like parity checking, error corrections, a programmable watchdog timer. All these little hardware features enable a customer who’s building a subsystem to be able to write software that uses those features to make sure there aren’t errors in the memory, or aren’t errors when the software is running. On top of that is a software development kit.”

Overall, ISO 26262 compliance is no small task, he said. “It starts from the organization, to the development of the IP, to the software, to the hardware, to the documentation. There are many pieces involved, and it takes a lot of time and effort to really put together a solution that engineering teams can use.”