Cloud native EDA tools & pre-optimized hardware platforms
Mary Ann White, Product Marketing Director
Electronics engineers are being thrust into the automotive market like never before. The move to electrify automobiles, along with the advent of self-driving cars, means that silicon designers will be designing ever more sophisticated automotive ICs. But cars aren’t like most other electronic systems; it’s imperative that they cause no harm should they fail.
This brings us to the realm of functional safety, a new layer of responsibility that used to affect the small number of engineers working on military and aerospace designs. It has now gone mainstream, enabled by the ISO 26262 standard that governs how functional safety is to be assured in electronic systems and designs for automobiles. That means that there is a much broader set of engineers affected by functional safety as their companies pivot towards the rapidly growing market for automotive applications.
The challenge is that functional safety adds non-trivial tasks to the design flow. Before the current automotive push, it not only required a lot of expertise in knowing how to implement safety mechanisms such as redundancy; but, it also went against the grain of typical design goals such as optimal area. This doesn’t fit so well into a competitive commercial market where power, performance and area are the key driving goals. Engineers need design tools that allow them to meet their functional-safety requirements while maintaining competitive productivity. Areas that can provide dramatic benefit in simplifying ISO 26262 requirements for IC design are:
Figure 1: Automotive design migration to ASIL D with increased autonomous driving capabilities
Table 1: Increasing requirements for SPFM moving from ASIL B to ASIL D
Figure 2: Safety Register types that can be implemented as safety mechanisms
Another safety mechanism that can be implemented, particularly with designs that have processor cores, is dual-core lock-step (DCLS); and, while it can’t correct a fault, it can detect that a fault has occurred in either one of the cores. Two cores with identical input logic run in parallel, and their output is run through a comparator. If the output values are different from each other, it indicates a fault. This can then raise a signal so that the system can take some kind of remedial action, like moving into a known-safe state until the effects of the fault can be neutralized. Here again, careful layout of the two cores is important for ensuring that they are truly independent of each other such that cells or buffers from one core are not placed in the other, and that there is truly physical separation of the two cores. In addition, routes should not be shared or traverse from one core to the other.
While these steps are important for automotive designs, they can also be extremely time-consuming if done manually, especially for new automotive designers. Automation is the key to meeting the requirements of both a competitive market and ISO 26262. But, in order to automate this, we first need a way of expressing our functional-safety intent for consumption by the tools. This makes it possible for the tools to implement the various safety mechanisms.
The first step is to analyze the safety critical paths to identify those that must be enhanced with safety circuits. Once identified, those paths can then have the redundancy or fault-tolerant registers automatically inserted, placing them carefully with proper separation and, if needed, with taps on either side of the register. This makes them less susceptible to disturbances from the SEU fault. The rest of the tools must then respect those specific elements, since the natural inclination of tools is to optimize redundancy away. Finally, a verification step is needed to confirm that all of the desired circuits have been created, placed, and routed correctly.
One important consideration, however, is the ability to have a backup tool, which is always a good practice for verifying that safety elements are implemented. If you’re relying on a single tool for a task like, say, synthesis, then you really want another tool that can confirm that the task was performed correctly. For synthesis, you have numerous different verification tools that can act as that backup – including the new functionality needed to confirm the redundancy of safety circuits.