Why Designing an FPGA makes a Difference for Automotive Engineers
The automotive industry is currently working hard to fulfil the end user’s dream of autonomous driving. This is a dream that has been around for quite some time and now seems to be achievable within the next decade. While legislative hurdles still exist, there still exist legislative hurdles that need to be taken into account, the technological questions seem to be answered for the most part: Radar, Lidar-, ultrasonic and camera sensors can provide all of the required data of the vehicle’s surrounding environment that would be necessary for autonomous operation. The fusion of all of this sensor data, the appropriate vehicle control algorithm, and the Human-Machine Interface (HMI) are areas remain fields where more effort is required to make autonomous driving achievable.
Devices like the Xilinx Zynq-7000 All Programmable SoC are enabling these modern systems by delivering unsurpassed processing power, leading performance to power ratio, with and the option to up/downscale the design within the device family according to the specific project requirements.
However, for developers not familiar with this kind of technology, using a device like the Zynq AP SoC may look like rocket science compared to the conventional flow of developing software for an MCU or DSP. While developing software for Zynq may be more complex due to the nature of the device, providing more flexibility with the same principles for software development or coding still apply. Another reason why companies are sometimes reluctant to adopt new hardware architectures is the fact that most companies employ four times more software developers than hardware developers, and even within the latter group, only a handful would consider themselves as experts in a hardware description language, like VHDL or Verilog, to design an FPGA/ Programmable SoC. In reality today, intelligent tool chains can automatically add parallelism and pipelining to a sequential description, and advanced profiling can guide the programmer towards more efficient and higher performance implementations of their design.
In the majority of designs, reaching the right balance between performance, power dissipation and device cost – according to the system specification – is the goal designers need to achieve. Development tools like the Xilinx Vivado IDE have already taken over multiple tasks during the design phase with respect to optimization and/or IP integration.
How Programmable SoCs Allow Virtual Development
Dependent upon the complexity of the system, series development starts between 18 and 36 months before the start of vehicle production (figure 1).
Figure 1: Development Lifecycle for Automotive Embedded Systems. For full resolution, click here.
With the exception for certain parts of a design, such as algorithms that which are developed on PC-based systems, the software development for a given project usually cannot start before a decision on the target hardware is made. However, at the point in time when this decision is to be made, it’s almost impossible to exactly determine the performance requirements as most software function blocks??? aren’t available yet – sometimes not even known yet as features usually get added to the development project along the way.
So deciding on a specific, non-scalable hardware platform carries a high risk for running into performance issues later or at least – in case the added safety margin for potential higher-than-expected performance requirements was chosen too large – the solution is commercially sub-optimal.
The development lifecycle in Ffigure 1 shows that the usual B sample hardware requirement is based on the final device/silicon with the only difference being that device qualification (in most cases according to AEC-Q100 at a minimum)is not required before building the C sample hardware.
So, how can using a device like the Xilinx Zynq-7000 AP SoC positively impact this development cycle? The Zynq-7000 family for automotive applications consists of three devices. While the processor systems of these devices are identical, the programmable logic parts differ in size (and therefore the individual number of each processing resources varies). Knowing this, the development engineer can start using a large device like the Zynq-7030 for prototyping or A sample hardware while eventually targeting a Zynq-7020 for final series development. The Zynq-7030, due to its number of resources, allows integration of all functions required for the final design – even if parts of this may not yet have been optimized for this architecture – as well as the diagnostic functions needed during the development phase. Also, software development can be initiated right away as the processor systems in both devices are identical.
Another benefit of the Xilinx Zynq-7000 AP SoC comes into play at a later stage. Assuming the system based on a Zynq-7020 is already deployed into the field and the OEM wants to integrate an additional feature, unlike microcontroller based systems where adding another piece of software may lead to a drop in performance (potentially violating real-time requirements), the Zynq-7020 can be loaded with either an additional hardware accelerated function or an additional piece of software. Of course, the processor cores of the Z ynq-7020 can also reach its performance limit, however, the flexible architecture of the device allows for a versatile hardware/software partitioning, meaning certain software functions can be offloaded into hardware functions in the FPGA fabric, freeing processor bandwidth for a new feature.
If the hardware processing needs exceed the resources available in the programmable logic, the designer could potentially switch to the next larger device – in this case a Z ynq-7030. As the processing system is the same as in the Zynq-7020 most of the software (OS, drivers) can remain unchanged and only the new features need to be added.
Demystifying FPGA/SoC Ddesign
Although the classic VHDL/Verilog based development flow for FPGAs is widely used, using a higher abstraction level brings advantages in certain cases. For instance, many algorithms that are used to analyse the data coming from radar or video sensors – the common sensor data source in ADAS – usually are coded in C/C++ language. Re-writing them in VHDL would not only be a significant effort, but could also increase simulation time dramatically (Figure 2).
Figure 2: A C-based approach can help to speed up verification time significantly.
Also, in the case where a developer is already familiar with a language like C or C++, switching to an unknown programming concept may lead to an inferior implementation result or at least add unnecessary delay in the development cycle. When looking at a device like the Xilinx Zynq-7000 AP SoC, the advantages for a C/C++ based development flow become even more obvious. Instead of working with two development flows – C/C++ for the software algorithms running on the ARM® core and VHDL/Verilog for the functions implemented in the programmable logic part – going with a C/C++ flow only is more convenient.
Because of this challenge, Xilinx has implemented a new design flow that allows the design of hardware and software functions for Zynq running completely on C/C++ (Figure 3).
Figure 3: Flow of the All Programmable Framework allowing C/C++ code to be used for generating software or hardware
This new design methodology called High-Level-Synthesis (HLS) consists of a new system level, heterogeneous parallel programming environment that leverages abstractions such as C/C++ or OpenCL, in an Eclipse based development environment. Here the user can determine which program modules he wants to accelerate and the tools automatically handle the compilation, communication and cooperation between the processing system (software modules) and hardware accelerators.
Decisions about hardware/software partitioning can be made according to system requirements like performance requirements (real-time), maximum power dissipation or even cost considerations. Also, these decisions can be changed along the way until the optimal system set-up is found.
A simpler version of this design flow can also be used for standard FPGAs that do not contain an ARM core to run software on. In this case, the development engineer can generate hardware IP from algorithms without RTL design experience using C, C++ or SystemC and then integrate it – potentially together with an already existing subsystem or third 3rd party IP – into the target device using a tool called Vivado IP Integrator (Figure 4).
Figure 4. Vivado IP Integrator provides a graphical and Tcl-based design development flow
Summary
FPGAs and All / Programmable SoCs have become key components in many automotive embedded systems, especially in ADAS. Now with this evolution in tool support, allowing users to develop IP, subsystems or even complete FPGA/ Programmable SoC designs using a high-level language, the base of potential applications is becoming even broader. It is not just that designing an FPGA or All /Programmable SoC is becoming a lot simpler, but also the line of differentiation between hardware and software is blurring, allowing the development engineer to design a system exactly to meet the specific features and functions of the OEM automaker.
About the author:
Stephan Janouch is Senior Manager Automotive Marketing EMEA at Xilinx.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
