Contact Us
See All Media Coverage
A Deeper Dive into IP Core Considerations for Safety-Critical Applications

Philipp Jacobsohn, Senior Staff Applications Engineer, SmartDV

This Tech Talk article is follow-up to my previous blog on the same topic. I also recently spoke on this subject—watch the video of my presentation on SmartDV’s YouTube Channel.

Safety-critical chip designs of all kinds require foresight and serious planning. The intention of this article is to shed some light on the benefits of using predefined circuit functions—that is, IP cores—in safety-critical applications, and also to provide some guidance on the selection and incorporation of IP into your chip design. 

Unfortunately, designers often underestimate the importance and benefits of getting the manufacturers of third-party IP on board for their projects at an early stage. The lack of close, intentional collaboration with IP suppliers can lead to misunderstandings, time pressure, tapeout delays, and mutual frustration. Naturally, you want to avoid all of this in your chip design project—so let’s get started. 

What are safety standards?

Before we dig into IP selection for safety-critical chip designs, let’s first take a quick look at the different industry standards at play.

The applicable standard in the automotive sector is ISO 26262, which is a subgroup of the IEC 61508 standard. DO-254 (Design Assurance Guidance for Airborne Electronic Hardware) and AMC 20-152A (which is basically an addition to DO-254) are the common standards that provide requirements for engineers developing airborne electronic hardware. Other end uses and design applications have their own specialized standards that may apply. One example would be ISO 21434 for cybersecurity, which plays an increasingly integral part in today’s automotive and avionics designs. (For the purpose of this article, I’ll constrain my focus to safety, rather than security.)

Why do we need safety standards? And why so many different ones?

Let’s discuss the question of why standardization is needed in the context of circuit development. To be frank, this topic is not something that can be considered new or even exciting! Safety standards are often even viewed as a necessary evil—and yet the operation of electronic circuits is no longer possible without clearly defined rules of reliability and operational safety. 

Similar to how an airline pilot must work through a standard protocol of all safety-related procedures for the aircraft before taking off, this also has to happen as part of circuit development. Even if a pilot has already gone through the same process of hundreds of times, and successfully completed the corresponding number of flights, this procedure must be carried out again before each new flight. The sole goal of this measure is to avoid errors. Similarly, this  is exactly what is provided by predefined standards like ISO 26262 and IEC 61508: a firmly defined structure that facilitates the discovery of possible errors and the classification of problems, thus enabling the design to react adequately to the occurrence of unforeseen situations. If a tire is damaged, the aircraft must be prevented from taking off, because it would not be able to safely land. If, however, the onboard kitchen is defective, this might be acceptable for a flight, as it would not adversely impact the airborne mechanical performance of the plane. 

Fundamentally, the goals of a ship’s captain and an airplane pilot are identical: namely, to convey their passengers and cargo safely to the intended destination. Owing to the vast differences between sea and air travel, different criteria are relevant for these tasks. It is precisely for this reason that specialized safety standards have been defined. Any supplier of equipment for these respective means of transport must know in advance whether, for example, their gyrocompass is to be installed in an airplane or a cruise ship, in order to ensure proper performance. That’s also why an IP vendor needs to understand the environment in which their predefined circuit function is to be used.

What do safety standards define?

Safety standards define the individual phases of design process requirements: planning, implementation, verification, and documentation. 

This procedure is more or less uniform for all standards, but it should be noted that each standard defines the applicable requirements for the four phases slightly differently. The tenets of each step must be met for the standard to be satisfied. 

End use and allowed probability of failure

Potential hardware failures must be categorized in order to define appropriate mechanisms for error handling. As with the aforementioned airplane tire versus kitchen scenario: an error in a car’s infotainment system might be acceptable, while an error that affects safety gear, such as the automated braking system, is not. 

Different requirements, therefore, need to be classified in turn. For example, the IEC 61508 standard is subdivided into five safety integrity levels: SIL 0 to SIL 4. The ISO 26262 standard comprises four levels: ASIL A to ASIL D (where ASIL stands for automotive safety integrity level). The higher the category level, the stricter the safety requirements, with SIL 4 or ASIL D being the most stringent. 

A product’s end use plays a vital role in determining the approach that must be taken in design and verification. A chip that makes its way into an automotive infotainment system, for example, would cause a nuisance to the driver if it were to fail—but it would not present any risk to human life. By contrast, the malfunction of a chip in an airbag or lane management system could threaten the safety of the driver, their passengers, other vehicles on the road, or even pedestrians. When a chip design’s end use could mean that human life hangs in the balance, we refer to it as safety-critical. Functional safety is essential in such designs: thus, the integrity level of such designs must be commensurate with the end use. Potential failures caused by software or hardware must be planned for and proactively addressed. 

Understanding and reacting to malfunctions

Let’s take a closer look at understanding and reacting to potential malfunctions. Fundamentally, this is all about how a system can address a failure case and determine either 1) how to prevent the failure itself, or 2) how to react to it. A distinction must be made here between hardware and software errors, which can be either safely ignored or must be prevented or reacted to, with different approaches in each case. Even with pure hardware errors, it is essential to understand what malfunctions can actually result from these, and what an appropriate reaction should look like. 

A distinction is made between systematic errors (which result, for example, from errors in circuit development or insufficient verification) and randomly occurring errors (which are caused by external influences). It is important to understand that systematic mistakes cannot be avoided in every case. It is possible to greatly increase the probability of providing an error-free product through good verification coverage, standardized test procedures, extensive tests (possibly also by using dedicated verification IP), and the use of specialized tools. As the corresponding safety standards explicitly emphasize, one hundred percent coverage cannot realistically be achieved. This is especially true of so-called corner cases, which describe the operation of a component under unusual conditions and represent a challenge in both circuit development and the associated verification. 

Random errors, on the other hand, cannot be ruled out at all. Here, it is necessary to develop strategies for reacting adequately to such errors. To eliminate potential malfunctions caused by external influences, such as alpha-particles, error detection and correction circuits must be employed. Depending on the area of application and the level of the requirement for error-free operation, it is necessary to provide an error-tolerant implementation. Fault tolerance is particularly crucial in situations where human lives would be at risk if an error occurred, such as in an airplane. In principle, such a requirement has a significantly increased effort for implementation and, of course, also for verification. Here, it is necessary to stress that chip designers must verify not only the correctness of the circuit itself, but also the correctness of error-detection and correction circuits.

How is IP development impacted?

When creating or using IP for safety-critical designs, what must an engineer bear in mind? 

Even if only a certification of the final product is to be carried out, each component must nevertheless meet the requirements that apply to the overall system. Therefore, it is necessary for all subcomponents to carry out the circuit implementation in compliance with strict rules, to consider the subsequent use of the product in safety-relevant applications, and to adhere to the development processes of the applicable standard(s). 

In the case of the ISO 26262 standard, the design process requirements include: 

  • Detailed planning, during which the requirements for functional safety are defined
  • Analysis intended to identify hazards and possible error modes 
  • Implementation, which takes into account the two previous steps

Subsequently, verification and validation of the system must take place. To achieve certification, all sub-steps must be well documented, and the results recorded. This record must include the tools used, verification methods employed, and so on.

To achieve certification according to DO-254, it is mandatory to first use clear definitions and terminology during the specification phase, to ensure full traceability from the start, to specify precise requirements, and to ensure meticulous documentation.

It takes substantial effort to achieve this type of certification! Additional tasks are necessary to create appropriate documentation (verification process, error coverage, error reports, tool use). It should also be noted that only a certain “frozen” version of a product is qualified (which remains unchanged after receiving certification). Also, tool versions that were used when creating the product must remain the same.

Obtaining industry standards body certification

To ensure compliance with a safety standard like DO-254 or ISO 26262, it is necessary to obtain certification. Companies must work with an independent organization, such as TÜV SÜD (Germany), to complete the certification process. There are many such bodies around the world. 

So, should you pursue certification? It depends. 

On the negative side, the entire process up to obtaining safety standard certification is time-consuming and requires appropriately trained personnel. It is also necessary to carry out audits with the certifying organization during the entire period of certification, during which the completeness of the measures for achieving functional safety are checked and proven.

On the positive side, certification can increase customer confidence that a product has the quality and reliability that they are looking for. Additionally, the rigorous attention to detail demanded throughout the design process can lead to the development of a superior product, as a result of the extra time and care invested.

In most cases, it makes no sense to certify individual subcomponents such as IP cores, as these are used in the context of a more complex circuit. But it is necessary for all subcomponents to comply with the strict rules specified by appropriate standards and to take into account the subsequent use of the product in safety-relevant applications.

Final considerations

As mentioned before, obtaining certification is not easy, but it can be worthwhile. Even if only a certification of the final product is to be carried out, each component—including third-party IP cores—must meet the requirements that apply to the overall system. Therefore, it is necessary for all subcomponents to carry out the circuit implementation in compliance with the strict tenets of the applicable standard, and to plan for the safety-critical end use of the product during the development phase. The previously mentioned standards define processes that must be maintained. 

SmartDV is ready to be your trusted IP partner in automotive and avionics designs. Our VIP is created by verification engineers with decades of experience in verifying complex chips. We also offer standards-based design IP for a variety of applications. Shown below is a selection of our IP cores that are applicable for safety-critical designs like the ones discussed in this article. 

As the complexity of chips continues to increase, verification grows more intricate with each passing year. In today’s chip designs, verification tends to consume about 60–80% of project resources and often represents a bottleneck in the overall process. Bearing this in mind, it pays to work with a trusted IP partner who will collaborate with you to solve any problems you encounter along the way.

Whether you’re sourcing design IP for your next SoC, ASIC, or FPGA project, or seeking VIP to put your chip design through its paces, SmartDV can quickly and reliably customize our extensive portfolio to meet your unique design needs. Our SmartCompiler™ technology makes it easy to get it get IP Your Way™—simply define your specs and let us handle it from there. 

We look forward to seeing the results of your chip design efforts on the road or in the skies!

About Philipp Jacobsohn

Philipp Jacobsohn is Senior Staff Applications Engineer at SmartDV, where he supports users of design IP and verification IP in North America and Europe. Beyond his work enabling the chip design success of SmartDV’s customers, Philipp is an avid technical writer with a keen interest in sharing the considerable knowledge he has cultivated over nearly 30 years in the semiconductor industry. Prior to joining the team at SmartDV in 2023, Philipp held a variety of engineering and field applications roles at J. Haugg, Synopsys, Synplicity, Epson Europe Electronics, Lattice Semiconductors, EBV Elektronik, and SEI-Elbatex. Philipp is based in Switzerland.

This Tech Talk article was originally published on ChipEstimate

See All Media Coverage