Leveraging Safety Processor Expertise to Develop RISC-V Based Automotive Implementations

Find the Latest SoC Solutions
for... Automotive... IoT... Security... Audio... Video

www.eetimes.com, Jul. 26, 2024 – 

The podcast interview explores the role of RISC-V in the automotive sector. It begins with a brief introduction to RISC-V, explaining it as an open standard instruction set architecture (ISA). The discussion then shifts to current automotive trends from a processing perspective, highlighting advancements and the increasing importance of robust, high-performance computing.

ES: You are listening to EETimes On Air, and this is EETimes Current. I'm Eric Singer. Today's podcast is sponsored by Synopsys: our technology, your innovation. Rich Collins is a senior product management director for the ARC-V RISC-V based processor portfolio at Synopsys and has over 30 years of experience in embedded semiconductor R&D, product marketing, and business development. We invited Rich on the show today to educate us on the RISC-V ISA, and specifically how it's being used in automotive safety applications. Rich, thank you for joining us. Let's start by giving our listeners some background on what RISC-V is.

RC: All right, so RISC-V is an open standard. It was founded by some folks at Berkeley, I'd say about 15 years ago, and basically, they set out to define an open standard ISA, ISA being instruction set architecture. So effectively, they're trying to define, or have tried to define a set of instructions that's sort of how you would build a processor, a RISC based processor. Over the last 15 years it's really expanded, really taken off. People see it as an alternative to other proprietary ISAs and have over the years added a lot of extensions, and they want to define it so that it can be used for the smallest of processors all the way up to server class processors. And in order to do that, they've had to add a lot of different extensions to be able to support different kinds of processing paradigms and whatnot. And lots of people have started to adopt it, and it's grown to I think almost 4,000 members of RISC-V international that are effectively either monitoring the standard or actively building products around RISC-V processors, and that momentum is what Synopsys saw over the last few years of monitoring this standard, and effectively why we decided to go ahead and start building processors that adhere to the RISC-V standard over the last six months.

ES: From a processing perspective, what are some of the trends you're seeing in automotive?

RC: At least in terms of CPU or processing architectures, we're seeing a definite evolution of how the automotive vendors are building processing elements into their cars. As I think most people are aware, there are chips, tons of chips in almost any car, and on the road. Traditionally you had lots of kinds of discrete ICs, microcontrollers that controlled individual functions. So, you might have a chip that controlled your automatic windows, a chip that controlled your infotainment system, a chip that controlled power train or any other element in the car, and that was kind of the standard for many years. More recently they've moved to kind of an architecture that is a little bit more domain specific. They call them domain controllers, in fact. So they kind of consolidated some of the functionality that was common. So, for instance in, you have a lot more safety features that rely on external sources. So, you have cameras. You have radar and Lidar. So, all of these sensing elements to be able to detect things in the road to make sure that A, they don't hit them, or they can provide a way to actively slow the car or stop the car in order to avoid an accident, things like that. Those things, the processing for all those were done together in what they call domain controllers. And that's kind of where the sort of, I'd say the steady state is today. But what we're seeing now is a trend to move toward what they're calling zonal architectures, where you have four quadrants of the car, and each quadrant effectively manages everything that's needed for that quadrant of the car. So, in other words, all the sensor processing, the communications to maybe a central hub, all of the body electronics, the control for that quadrant, are done inside that rather large SoC. And then that would be duplicated effectively four times, and managed from each quadrant of the car would manage everything for what's needed at that portion of the vehicle. And so, what that means is that there's a lot more processing required. So, it's not just a single processor. Effectively these ADAS or driver assistant chips are going to need a lot more processors, and that's given open standards like RISC-V a major opportunity to shine with a lot of vendors, because you have that need for multiple kinds of processors, whether it's the safety management, whether it's the larger sort of host processor that's in that zonal controller, or if it's real time processing and security. All those functions basically require processing elements and need to be done effectively together in a larger SoC.

ES: What are the considerations for designing safety critical automotive applications? Obviously low latency is key, but it's obviously more complex than that.

RC: Sure. Just to step back, I think people that have been involved in safety development kind of understand the concept of the standard ISO 26262, that defines safety integrity levels, and they can be from ASIL-A to ASIL-D, effectively, increasing in terms of the risk and how safety critical that application is. Obviously the closer you get to anything that has to do with passenger safety or those types of things are effectively categorized as ASIL-D, D as in dog, and there's processors that need to basically, in any element on the SoC has to basically adhere to these safety integrity levels and get certified by a third-party certification house. And so that's a very involved process, and what we've found is that the SoC vendors, traditional chip builders that are taking different elements and putting them together and building these larger devices, really rely on vendors like Synopsys to deliver IP products that have already been certified, for one, and that can provide a lot of the what we call work products that we deliver or build on our way to certifying our, what's called a safety element out of context, the actual processor IP, and delivering those work products to the SoC vendors so that they can use them in their own certification process, and effectively trying to reduce the time to market certification is a long process, very involved. And so, anything that can help reduce that time to market or quicken that time to market is going to be looked upon very favorably. Within the processor itself, in order to achieve those ASIL levels, there's a lot of different safety mechanisms that have to be put in. If it's an ASIL-D, critical safety, the highest safety critical level, then you need effectively to have full redundancy, hardware redundancy, so you effectively duplicate many of the processing elements. That way there's a failsafe if something goes wrong with the program that's running on that processor. But even for, say, an ASIL-B implementation that's less safety critical but still has some element of, important element of safety to it, there are safety mechanisms that have to be built into the processors themselves, so things like error correction on memory to make sure your memory stays, the integrity of your memory is maintained, protecting data on buses, having washed out timers that can effectively make sure that code doesn't run out of control, things like that, are all safety mechanisms that we build into the processor itself, and again all toward basically being able to certify our processor and then deliver some of those work products to our customers building the SoCs.

ES: Okay. Well let's zoom out a bit now. How does the RISC-V ecosystem play into automotive safety implementations?

RC: Right. When I talked, a lot of the things that I talked about are kind of hardware safety mechanisms that we build into the design itself. Software is also something that is, has to be certified and taken care of from the safety perspective as well. And a lot of the software, especially if you look at the tools that are used to do, say, application development or even debug of these processors, all those tools have to be certified as well. And the ecosystem is super important. You want to make sure that, A, our customers have a lot of choice, because for one, there's not just one vendor in the world that does, builds tools that are automotive certified. There's dozens of them, and different SoC vendors have their preference. There's also automotive standards such as AUTOSAR where vendors are building their own real time operating systems as well as development tools for building out and building software applications around or on, based on these automotive processors. And it's really important that we build an IP product, because we sell to effectively any customer that's building their SoCs, and we don't dictate the choices that they want, and they make in terms of the software and tools that they use. And RISC-V is one of those areas that helps, or one of those standards that actually helps in that regard, because it's an open standard. There's lots of different vendors that are now building RISC-V compliant tools, and the idea of the standard is if you follow the profiles defined by the RISC-V standard, then any tool in the industry that also adheres to that profile will work out of the box. And so, the idea that we comply to those profiles, comply to the standard, then effectively our customers have lots of choice in the ecosystem to use any tools and software that, you know, that they need for their own development.

ES: Obviously Synopsys has this very well-known track record of success over many generations of the ARC series processors. So, as you've built on that, what do ARC-V processors bring to the table for automotive applications?

RC: Sure. As you mentioned, with the ARC Classic instructions and architecture, we've built FuSa or functional safety compliant products for probably now 12 years, I would say, is roughly when we started building certified functional safety compliant products that we've sold to multiple SoC vendors building out automotive SoCs. And we've learned a lot over those 10, 12 years in terms of what's required, how do you get things certified, what are some of the functions that need to be built into the processor itself. And I mentioned a few of them, but things like error detecting codes that will help with making sure that your data path integrity is maintained, protection on external buses, error correction on the memory so that you can avoid any sort of alpha particle bit manipulation that then could cause a program to run awry, one-shot timers, again, I mentioned about trying to maintain the integrity of a program running on the processor. So, all of these features are things that we built into our products for a number of years. We've had generations of certification with those products, and so we're bringing all that knowledge. We have a deep bench of functional safety experts within Synopsys, not only within the processor team itself, but also an independent IP assessment team here at Synopsys that looks at all IP that Synopsys delivers for automotive and assesses its worthiness, if you will, from a safety perspective, and helps us in terms of getting our third-party certification. And so all of that that we've done over the number of years, we're bringing that to bear with our ARC-V products as well, and we've had some pretty good success with it. We've had some pretty high-profile automotive SOC vendors that have publicly acknowledged that they're using our products, and we feel that itself is a validation of what we're doing and that we're on the right track and we're doing the right things in terms of building out safety products.

ES: Okay. Rich, I can't thank you enough for sharing your deep knowledge on RISC-V, what you're doing in the field with your customers and partners with the ARC-V line, and your expertise on automotive trends.

RC: Thank you, Eric. It was good chatting with you, and hopefully everybody learned a little bit of something about what we're doing here at Synopsys in terms of automotive processor IP.

ES: That brings another episode of EETimes Current to its end. Thank you for listening, and thanks again to our guest, Rich Collins, from Synopsys. EETimes Current is available through the major podcast platforms, but if you get to us at our website at eetimes.com, you'll find a transcript, along with direct links to the other stories we've mentioned and other resources. EETimes Current is produced by EETimes. It was engineered by Taylor Marvin at Coop Studios. I'm Eric Singer. Thanks for listening.

click here to read more...

 Back