Ic Design For New Mobility: Andrew Macleod, Mentor, A Siemens Business
Ic Design For New Mobility: Andrew Macleod, Mentor, A Siemens Business
Ic Design For New Mobility: Andrew Macleod, Mentor, A Siemens Business
W H I T E P A P E R
A U T O M O T I V E
w w w . m e n t o r . c o m
IC Design for New Mobility
New mobility refers to a group of technologies that are disrupting traditional means of moving humans and
goods from one place to another. Today, this includes ride-sharing services, city-wide bike sharing programs,
electric scooters, and, of course, connected, autonomous, and electric vehicles (Figure 1). The latter have
garnered innumerable hours of public, corporate, and media attention due to the large-scale industry and
societal changes they will cause.
Connected, electric, and autonomous vehicles will alter how cars are evaluated and used. In particular, the
value of electric and autonomous vehicles is increasingly found in the electronics, and not the mechanical
aspects of the vehicle. In the new age of mobility, companies that are able to own and optimize the design of
the critical electronics will capture more of the profit available. This fact is bringing traditional automotive
manufacturers into the electronics business, and simultaneously attracting tech companies like Google and
Facebook into the automotive industry.
Figure 1: New mobility technologies such as autonomous cars and ride-sharing will disrupt our usual methods of transportation.
Consider the electronic content of an autonomous vehicle. The Society of Automotive Engineers (SAE) defines
six levels of sophistication for autonomous vehicles, from zero to five. A level five autonomous vehicle will use
a network of fifty or more advanced sensors to perceive the driving environment. This network will link LiDAR,
radar, camera, and other sensors to detect key features of the vehicle’s environment such as road lines, traffic
signs and signals, other vehicles, and pedestrians. Next, a set of integrated circuits (IC) will process the
gigabits of sensor data being gathered every second and decide on a response.
This architecture will converge, with larger and more powerful domain controller systems-on-chips (SoCs)
connected to a centralized processing unit, all implementing artificial intelligence. To date, many autonomous
vehicle programs have used CPUs and GPUs, designed for data center or personal computing applications, as
these domain controllers and central processors. These solutions worked well for early testing and
development tasks, but are not equipped to meet the power, performance, and area requirements of a true
autonomous vehicle SoC. Chip designers are discovering that meeting these requirements will require new
silicon and system architectures, developed around artificial intelligence, machine learning, and information
processing.
Developing bespoke SoCs to meet these exacting requirements is one of the most difficult, and critical
challenges that autonomous vehicle programs must overcome to achieve commercial success. The ability of
these chips to navigate a vehicle safely and reliably through an environment will be a key differentiator in the
autonomous vehicle market. The safest and most reliable system will garner the greatest public trust, and thus
the most favor in the marketplace. Advanced IC design and verification solutions can help companies realize
their SoC designs, verify them, maximize their post-manufacturing yield, and ensure their reliability over long
lifetimes.
w w w. m e nto r. co m
2 [ 1 0]
IC Design for New Mobility
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 2). 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 2: 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.
Incorporating emulation into this flow enables the design team to further accelerate design. The RTL
generated from HLS can be instantiated in an emulator, providing the software team a platform to test their
software before any chip hardware is available. Meanwhile, synthesized sensor & mechatronic system data can
be integrated to create a virtual environment that provides realistic feedback to help optimize hardware and
software designs.
Finally, advanced HLS solutions can conduct robust verification of the designs to remove bugs and errors
before the designers commit to RTL (Figure 3). HLS verification capabilities include automatic formal checks of
the C++ or SystemC code, simulation based C-to-RTL verification, and formal equivalence verification to find
bugs and errors before synthesizing to RTL.
w w w. m e nto r. co m
3 [ 1 0]
IC Design for New Mobility
Figure 3: Advanced HLS flows HLS can perform C-to-RTL verification to remove bugs and errors before committing to RTL.
Established automotive manufacturers, startups, and chip companies alike will need to develop brand new
silicon architectures optimized for neural computing and computer vision to make autonomous vehicles
possible. Existing design methodologies cannot scale to meet this demand. SoC designs for autonomous
vehicles are too complex to design efficiently by hand-coding RTL. Additionally, verification times are
escalating out of control, making it necessary to verify designs as early as possible. HLS can deliver higher
quality SoC designs faster and more efficiently than hand-coded RTL. New HLS solutions further enhance this
advantage with automatic C-to-RTL verification. In sum, HLS can provide productivity gains up to 10X, and
help designs get to market four times as fast.
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.
w w w. m e nto r. co m
4 [ 1 0]
IC Design for New Mobility
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.
There are four key processes in a complete functional safety flow (Figure 5).
1. Lifecycle management covers the functional safety lifecycle from planning to compliance. This includes
design changes, requirements, quality assurance, and audit or compliance management.
2. Next, safety analysis uses failure modes, effects, and diagnostics analysis (FMEDA) to understand
potential failure modes of the design due to random hardware faults. FMEDA automatically computes the
failure in time (FIT) rate of the design, and estimates the single-point and latent fault metrics (SPFM/LFM).
A fault list is also generated to use during the safety verification process.
Figure 5: The four key processes in functional safety include lifecycle management, safety analysis, safety verification, and design for safety.
3. Third, design for safety attempts to enhance or modify the design to mitigate potential failures from
random hardware faults. This is achieved by inserting safety mechanisms into the design that detect and
correct faulty behavior, ensuring the design behaves and fails safely. Some toolsets can even perform this
insertion automatically.
4. Fourth, safety verification proves that the design is safe using fault injection to test the behavior of the
design and safety mechanisms during a random hardware failure. The results of safety verification are
compared to the FIT rate, SPFM/LFM, and the diagnostic coverage (DC).
In the past, SoC designers and engineers had to call in experts, who performed these critical tasks with
painstaking manual procedures. Relying on experts creates a bottleneck in the SoC development process, and
prevents the experts from focusing on unique and challenging problems requiring of their skill. Today,
advanced portfolios of solutions, such as Mentor Safe IC, are able to achieve rigorous functional safety
standards while automating lifecycle management, safety analysis, design for safety, and safety verification
processes. This accelerates the verification of functional safety for compliance with industry standards such as
ISO 26262.
w w w. m e nto r. co m
5 [ 1 0]
IC Design for New Mobility
Emulation provides unparalleled flexibility for collaboration throughout the supply chain without altering the
design flow. An emulator can run specific pieces of IP, or the entire SoC design long before any silicon is ready.
Therefore, engineers can begin writing software and testing it with the evolving SoC design on which it will
be implemented. Engineers can then feed the emulation with synthetic sensor data, and output to an
environment that models the vehicle’s behavior to test how the IP and software respond to stimuli. With
emulation, each level of the supply chain will be able to begin development earlier while testing within a
model of the entire system.
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 6). 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 6: Hardware emulation can fuse sensor, compute, and actuation data to create a testing environment for autonomous vehicle platforms.
w w w. m e nto r. co m
6 [ 1 0]
IC Design for New Mobility
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.
w w w. m e nto r. co m
7 [ 1 0]
IC Design for New Mobility
Automotive AMS ICs must also operate with extreme reliability for many years, and often under harsh
environmental conditions. To manage, designers will need an integrated design and verification solution that
can bridge analog, digital, and MEMS to create the single-purpose smart sensor systems critical to
autonomous vehicles.
Aging simulations are important in automotive applications because the devices must operate reliably over
ten years or more. Automotive applications have stressful bias and thermal conditions which cause circuit
degradation over time. Using simulation, potential reliability issues can be detected early and rectified at the
design level. Next, electrothermal simulation helps account for circuit problems caused by self-heating and
mutual heating, which are a result of high power dissipation. Finally, safe operating area (SOA) simulations
detect dangerous situations that may occur over the life of a component.
Additionally, the analog and digital design environments and verification use models are different, making it
challenging to integrate the IC for full mixed-signal verification. To address these challenges, mixed-signal
simulation solutions need to be fast, accurate, easy to use, and seamlessly integrate into existing analog and
digital verification flows.
w w w. m e nto r. co m
8 [ 1 0]
IC Design for New Mobility
Traditional DFT fault models and test methodologies consider faults that arise from cell-level inputs and
outputs, and only some faults that occur on interconnect lines between cells. This level of abstraction is no
longer suitable for the small device geometries needed to meet automotive power, performance, and area
requirements.
New, automotive-grade, ATPG technologies have been developed that target defects at the transistor and
gate level. These new methodologies rely on cell-aware test (CAT), which uses fault models that specifically
target defects internal to each cell. Mentor’s CellModelGen fault model extraction uses layout-annotated Spice
representations of the cells to identify the location of possible transistor, bridge, open, and port defects. The
cell layout is analyzed for potential bridge defects by calculating the critical area of each potential defect and
its related defect probability. This analysis generates a model that ensures the highest possible defect
detection, minimizes pattern count, and preserves required information for diagnosis. Capturing these
otherwise undetectable defects helps the makers of digital ICs meet the ISO 26262 goal of zero defective parts
per billion (DPPB).
Automotive-grade ATPG has been instrumental in increasing the quality of testing to meet the rigorous
standards of ISO 26262. But, ATPG and standard test procedures only cover the chip after manufacturing.
Periodically testing these chips during operation is a crucial step to ensuring their reliability, especially over
the long service life of an automotive chip.
Built-in self-test (BIST) is test IP that is inserted into the chip for testing digital logic or memory in the field.
Logic BIST involves the on-chip generation of pseudorandom test patterns that are applied to the chip’s
circuitry. Traditional BIST technologies test the chip at power-on, to prevent the test process from affecting
the chip’s performance. Advanced testing solutions can perform tests during the chip’s operation without
affecting its performance. In addition, ATPG compression can be integrated with BIST for manufacturing-
quality test that can be performed for both power-on and in-systems testing.
On the cutting edge, on-chip test controllers can interface with any and all test IP that has been inserted into
a chip. This provides a variety of users, up to the OEM and dealer, with the capability to reconfigure test IP for
post-manufacturing use cases (Figure 8). Tier 1 suppliers can use this capability to retarget existing test IP to
test ECUs and other control units, and to check application specific functions. At the OEM level, test IP can be
reconfigured to perform in-system test runs to ensure the chip functions correctly as a part of an entire
vehicle. Finally, the dealer can access the test IP to diagnose and repair chip functions, and perform firmware –
over-the-air (FOTA) updates.
Figure 8: Advanced test controllers enable test IP reuse at all levels of the supply chain.
w w w. m e nto r. co m
9 [ 1 0]
IC Design for New Mobility
Designing these chips is just the beginning. Autonomous vehicle IC designs must be proven to operate
correctly and fail safely in the event of a random hardware failure. Functional safety standards like ISO 26262
are necessarily rigorous, targeting zero defective parts per billion (DPPM) for safety-critical ICs. Ensuring this
level of quality in astonishingly complex autonomous ICs will require a new flow that combines simulation
and emulation to “left-shift” verification in the design process. The ICs must also be validated within the
system, a task that cannot wait until real-world testing.
The physical reliability of the chips must also be verified and proven to comply with functional safety
standards and manufacturing requirements. Physical verification tools are necessary to ensure that designs
meet the specifications provided by the foundry, that the layout and schematic representations match, and
that electrical phenomenon will not lead to random hardware failures. Additionally, the mixed-signal ICs that
power the many supporting sensors come with their own design and verification challenges. The interactions
between digital and analog logic can be particularly troublesome, requiring solutions tailored specifically to
those challenges. After manufacturing, the ICs will need to be tested time and time again to ensure proper
functionality off the fab floor, and while in the field.
As automotive startups, established OEMs, and systems companies vie to be the first to market, they will need
a portfolio of advanced design automation and lifecycle management tools. Siemens PLM and Mentor are
uniquely positioned to provide such tools, with leading solutions in HLS, functional safety and verification,
emulation, physical reliability verification, AMS design, mixed-signal verification, and IC test.