IP Risk Sharing

Who is responsible for automobile safety? If you want to play in the industry you have to take on some of the responsibility.


For most people within the semiconductor industry, managing risk involves making the right product decisions that will enable a company to be profitable, and ensuring the product is successfully produced within the necessary time window. In contrast, for products within high-risk areas such as medical and mil/aero, design often proceeds at a slower pace, using proven technologies and adopting large amounts of traceability into the flow. These are different approaches, but they are on a collision path as more of the consumer level and mass market products are reaching into products such as automobiles, medical devices and other places where the risk of failure can lead to human harm.

Standards are being created that attempt to limit the risk associated with the failure of an electronic component within devices such as a car. In addition to defining good design and engineering practices, it also acknowledges that semiconductor devices can fail and that in turn can cause problems. While analog systems tend to fail gracefully most of the time, digital failures are more catastrophic and as we trust more of the basic functionality of the car to digital systems, safeguards have to be inserted.

Devices, such as cars, are also the place where issues such as safety and security come together. The industry has already seen some high-profile examples of the impact of ignoring security and how this can directly lead to safety issues. These kinds of issues will have a large impact on the way that systems are designed and some parts of it will require retooling.

Let’s take a step back. In the 1980s, when software-driven systems were beginning to replace dedicated hardware, there was growing concern about the safety of this approach. The people defining the standards at that time wisely concluded that “it was almost impossible to prove software correct, and even if it were correct with respect to its specification, the difficulty of getting the specification correct was well known.”

Before the hardware community gets too excited, they also concluded that the same was true for hardware and those in verification know how true this is. No piece of hardware can be 100% verified. By 1995, a draft standard was in place that advocated a new approach to functional safety and made sure that risks within the system were understood. That became a released standard in 2000 and is known as IEC 61508.

The creators of that standard understood that what they were doing was only one layer of the problem. Different vertical segments would have different levels of risk, safety requirements and other considerations. Within the automotive segment, a derivative specification was created and we know this as ISO 26262.

Confusion is rampant
There is a maxim of unknown origin that says, “The great thing about standards is that there are plenty to choose from.” However, that does not apply here. The modified form is becoming, “The problem with standards is that there are many that apply.” To be a part of the automotive supply chain, you have to be aware of, and qualified under, several standards. That number is increasing and those standards are being updated.

For example, Navraj Nandra, senior director of marketing for Synopsys, says that “IP vendors are being considered part of the supply chain. In order for the IP vendor to be successful, they need to adopt the design methodologies and design deliverables that are automotive grade.” Nandra notes this includes ISO 26262 for functional safety and that designers need to reach their target ASIL levels. They also assist with an SoC developer’s AEC-Q100 qualification as required by automotive manufacturers.

AEC Q100 relates to “Stress Test Qualification for Integrated Circuits” and was first put into practice in 1994.

“AEC Q100 it is a component level specification, so it has things like wire bond pull and sheer and delamination,” explains Andrew Faulkner, senior director of product marketing for Sidense. “None of this relates to IP, but there are parts of it that do. It also talks about storage temperature testing and temperature cycling. You can’t claim to be compliant unless you do all of the tests, but we do all of the tests that are applicable to IP so that when it is put into a system, and if you follow all of the guidelines for Q100, then you will pass.”

Faulkner sees a trickle-down effect occurring. “It starts with the car manufacturer, and they push requirements down to the electronic module manufacturer, and they in turn push it down to their IP vendor and they in turn push it down to us. Those kinds of standards are very collaborative. We have to make sure that our design enables our customers to meet the standard.”

This means that an IP vendor has to have a greater understanding about the market. “An IP vendor has to understand the intended market for their IP and has to work with the user,” says Kevin Yee, product marketing director for Cadence. “As an IP provider, we have to understand all about the market and sometimes make decisions about what are critical requirements and make sure we get those designed in.”

This is where confusion starts.

The first edition of ISO 26262 was published in 2011 and applies to cars weighing less than 3500 kg. It targets the electrical and electronic sub-systems. ISO 26262 is not mandated by the automotive industry, but it is being increasingly mandated by automobile manufacturers. The standard as written today is also seen by many as a first draft, so you can either read the spec as written today, or where you think it is going and be prepared for the future.

“There are a lot of people who are confused about it and a lot of misinformation going around,” says Yee. “What most people don’t understand is that ISO 26262 specifications are for the chip level. There is no certification for IP although we are seeing them move in that direction. ISO is being updated to start including IP and what can be done there.”

“It does not say in the standard that it has to be at the IC level,” counters Faulkner. “Neither does it state the IP level or the module level, but it needs to have it somewhere. We can do things in our IP that provides some redundancy in the memory. We can add security features. We also have to make sure that we cover the temperature range.”

The lack of clarity makes it difficult for the IP developer to know what to do. “I have talked to designers that have been in automotive for a long time,” says Yee. “Their comment is ‘we have a system in place at the system level, so don’t go and change the IP and mess up what we are already doing.’ Do they want the IP to do replication, which makes the IP larger, or do you let the system guy do the replication or maybe they have a separate path for that recovery?”

Impact on IP industry
If you assume that ISO 26262 applies to the whole food chain, Synopsys’ Nandra says, “the ISO 26262 requirements add a large set of new deliverables including rules and processes for functional safety, Failure Modes Effect Analysis (FMEA), quality management and configuration management.”

“ISO 26262 is important and you have to figure out what it means if you want to sell IP blocks into that environment,” says Drew Wingard, chief technology officer at Sonics. “One thing you may do is add configuration options that put various forms of redundancy into the design so that you can be more tolerant of errors. It is not that you have to prevent errors from happening. It is that you must catch them and put the car into a safe operating mode.”

But configurability comes at a price. “It gets tough when you get into domains such as ISO 26262 or DO-254 because those look at not just the IP, but the process in which the IP was created,” says Gabriel Chidolue, verification technologist for Mentor Graphics. “That means that there is a lot more for the user of the IP to show in terms of the process followed. You have to follow the guidelines set out by the standards. You have to specify the traditional information and to show that the things that should work do actually work. In the case of ISO 26262, there is a lot of emphasis in showing fault tolerance in the design. That requires specific flows and characterization of faults, and the design’s inherent behavior in how it reacts to those faults.”

Some changes may be more fundamental in nature. “Customers sometimes come up with temperature and voltage conditions that are beyond the standard range and may have special power requirements,” points out Vamshi Krishna, senior IP field application engineer at Open-Silicon. “In these cases the IP vendor needs to invest a substantial effort to ensure their IP is compatible with these extreme requirements. A common core may not be suitable in these scenarios and in some cases a design change may be needed to meet these requirements.”

While Krishna points out that these instances are not common, there are things that do apply to all IP intended for these markets. “The standard requires reliability conditions to prevent system failure, availability conditions to ensure system availability even after a failure, and serviceability conditions to diagnose and repair the system after failure. IP suppliers have to modify the design to ensure all of these requirements are met. This change in the design along with additional documentation in the deliverables is a significant effort for vendors to win and support the market segment.”

New tools
FMEA is one of the most important requirements of all domain standards where safety is involved. Ironically, the tools necessary to analyze this are tools that have long since been dropped by the EDA industry. Back in the 1980s, Fault Simulation was a standard part of the verification suite. It was used to grade the quality of the test vectors that were to be used to verify the manufactured chips. However, rising chip sizes meant that time on the tester was increasing rapidly and becoming the dominant cost of devices.

To reduce the test burden, additional logic was placed on the chip to enable scan-based testing. This ended the need for fault simulation and it quickly went by the wayside. But scan chains do not deal with faults that occur during usage, and these faults have to be detected while the device is in operation. This has created a resurgence in the need for fault simulation and to that end, Synopsys has just acquired WinterLogic, a company that specialized in fault simulation.

Automotive is one of the fastest-growing segments of the semiconductor industry, but in order to play, the stakes are high. New design and verification techniques apply that will require a rethinking of design practices within many companies. Over time, this may lead to better overall design methodologies being used within the industry, but overdesign may lead to less competitive products. The standards are also evolving. In 2017, the industry can expect to see a new version of ISO 26262 come to market, so anyone designing IP today will need to start anticipating what that standard will require rather than the one in existence. The new standard is also expected to start addressing intentional misuse, or hacking.

Related Stories
Reducing The Risk Of Third Party IP Integration
New IP Risks
IP Integration Challenges Increase