2.1

The race against the clock: shortening automotive IC design cycles

To meet the high-performance and low-power requirements of autonomous vehicles, SoC designers will need to create bespoke silicon architectures optimized for artificial intelligence algorithms. Using traditional design methodologies will take far too long, as the complexity of designs increases and verification time rises. To lower the investment in time and labor, many companies are looking for a proven solution that can increase their productivity and design quality, while accelerating their time-to-market. This explains the increasing interest in high-level synthesis (HLS).

HLS takes high-level descriptions of the design functionality in SystemC or C++ and synthesizes them into RTL. Designing at a higher level of abstraction accelerates the completion of initial designs by separating the specification of the chip functionality from the implementation (Figure 3). Designers must only describe what the chip needs to do, without delving into how it accomplishes such functionality. Then, the HLS tool automatically generates RTL to implement the described functionality.

Figure 3:

HLS rises the design abstraction level to improve design productivity.

Using HLS to design at a higher level of abstraction can reduce design times to a few months, and requires half as much code as a traditional RTL flow. Late functional changes, new features, or even a migration between technology nodes or from FPGA to ASIC can be incorporated without impacting the design schedule. HLS also enables the design team to explore hundreds of design variants to optimize the power, performance, and area of the chip. Design space exploration results in higher quality designs compared to hand-coded RTL.

2.2

Functional safety, verification & design for safety

Despite the numerous challenges involved in designing SoCs for AVs, the most substantial obstacle to the success of AVs is earning the trust of the public. One way that AV manufacturers can establish this trust is to demonstrate the safety and reliability their platform through safety standards and certification. To that end, the automotive industry has established a set of procedures and standards focused on the safety of electrical and electronic systems, known as functional safety. Functional safety is the reduction of the risk of electrical and electronic components malfunctioning due to failures. In the automotive industry, these procedures and requirements have been formalized in the ISO 26262 standard. ISO 26262 requires that electronics be tested for random hardware failures and systematic faults (Figure 4).

Figure 4:

ISO 26262 requires that electronics are tested for systematic and random faults.

Systematic faults are those that prevent an integrated circuit from operating correctly according to the product specifications. These could be design bugs, hardware/software interface problems, misinterpreted or incomplete specifications and so forth. The goal is to eliminate systematic faults through robust design procedures, qualified EDA tools, and formal requirements.

On the other hand, random hardware faults occur over time as the IC operates. Random hardware faults can be caused by electromagnetic interference (EMI), electro-migration, and other electrical phenomena. Some of these faults are transient, and will disappear with time, while others are permanent. In either case, a random hardware failure in a mission-critical autonomous IC has potentially catastrophic consequences. Therefore, ISO 26262 requires that chips continue to operate, or fail safely, in the event of a random hardware fault.

Verifying the functional safety of an automotive SoC involves the analysis of a design to identify potential failure modes, the insertion of safety mechanisms to mitigate failures, and verification to demonstrate the effectiveness of inserted safety mechanisms. Verifying the SoC in isolation, however, is not enough to guarantee its safe operation once inside the vehicle. For that, the chip must be tested in real operating conditions. It is not feasible to test every possible safety scenario in the real world. As vehicles progress from level 1 to level 5 automation, the number of potential scenarios that must be investigated to properly validate a vehicle explodes into the millions. As a result, estimates predict that it will require more than eight billion miles to fully test and verify the safety and functionality of an autonomous car. The only way to achieve this amount of verification is with a virtual testing environment employed early in the design process.

Hardware emulation supports model, software, and hardware in-the-loop verification. It provides an environment to test, program, and debug an IC or an entire autonomous vehicle platform before any chip or vehicle hardware is available. This testing environment merges three data types (Figure 5). First is sensor data. To generate this data without sensor hardware, advanced physics-based sensor simulations feed the hardware emulation with simulated LiDAR, radar, camera, and other sensor data. Second is compute data that is provided by the emulator running the autonomous drive IC. Third, a mechatronic simulator provides actuator data from steering, braking, and drivetrain systems. Advanced sensor simulators can also generate traffic patterns and simulate V2X communications to fully test the capabilities of an autonomous vehicle platform.

Figure 5:

Hardware emulation can fuse sensor, compute, and actuation data to create a testing environment for autonomous vehicle platforms.

2.3

Physical reliability verification

Now, the SoC design team has optimized the chip through rapid iteration enabled by HLS, verified for its functionality and functional safety, and even tested it in a realistic virtual driving environment with simulated sensor and mechatronic data. Next, the physical reliability of the design must be verified to ensure that the design will survive the manufacturing process with sufficient yield, and will operate as intended in the real-world. The hand-off from design to manufacturing is a critical juncture in the IC design process; it is where the rubber meets the road.

Understanding the reliability needs of autonomous vehicle ICs can be challenging, particularly for companies just entering this market. Typical automotive ICs are expected to function for up to thirty years in temperatures that can range from -40° C to 150° C, and electrical loads into the hundreds of volts. The harsh driving environment that automotive electronics must operate in, combined with the high reliability requirements for verification of these ICs, creates design and verification challenges that are not commonly encountered when developing ICs used in less demanding settings. Design standards will mandate acceptable criteria for electrostatic discharge (ESD) or electrical overstress (EOS) compliance, but they cannot articulate the design trade-offs or best practices needed to meet such criteria.

The traditional IC physical verification tools of design rule checking (DRC), layout vs. schematic (LVS) comparison, and electrical rule checking (ERC) can efficiently identify and solve very specific layout and circuitry issues within your IC design. But they cannot understand the holistic impact of device implementation in the context of a larger circuit. Standard physical verification tools struggle to consider the net connectivity and the physical layout of a device in the same framework.

Fortunately, a new class of IC reliability verification tool is able to consider these problematic realms in a cohesive environment. Created out of the need to improve the coverage of IC reliability verification in a circuit aware context, these tools allow focused analysis on how circuits are implemented from both a circuit topology and layout perspective. As part of this analysis, external constraints can be leveraged to direct the intent of checks and help determine which circuits are out of compliance. A reliability verification tool that can understand and assess those constraints is essential to identifying reliability issues and ensuring compliance with reliability requirements and industry standards.

One common example is protection and verification against time-dependent dielectric breakdown (TDDB) in interconnects (often called voltage-aware DRC), where reliability verification in electrical overstress (EOS) environments plays a critical role. This issue requires larger design areas to avoid failure, but is critical to mitigate in high reliability IC designs.

Next, designers must optimize the physical layout of the chip for successful manufacturing. Design for manufacturing (DFM) solutions can help designers by automatically performing layout optimizations, simulating manufacturing processes, or managing lithographic hotspots before tape-out. DFM solutions automatically measure changes in yield that result from proposed layout modifications. This gives designers the ability to select layout modifications that will maximize manufacturing yield and reliability of the chips.