( ESNUG 572 Item 2 ) -------------------------------------------- [05/30/17]
Subject: Jim Hogan on ISO 26262 certification and systematic verification
AUTOMOTIVE & ISO 26262
While all these applications are important, I will focus the rest of this
post on ISO 26262 and automotive chips.
Car manufacturers must differentiate -- it's the only way they can win in
such a competitive world market. For chip designers, it's a fast changing
space with lots of moving parts.
Many car components such as: brakes, engine management, suspension, and
steering each have integrated micro-controllers. Additionally, there are
electronic systems which control the way the car is driven, like:
- Self-parking
- Adaptive cruise control which speeds up and slows down the
car if it sees another car ahead
- Systems for automatically braking the car when it encounters
an obstruction
- Airbag controllers that sense a crash and inflate the airbags
And even fully autonomous self-driving cars aren't far off in the future.
- Hogan on how Safety Critical Verification is Next Big Thing
From: [ Jim Hogan of Vista Ventures LLC ]
Hi, John,
Now let's look more closely at the ISO 26262 standard, the certification
process, and how safety critical verification is split into analyzing
systematic faults and random faults.
---- ---- ---- ---- ---- ---- ----
HOW ISO 26262 DOES & DOESN'T WORK...
ISO 26262 does not tell you what to do -- instead it tells you how to comply
with the regulations. I've listed four items below to give you an idea of
how it works.
The ISO 26262 standard:
1. Rigorously covers every facet of the chip development process.
- How the requirements are selected. Example: when you push a
brake pedal with 24.8 kilopascal of pressure, the brake will
engage.
- How the requirements turn into device specifications.
Example: the brake chip spec converts 57.3 milli-newtons
into 24.8 kilopascal of pressure.
- How the specification is implemented. Example: a look
up table for converting operator foot pressure into
newtons -- it follows a curve.
- How the implementation is verified. Example: threshold
checking, stabbing tests, impulse tests, recovery time,
and hysteresis.
- Measuring the coverage of the specs. Example: 99% coverage.
2. ISO 26262 stipulates how the chip must be built to ensure it's
safe and fault tolerant. If a fault occurs during chip operation,
the standard stipulates how those faults will be tracked and how
the chip will continue operation.
- Defines which situations the chip can continue operation.
- Defines which situations an alarm signal is sent from the
chip to some overall management software. For example, if
there is a bit flip in the memory for a brake chip, there
is error correcting logic to continue viable brake operation.
3. ISO 26262 specifies the actual development process, including the
kinds of EDA tools used and how they are certified, as well as the
specific engineering capabilities and expertise required for the
various tasks.
It won't say you must use Design Compiler 2017.1, but it will say
something like "you can use RTL synthesis but not behavioral
synthesis". IMPORTANT: Individual EDA tools are not certified,
instead a chip design company's methodology is certified. E.g
Bosch's specific in-house chip design & verification flow.
4. ISO 26262 defines the safety manager role, an actual person, and
how they must do the reporting. This person defines the
Automotive Safety Integrity Level (ASIL) of each specific device,
i.e. ASIL A, ASIL B, ASIL C, ASIL D.
---- ---- ---- ---- ---- ---- ----
ISO 26262 COMPLIANCE VERIFICATION
A key element of all safety critical standards -- and in particular ISO
26262 -- is the certification of the chip design methodology and tools.
ISO 26262 specifically states how the tool flow is tested as well as the
methods to ensure that those specific individual EDA tools work properly.
The initial certification process is done on the final design methodology
by the company that is actually doing the chip design. There are a few
agencies with expertise in this process; by the far the most well-known
is the German company TUV SUD. TUV specializes in certifying your chip
design & verification flow -- and writing up a compliance report.
The company doing the design can only certify their overall methodology; the
individual EDA tools used cannot be certified on their own. However, the
individual EDA tool vendors can work with TUV to certify their tool as an
element in the user's overall design methodology.
There are three specific levels of certification, called the Tool Confidence
Level (TCL). The TCL level is defined by the impact of the EDA tool on the
safety goal. TCL-1 is required for an EDA tool at a critical point in the
design flow. TCL-3 would be for an EDA tool that's not critical, such as an
analysis tool, that's not central to the design flow.
---- ---- ---- ---- ---- ---- ----
LET'S START WITH SYSTEMATIC VERIFICATION
Doing random fault verification is long and involved -- I made it a separate
topic in ESNUG 571 #3. Here and now in this section I'm only going to talk
in detail about systematic verification because that's easily dealt with.
Systematic faults are caused by errors during the chip development process.
These can be:
- Faults introduced by human error during engineering development,
i.e. design bugs.
- Faults introduced by the software tools used for development.
E.g. a synthesis optimization that goes wrong and introduces
incorrect functionality into the design.
- A fault in the specification or requirements document. These
can be complex, and trying to make sure that you've implemented
the right thing is not a trivial task.
Crazy amounts of tracking is involved with systematic verification. It's
not like your normal verification process. ISO 26262 requires this.
---- ---- ---- ---- ---- ---- ----
USING RTL SIMULATION & FORMAL FOR SYSTEMATIC VERIFICATION
ISO 26262 says you must be able to show how you verified your entire chip
design -- or for sections of your chip that are not verified, you must
provide waivers to specify why not.
- RTL Simulation. Simulation has a strong role in systematic
verification. You first define how the chip would get into a
scenario where a specific behavior would occur, then write
individual tests to cover each behavior.
- Formal verification is a rigorous technique where you write
specifications in terms of end-to-end assertions. There is
often a direct connection between a specified requirement and
the assertions that capture this requirement to be run in
a formal tool.
The verification teams look at the specifications to determine which pieces
are better verified with formal, and which pieces are better verified with
RTL simulation, and then divide it up accordingly.
Back in Feb 2016, I discussed how to evaluate formal tools in ESNUG 558 #3.
My warning now to everyone is that your verification tools (both formal and
RTL simulation) must now be significantly better for safety critical design.
For general verification, you might be able to get away with 95 percent
coverage -- but for safety critical, 99-100 percent coverage is required.
In my next section, I'll discuss the use of random fault verification for
safety critical designs.
- Jim Hogan
Vista Ventures LLC, OneSpin BoD Los Gatos, CA
---- ---- ---- ---- ---- ---- ----
Related Articles
Jim Hogan on how Safety Critical Verification is Next Big Thing
Jim Hogan on ISO 26262 certification and systematic verification
Jim Hogan on using Formal along with random fault verification
Jim Hogan rates all the EDA vendors on Safety Critical IC design
Join
Index
Next->Item
|
|
