Future Emulation Requirements
Future Emulation Requirements
Future Emulation Requirements
W H I T E P A P E R
E M U L A T I O N
w w w . m e n t o r . c o m
End-to-End Vehicle Verification
INTRODUCTION
Future automobiles are bringing about the convergence of a huge range of technologies. Electrification;
sensors; connectivity; cloud computing; big data; AI — they’re all intimately connected in functional
safety and their driver-assist features for autonomous vehicles, vehicle-to-anything (V2X) communication,
and infotainment electronics.
Furthermore, these vehicles are the ultimate systems-of-systems-of-systems. At the lowest levels we have
individual sensors and integrated circuits. They interact in the various subsystems of the vehicle, and those
subsystems comprise the vehicle itself. But it doesn’t stop there: the vehicle is but a part of the overall
vehicular environment, which includes other vehicles, pedestrians, infrastructure, and even the cloud.
This makes verification of automotive systems an enormous task. There are literally millions of scenarios
to be checked out. And each of those scenarios has variants. For example, one scenario might have the
car approaching a pedestrian in a crosswalk. But that could be at different times of day, with different
weather, with different pedestrian clothing, and with different racial types. All of which present a
verification project that, realistically, could never be accomplished using manual, physical means.
At the 2016 Paris Auto Show, Toyota CEO Akio Toyoda warned that, ““14.2 billion miles of testing is
needed.” In a 2014 article, Autonomous Driving, Roland Berger noted that, “Design validation will be a
major – if not the largest – cost component.” And the McKinsey report, When Will the Robots Hit the
Road, cautioned that, “While hardware innovations will deliver, software will remain a critical bottleneck.”
Warning lights are flashing for anyone not taking the full burden of automotive design seriously enough.
This is not a business where one can come in unprepared for some back-breaking work.
As if raw complexity weren’t enough, safety and security complicate matters further, since lives are at
stake. Certification is coming, as standards like ISO 26262 and, soon, the SOTIF (Safety of the Intended
Functionality) standard for defining test scenarios become established. Vendors must do more than pay
lip service to safety; they must prove safety.
All of these demands join the usual challenges of getting a cost-competitive product to market as quickly
as possible. The problem cries out for verification tools that can make this process manageable. A
combination of realistic scenario modeling, hardware emulation, and mechatronic verification are
required to get a new car on the road quickly and efficiently.
w w w. m e nto r. co m
2
End-to-End Vehicle Verification
All three of these elements need to be included in any comprehensive verification process. And that
presents a significant challenge, since there is no time to do physical prototyping using trial-and-error to
find issues. And we certainly can’t test safety and security thoroughly in a real, physical vehicle. The only
way we can do an extensive verification job is to virtualize the entire system – environment and vehicle.
Figure 2. PreScan, from Siemens’ Tass group, can model a wide range of
real-world scenarios.
w w w. m e nto r. co m
3
End-to-End Vehicle Verification
But there’s a faster way to verify silicon: emulators. Unlike simulators, which use computer instructions to
do their work, an emulator implements the circuit that you’re trying to verify in logic chips that make up
the heart of the emulator. In Veloce emulators, those logic chips have been custom-designed by Mentor
Graphics to allow them to implement any digital design within the size constraints of the emulator. And
Veloce emulators can handle up to 15 billion gates, effectively removing design size as a constraint. So,
while you’re not running the actual final silicon chip – which hasn’t yet been built – you’re still using
hardware instead of software, and that can speed things up by 1000-10,000 times.
One key requirement of any verification approach is visibility. You need to be able to see deep inside the
circuits so that, if something goes wrong, you can figure out exactly where and why it happened. You
can’t do that with a real, physical circuit because the overwhelming majority of the signals never leave
the chip – so they’re not visible. Simulators give good visibility, since everything is modeled in software,
but, as we’ve seen, they’re too slow. Critically, emulators also provide the needed visibility. Mentor’s
Veloce emulators make it possible to peer into the circuits in the same way that simulation allows, but
with far faster execution speeds.
The circuit that you build inside an emulator acts as a digital twin of the real circuit that you’re designing.
It allows you to develop a high-quality circuit much more quickly. This makes verification much more
efficient, because you’re testing the circuit before it’s built. This means that there’s no need to wait for
actual silicon to do the verification. More critically, you can find any problems before committing to
silicon, dramatically reducing the chances of an expensive and time-consuming mask re-spin and raising
confidence when you move into production.
Importantly, scenarios and results can be traced back to requirements. This lets you converge on a
complete, correct design more quickly, since the verification plan and results remain connected to the
requirements that drove the design in the first place.
Figure 3. Veloce emulators take a design that’s been compiled for the emulator, execute the design, and allow debugging
of both hardware and software.
w w w. m e nto r. co m
4
End-to-End Vehicle Verification
Finally, Veloce emulators can be installed in data centers, making them accessible by global design teams
around the clock. This keeps the design and verification process going without requiring a break at the
end of the day.
While Veloce emulators help to ensure that a silicon design is correct, there remains the challenge of
testing production silicon to ensure that only fully-functional chips are used in safety-critical
applications. Mentor’s Tessent TestKompress has been augmented with automotive-specific test patterns
and more thorough analysis of cell-to-cell interactions to increase defect coverage. Improved vector
merging and compression keep test costs down and throughput high.
Systematic faults are, by and large, design errors or bugs. If a condition occurs that uncovers some bug,
then that bug will happen predictably every time those conditions crop up – hence it is deterministic.
Random faults, on the other hand, don’t represent an error in the circuit. They’re caused by something
external that’s unexpected and probably not repeatable. The classic example is the single-event upset
(SEU), where an energetic particle strikes a circuit somewhere and disrupts the state of the circuit.
Emulation helps with systematic faults by raising the level of verification coverage. It provides enough
performance to put the circuit through all of its paces, ensuring maximal coverage.
Emulation helps with random faults by testing what happens when random faults are inserted. Unlike
the situation with systematic faults, where you’re fixing circuit bugs if you find them, there aren’t bugs to
fix with random faults. Instead, you’re trying to prove that, if one of these unexpected events does occur,
that the system can recover into a safe state. The vehicle won’t suddenly be sent careening off the road,
for instance.
Siemens’ AMEsim tool provides just such a capability, using functional mock-up units (FMUs) to simulate
the effects of the emulator outputs. This is still a virtualized environment – you’re driving digital twins of
major mechanical components like the engine, the transmission, the brakes, and the steering.
So, for example, if a scenario in PreScan shows a pedestrian jumping unexpectedly in front of the car, the
camera and other sensor signals that observe this happening are run through the emulator. The emulator
will make a decision – say, to make an evasive steering maneuver, or to apply the brakes, or both. The
logical signals indicating the decision can then be sent to AMEsim, where the steering wheel will turn by
the requested amount, or the brakes will be applied the requested amount, or both.
w w w. m e nto r. co m
5
End-to-End Vehicle Verification
Figure 4. Siemens’ AMEsim allows simulation of mechanical systems in response to emulator outputs.
Figure 5. Together, PreScan, Veloce, and AMEsim provide end-to-end vehicle verification.
w w w. m e nto r. co m
6
End-to-End Vehicle Verification
These systems provide the performance required to run through the millions upon millions of scenarios
that must be covered before you can be sure that your vehicle will operate correctly and that it will
protect both the vehicle passengers and those outside the vehicle.
Not only can you test scenarios faster in a virtual environment, you can also test scenarios that would be
impossible to do with a real vehicle, either because it’s impractical (“what happens when it snows?” —
but I’m testing in July) or unethical (“will I successfully avoid that pedestrian?”).
By running a thorough verification using PreScan, Veloce, and AMEsim, you develop the confidence that
your design will perform as expected, behave in a safe manner, operate and communicate securely, and
meet the cost expectations required for market success and for the profitability that can both reward
your past efforts and fund future new developments.