Master the design and verification of next gen transport: Part One – overview

The design and verification of next generation transportation systems is proving a persistent headache, particularly as carmakers and their suppliers look to move toward Level 4 and Level 5 autonomous vehicles.

This is the first in a four-part series that addresses how high-level synthesis (HLS) and emulation contribute to relieving some of the pain, though with reference to other tools within a comprehensive flow.

It is based on a tutorial developed by David Aerne, Jacob Wiltgen and Richard Pugh at Mentor, a Siemens business. As such it concentrates on that vendor’s EDA solutions, specifically Catapult HLS and the Veloce emulation family.

(The tutorial has already been presented at DVCon United States and DVCon China, and will be available again during DVCon Europe. More details for attendees).

The series begins with an overview of the challenges and solutions followed by three deeper demonstrations.

• Part Two: HLS for algorithm development and optimization.
• Part Three: Functional safety for HLS-derived designs.
• Part Four: Emulation for development and verification in a system-of-systems context.

Parts Two and Three consider case studies based on the Tiny YOLO convolutional neural network model for object detection and classification as an illustration of the main obstacles facing design and verification engineers. You can learn more about YOLO (‘You Only Look Once’ here).

Challenges in automotive design

There are five overarching forces reshaping the automotive design landscape. Of these, electrification and infotainment are the more established.

Extra difficulties are posed by advanced driver-assistance systems (ADAS) and autonomy, an increasing number of smart sensor technologies, and demands for greater V2X connectivity (e.g., vehicle-to-vehicle, vehicle-to-infrastructure, etc). In these three areas, there is also a trend to drive more system intelligence into vehicles and other parts of what we call the edge to ensure safe and appropriate responsiveness.

Then at the design level, there are also, broadly speaking, five other challenges.

1. Existing technologies are already driving up design complexity and size. For example, even a ‘small’ CNN for computer vision such as Tiny Yolo may only detect 20 objects, but still needs to carry out more than 70 billion MACs per second using more than 25 million weights.
2. Along with new sensors, these technologies and the algorithms that underpin them are constantly evolving. Tiny Yolo is currently in its third version. Moreover, players want to add their own differentiation to the products they offer, with proprietary enhancements and additions, as well as those required by evolving and emerging applications.
3. Functional safety requirements must be met and verified, according to standards such as chiefly ISO 26262 – and these are also under constant review, improvement and extension.
4. Test requirements are already heavy and will continue to rise. Akio Toyoda, CEO of Toyota, has estimated that a full autonomous vehicle will need to undergo some kind of acceptable test over 14.2 billion km. Millions of tests need to be applied.
5. Test then needs to be undertaken both at the standard silicon system level and, as Toyoda’s observation implies, at the system-of-systems level.

How then can HLS and emulation help players in advanced transportation systems master and overcome all these factors?

The role of high-level synthesis

HLS is a ‘shift left’ abstraction above RTL. Some of the main advantages claimed for it include:

• An ability to generate high quality RTL from descriptions in C++ and System C, that also allows for wide architectural exploration pulling upon IP libraries and all of this achieved much more quickly than hand-coding RTL alone (an increasingly onerous task as design sizes mushroom).
• Much faster simulation speeds, anything between 50 and 1,000X faster than for traditional simulation, with verification further assisted by formal pre-RTL synthesis checks and increasingly robust metrics for code and functional coverage.
• Integrated power optimization, and equivalence checking across C++ models and the resulting RTL.

Each of these qualities has benefits in terms of the challenges facing automotive design.

They accelerate design cycles, reducing code volume by 5X compared to RTL. Users can quickly swap new features in and out. They can examine their coding and architectural options, and optimize across power, performance and area. On that last point, as well as facing the challenge of implementing more sophisticated algorithms, ADAS systems overall face a power ceiling of just 100W.

A further benefit is that the rapidly verified RTL that results can then be quickly fed into a functional safety workflow to undergo the failure mode effects and diagnostic analysis (FMEDA) required under ISO26262.

As shown in Figure 1, HLS essentially separates functionality from implementation making it faster and more productive – and allowing easier rework as functionality is added or extended according to standards or the designer’s proprietary goals.

Figure 1. High-level synthesis boost productivity by separating functionality from implementation (Mentor)

The role of emulation

Emulators compile and then execute tests on custom hardware. They do this thousands of times faster than for traditional simulation, and enable pre-silicon verification of software. They provide visibility for debug that is now available for FPGA prototypes, and are geared for fault injection, monitoring, and, critically for the automotive market, detailed analysis of safety-critical hardware-software systems. And they have offered all this for quite some time.

In the context of automotive challenges, some of those qualities have self-evident benefits. But more recently, emulators have become more closely integrated with other design solutions.

So, in the context of HLS, wrappers and transactors can enable the verification of synthesizable C++ and RTL in a environment based around TensorFlow, the open-source machine-learning framework developed by Google. This can reduce RTL verification time from hours to minutes.

Figure 2. Emulation plus HLS for efficiency in a TensorFlow context (Mentor/Accellera)

But at the system-of-systems-level, they can also be used alongside tools that simulate sensor input and then, via the emulator, place a virtualized implementation within a simulation of a real operating environment (the connection to Akio Toyoda’s observation about the amount of test required for Level 5 should be obvious).

In an automotive context, Siemens and Mentor see this as a ‘sense, compute, actuate’ process. It is also the kind of virtualized environment that leverages the benefits behind the idea of The Digital Twin.

Figure 3. Sense-compute-actuate: Emulation in context with other solutions (Mentor/Accellera)

Next steps

So, having taken a bird’s eye view of the issues that automotive design faces, the next part of this feature looks at the specific use of HLS in the context of the Tiny Yolo CNN for optimization and refinement as might take place on a still more complex automotive project.

The other big takeaway from all this, as we shall see, is that while HLS and emulation can play major roles in delivering projects more efficiently to the highest safety standards, they do so – as ‘sense, compute, actuate’ suggests in the context of a much broader portfolio of tools. This will become particularly evident in terms of safety as well as any digital twinning that can be exploited.