Experts At The Table: Automotive Electronics

Second of three parts: Esoteric processes; embedded software; critical challenges.


By Ann Steffora Mutschler
System-Level Design sat down to discuss the opportunities in automotive electronics with Alexandre Palus, principal SoC architect at Altera; Aveek Sarkar, VP of product engineering & support at Apache; Mladen Nizic, engineering director, mixed signal solution at Cadence; and Stephen Pateras, product marketing director, silicon test solutions at Mentor Graphics. What follows are excerpts of that conversation.


SLD: What do EDA tools need to do to accommodate the automotive industry requirements?
Sarkar: A lot of the automotive customers use more esoteric processes like other mainstream. BCD tends to be very common, LDMOSs: big devices that are able to handle high voltage ranges. Overall, that’s one of the things that we see. When we have to analyze these ICs, we have to be able to handle these esoteric, non-mainstream process technologies, and the coupling now earlier. It would have been mostly analog chips with very small digital content. Now they have ARM processors running next to analog and digital sitting on the same silicon substrate, so we have to model the noise coupling. These are some of the things that we had traditionally seen in image sensor application now move onto automotive signoff. Thermal analysis, that is becoming very key – how do you model the impact of temperature on the chip, on the package, the whole system.

SLD: What are customers asking for today in terms of the software aspect of automotive systems?
Palus: First of all, you have the embedded software. You have to split that into two categories; you have the real time part – that is pretty much invisible and it’s probably 90 to 95% of the device in the car. And then you have the application part, which is the infotainment, the display, etc., which would be driven by Linux, Microsoft and others. The application side of it is actually in everything from the wireless phone. So that’s one part. The real time part, though, is starting to become standardized because the carmakers have pushed that with AUTOSAR [AUTomotive Open System Architecture], so as a semiconductor vendor you have to provide what we call MCAL [microcontroller abstraction layer], which are the layers of abstraction for your customization. Then your different vendors will sell the operating system, some other will sell the software stack so the real time system is becoming a bit more standardized. Now if you go to the 8-bit MCU, maybe it’s not that much because when you have a window lifter, there is nothing much there, so usually the software is very small and usually it will be the IP of the integrator – not the carmaker but somebody in between like Continental, Bosch, etc. — they will own that. The carmaker will inject some of the subsystem on the engine control, on the ABS, that type of thing, but not on the low end of things.
Sarkar: I think it’s interesting when we look at the traditional auto manufacturers, they are hiring more software engineers nowadays than mechanical engineers – you can see that shift happening already.

SLD: What are going to be some of the biggest challenges coming up in this space?
Sarkar: Driverless cars. I can already see in my neighborhood the Google thing going around – it’s kind of a little scary sometimes.
Palus: Driving assistance is the next big thing. I would say by 2030, we’ll have cars driving by themselves. The only problem right now in driving assistance is the people….it’s not electronics; the electronics can do it.

SLD: Do we have the infrastructure for this already?
Palus: The car doesn’t need an infrastructure – it just drives by itself. Google is not the only one. You have Audi has a car, BMW has a car, I think Volvo has a car.
Sarkar: It has the radar that controls how fast you are going.
Pateras: Tesla just announced they want to do that with Google. They want to create a self-driving Tesla.
Palus: It’s already there. The problem is people acceptance – to be driven.
Sarkar: It’s also a regulatory concern. The laws will have to change accordingly. Like, who do you sue [when there is an accident]?

SLD: What needs to happen before this is really possible?
Sarkar: There is an interesting video from GM on driverless vehicles. It’s almost like Minority Report in a way. Cars are all connected to the network and as they are going, they are sending real time information and that’s collected by all the other cars so there are no more traffic lights because everybody knows where everybody is going and they can just zip by. The data collection, because cars will be sending their position real time, so the whole network picking it up and then processing it. That’s probably the first infrastructure change we’ll see.
Pateras: You’re probably referring to the V2X standard – vehicle-to-vehicle or vehicle-to-network where all cars are communicating to themselves and to the network.
Palus: That’s not an infrastructure change because that’s embedded vehicle. I would say from an infrastructure change, 10 years ago we were thinking we would have to build a new highway with specific lanes, electronic lanes, etc. But now, the point is that, for example with other systems, people are able to recognize what kind of clothes you are wearing, so they can recognize everything surrounding you, so there is no need anymore to have specifics and that makes it cheaper for the community but the car is getting higher priced.

SLD: What are the critical challenges that need to be addressed with automotive electronics?
Sarkar: For us what we see is standardization of the data sharing. There are different players in this whole ecosystem: the ICs vendors, the component manufacturers, the system guys – how do you share data reliably and everybody understands what everybody else is giving like IP encrypting of the model. Let’s say you are doing a system-level EMI analysis. Does the model have enough information from the chip to have a near-field or far-field radiation study done? Even for thermal analysis, when the chip guy is doing a thermal simulation, how do they get the accurate boundary condition information because that will determine entirely what the thermal signature is going to be. A lot of that is bidirectional. The data flows both bottom up from the smallest part to the whole system or top down specification of power like if you have a hundred different chips going into the car … if you have 200 ICs running off a battery, there has to be a top down mandate from the integrator saying that you shall not consume more than a couple of milliwatts for these operations. And that top down specification has to be standardized and propagated down.
Pateras: For us on test it’s getting that curve more steep, as I mentioned earlier, so really getting more cost effective tests. We’re finding that it’s constant pressure: how do I get to low DPM [defects per million] cost effectively? It’s also standardization in terms of interfacing our test to the system: to be able to communicate back and forth from the test IP infrastructure to the embedded software and the system. There is no standardization, it’s very ad hoc. Each customer has different requirements and I think we need to streamline that.
Nizic: I can echo that. A vertically-integrated system for designing and verifying all the way from the hardware and software and be able to make it all the way down to the specific sensor including some of the process challenges that can come out.
Palus: Mixed signal simulation is probably one of the big things because you have, especially for the safety-related things, you need to do fault injection, etc., to meet the ISO standards. What we right now with the ISO 26262, it’s really becoming a de facto standard and we are going to get more and more requests, and it’s going to get pushed up. Back in the mid-2000s, it was pushed from the integrator to the semiconductor vendor. Now it’s going to get pushed from the semiconductor vendor to the EDA guys, to the IP guys because there is so much work to do for the ISO 26262. That’s why I need mixed-signal simulation so I can inject my fault. I need the testing environment. EMI stuff. All of those things are coming together because safety is becoming the main thing and you cannot do the vehicle of the future without safety.