White paper - MathWorks

Generating Hardware Descriptions from Automotive Function
Models for an FPGA-Based Body Controller: A Case Study
Matthias Traub
Daimler AG, Research & Development
Oliver Sander, Arik Rathner, Prof. Jürgen Becker
ITIV, Karlsruhe Institute of Technology (KIT)
ABSTRACT
Today's innovations in the automotive sector are, to a great extent, based on electronics. New features are often realized
solely on embedded electronic devices. Therefore, developers are facing higher demand in the field of electric/electronic
architecture. Actually more and more applications are developed using Model-Based Design in the automotive domain.
While C code generation is already used in series development, no satisfying solution for VHDL or Verilog generation was
available on the market yet, for example, to generate hardware description language (HDL) code from Simulink® or
Stateflow® models. Simulink® HDL Coder from The MathWorks introduces this ability. The tool offers the ability to
divide model-based functions into hardware- and software-modules. Advantages are flexible system partitioning and the
ability to accelerate time-critical applications in a hardware unit. A case study for such a system is presented in this paper.
In a cooperation project between the Karlsruhe Institute of Technology (KIT) and Daimler AG, a field programmable gate
array (FPGA)–based body controller unit (BCU) was developed, including automatically generated HDL code.
INTRODUCTION
To fulfill the increasing requirements of electric/electronic architectures in the automotive environment, new concepts for
future electronic control units (ECUs) are necessary. Novel semiconductor technologies for such a system offer much
higher potential in terms of performance compared with higher clock rates in standard microcontroller devices. The
following case study introduces the benefits of a new concept for a BCU. The system is realized on reconfigurable
hardware, more precisely on an FPGA, and is integrated in the SL-Class from Mercedes-Benz.
Since 2001 the research department of Daimler AG has been working on a cooperation project with the Institut für
Technik der Informationsverarbeitung (ITIV) at the Karlsruhe Institute of Technology. The focus of this project has two
aspects. The first is the usage of dynamic reconfiguration for automotive applications [1]. The second is a new gateway
concept based on an FPGA for automotive networks [2]. This system approach offers much higher routing performance in
comparison to gateways that are realized on a microcontroller. The FPGA-based gateway concept is also part of a case
study for a BCU, which is discussed later in this paper. For the applications that are running on the BCU, we have
evaluated a hardware/software codesign process for automotive applications, including Simulink HDL Coder.
Current and future BCUs must fulfill mainly two tasks. The first task is the routing of information between the controller
area network (CAN) bus of the body domain and the several LIN subbuses that are connected to the BCU. The second
task of the BCU is to handle the huge amount of applications that are integrated on it. BCU functions include, for example,
the window lifter, the mirror control, and the front light, to name only a few. For our BCU approach we use two methods
for the integration of applications. First we apply softcore processors such as MicroBlaze from Xilinx [16] or Nios2 from
Altera [17] for the applications. Second we integrate several functions in hardware. The toolflow for such a
hardware/software codesign is one of the main aspects in our case study. Actually, more and more automotive functions
are developed using Model-Based Design. Therefore, we use the embedded code generation of Simulink for our function
models. We generate C code for the software modules that run on a processor and HDL code for the application
modules, which are accelerated in hardware.
The remaining paper is organized as follows: In the next section some technical basics are discussed to provide a
common comprehension. The subsequent section introduces the case study. It starts with the system concept, gives an
overview of the design flow used, and discusses an implementation example. The last section provides the results of the
work and gives an outlook.

NETWORK ARCHITECTURE
Today up to 80 ECUs are used in premium cars. In order to guarantee reliable communication between them, complex
networks are necessary. Actual automotive network architectures partition the ECUs into different domains depending on
their functionality (body, chassis, powertrain, infotainment, etc.). For the requirements of the different domains, several
protocols are available. The CAN bus protocol is primarily used for inter-ECU communication. It is an event-driven
multimaster protocol that is not deterministic [11]. The main fields of application for CAN are the body, chassis, and
powertrain domains. Local Interconnect Network (LIN) is a low-cost protocol used for communication among simple
modules such as switch panels [12]. It is deterministic and easy to implement but features low speed only. FlexRay is the
youngest communication standard for automotive networks. It consists of a deterministic and nondeterministic part. It
offers higher throughput compared with CAN and is designed for X-by-wire and backbone applications [13]. Media
Oriented System Transport (MOST) is a communication protocol used for infotainment devices [14]. Additionally Ethernet
will become the diagnostic entrance to the car in the future [15].
FIELD PROGRAMMABLE GATE ARRAY
Reconfigurable hardware such as FPGAs offers many advantages in comparison to fixed architectures. A single device
can be used for numerous and very different tasks by adapting the hardware to the task during design, and even during
runtime. It is very suitable for rapid prototyping but also for limited-lot production of systems if the design of an ASIC is too
expensive or time-consuming. Quite a few reconfigurable hardware platforms are available (for example, Cypress's PSoC
Mixed-Signal Array, Actel Fusion, CPLD, FPGA).
An FPGA is a semiconductor containing programmable logic components called configurable logic blocks (CLBs) as well
as programmable interconnects. The logic function of the block is implemented using look-up tables (LUTs). These are
one-bit-wide memories whose inputs are interpreted as address lines. The one-bit content of the addressed memory is
used as the LUT's output. Thus the CLBs can be programmed to perform any combinatorial function by loading the
appropriate values in the LUT's memory addresses — only constrained by the CLB's number of inputs and outputs.
Through programmable interconnects, so-called switchboxes, CLBs can be interconnected to form very complex digital
circuits and designs. In data-driven applications FPGAs are therefore able to heavily parallelize tasks, thus speeding up
an application substantially. By including a softcore processor, functions can still be carried out in software. At the same
time it is possible to partition functions over software and hardware to exploit the distinct advantages of both and build
complete digital systems-on-chip (SoCs) including functional blocks and their communication infrastructure such as buses
or complete networks-on-chip (NoCs). Configuring FPGAs is done by writing a bitstream to the device over a
programming interface, for example, the JTAG. The LUTs are loaded with appropriate values and the switchboxes are
programmed. Most of the FPGAs are SRAM based (for example, from Xilinx); therefore, loading a bitstream is mandatory
after every power-up in order to have a working system. The bitstreams are usually stored in external flash memory. In
newer devices, memory has been integrated into the FPGA's package, decreasing the need for external memory
components. A bitstream is loaded into the device, initializing the FPGA's look-up tables, internal memory blocks, and
switchboxes to form the chip's digital functionalities.
SIMULINK HDL CODER
Simulink HDL Coder offers the ability to generate synthesizable HDL code from Simulink models and Stateflow charts
[10]. The generated HDL code is target independent. On this account, the generated code can be mapped on an FPGA or
an application-specific integrated circuit (ASIC). Furthermore, Simulink HDL Coder generates test benches, which enable
rapid verification of the generated model using HDL simulation tools such as ModelSim from Mentor Graphics [9].
CASE STUDY
One trend for network architectures in the automotive field is the use of powerful ECUs to realize high function integration.
The main benefits are a reduction of the number of ECUs and better system integration. The BCU of the body domain is
one example (see Figure 1). With the introduction of the LIN bus, new function integration and partitioning are possible.
Figure 1. Actual trend, for example, in the body domain.

In our case study we built such a BCU concept. Based on the network architecture of an existing car, we changed the
partitioning of the architecture. In our project we focused on a part of the comfort domain. The reduction of ECUs was one
main aspect. Another issue was the use of an FPGA as the central computing unit for the BCU prototype. Therefore, we
faced questions of hardware/software codesign for model-based functions. The system example was integrated in the SL-
Class from Mercedes-Benz (DATE). The key aspects of our case study are to find out and understand the necessary
design flow for such systems and to identify differences for the development and qualification process between a
microcontroller and an FPGA-based ECU.
SYSTEM CONCEPT
System partitioning is done on two abstraction levels. First, we define the overall system architecture. Second,
hardware/software partitioning for the central body controller is made. All decisions are based on a functional analysis of
all user-related functions we want to exchange. In principle all body-domain-related functions should run in the BCU. No
additional ECUs are necessary despite small intelligent sensor and actuator modules that communicate with the BCU via
the low-cost LIN bus. In fact we restricted ourselves to a selection of functions, normally located in the door modules and
the roof control ECU. The former are removed from the car; the latter is running in a special mode. The functions of the
removed CAN ECU are implemented in our concept on the BCU. In addition routing between our novel architecture and
the other domains must be handled by the BCU.
The overall function distribution is based on the architecture shown in Figure 2. Two CAN and four LIN buses are
attached to our BCU prototype. The first CAN bus is the existing body CAN, which is the interface to the remaining
electronic architecture of the car. We introduced four LIN buses for our smart sensor and actuator modules. Two of these
buses wired to the front doors with two LIN slaves in each door. The remaining two buses are attached to the rear power
window devices. Of course, fewer LIN buses would be sufficient. However, we decided to demonstrate modularity and the
ability of our FPGA system architecture to run several buses in parallel. To save time we did not realize the analog LIN
interfacing to the roof components on our own. This is the reason a second CAN bus is connected to a special version of
the roof control ECU. This special ECU allows controlling actuators and reading sensors via CAN bus over diagnostic
messages.
Figure 2. System concept.
In general we tried to concentrate as much functionality as possible in the central FPGA system. Only low-level functions
such as debouncing are integrated in the local LIN modules. The antipinch protection of the window lifter is the only
exception. This function is integrated in the LIN slaves. The reason for this partitioning is the performance of the LIN bus,
which does not fulfill the required latency time.
The system demonstrates how standardized sensor and actuator modules could look. The modules used in our project
are a development of Siemens VDO. Moreover, this concept introduces a possible system partitioning approach for
applications in the body domain. Low-level functions, which are application independent, and a standardized bus interface
are integrated in the sensor or actuator module. All these functions can be attached in one single package that probably
builds a small SoC. All application-specific functions are implemented on the BCU. The LIN modules can be used as
convertible standard components possibly delivered by different suppliers. These components can be set up for the
application by parameterization. On the BCU side the interface to the physical world is quite simple because no low-level
functions or analog parts are necessary. Information exchange is based on message transport level via LIN or other bus
systems.

As already mentioned the roof control is the most important function in our system approach, running on the BCU.
Moreover, some higher-level power window control functions are integrated. This includes switch prioritization as well as
monitoring of system conditions (for example, clamp 15). Power management for the LIN nodes is also implicitly done in
the BCU. When scheduling is stopped, the LIN modules fall asleep after a given time. The BCU is master for all LIN
buses. We have integrated parts of the seat control because the control buttons are placed inside the door. The seat
control itself is not realized in our system. Furthermore, the mirror control function runs in the BCU. Some routing tasks
are also realized in the BCU.
The basis for the BCU is an FPGA-based gateway system, which we have already developed within another project. The
evaluation board for the BCU has four CAN and four LIN interfaces. The FPGA is a Spartan3 XC 3S5000 from Xilinx.
Siemens VDO designed the LIN modules for this case study.
Most functionality is integrated in a softcore processor. To evaluate hardware toolflows we decided to test two
implementations of the roof control functionality. The functionality is modeled in MATLAB®, Stateflow, and Simulink. In
our first version, software code was generated and integrated into the softcore processor. Our second version is realized
in hardware. The roof control function runs in parallel to all remaining functions, thereby not influencing other tasks. The
hardware model is also generated from the MATLAB model. The toolflows we used will be described later on. The
interface to our internal communication system has to be done by hand. However, the generated model was not changed
and its behavior is equivalent to that of the model and the software version. In fact we can switch between both
realizations.
Figure 3 shows an abstract overview of our system approach. The system is built by plugging several modules together.
This flexibility is mainly achieved by the central communication structure and a well-defined interface. Four functional
parts can be seen in Figure 3. On the bottom are the bus interfaces to CAN, LIN, and USB. We used USB for debugging
and flashing purposes only. On the upper left is the roof control function, which can be split into three parts (roll bar
control, load help control, and convertible top control). The upper central element is the softcore processor, which runs all
the software applications. In our approach we use a MicroBlaze processor from Xilinx as the softcore processor. The
modules on the upper right are responsible for fast and efficient routing [2].
Figure 3. FPGA-based body controller.
Communication Structure
The communication between the individual modules of the BCU is of paramount importance for the overall system
performance. We decided not to implement a memory-mapped address-based communication structure. In this
application a very simple network on chip (GNoC) approach was used. It is a combination of a bus topology with network
packets being sent. All modules are equal and can receive and send data packets independently. Mechanisms for
broadcast and unicast exist. Our communication structure supports easy adding and removing of modules.
Bus Interfaces
The bus interfaces include the protocol engines as well as low-level bus-related functionality. For example, the bus off
repair procedure of the CAN bus is processed without affecting other modules. We implemented interfaces for CAN, LIN,
FlexRay, and Ethernet; the latter are not a topic of this case study. These transferred messages are buffered in the
modules. The operation mode of the system does not depend on the bus type. The messages that have been received

are broadcast to the internal communication network. The messages, which have to be sent to the attached buses, are
received from the internal communication structure. The internal forwarding of the information on the bus happens as fast
as possible.
Message RAM and Routing Engine Modules
In our system approach, two modules process all gateway routing tasks. The Message RAM module forwards messagerouting
messages and sends all signal-routing messages. Cycle times as well as timeout handling are controlled by this
module. Despite timeout values the data fields are not altered by the Message RAM module. Whenever the content of a
message needs to be changed, for example in case of a signal-routing or bus conversion, another module, the Routing
Engine module, is involved. The main task of the Routing Engine module is to group several signals from many messages
into a new message. Signals are concatenated with hardware support with the new data field as a result. Further
processing is done by the Message RAM, which takes care of all messages’ behavior (cycle times, timeout values, etc.).
Processor System
All parts of the software stack with the exception of the bus drivers and gateway functionality are implemented in the
application module. The main part of the module is a softcore processor (see Figure 4). We use the MicroBlaze processor
from Xilinx and some peripheral elements. In our application a timer, the NoC interface, a UART peripheral (debugging),
and the memories are attached to the processor. We decided to use a simple runtime system instead of a complex OSEK
version for availability reasons. The runtime system implements no preemption. Tasks are called in certain time slots, and
each of them ensures running within the allotted time. If a message is received, the corresponding signal values are
immediately updated by an ISR. Incoming signal values are available for all tasks. We have the following tasks running:
window lifter, seat control, switch prioritization, and roof control (in our software version). The latter includes some
managing tasks of our special roof control ECU. If the hardware implementation is used, the roof control forwards all
controlling signals directly to the hardware implementation.
Figure 4. Softcore processor system.
Hardware Module
The hardware implementation of the roof control is mainly based on the generated VHDL code of the roof control. The
entire hardware module is shown in Figure 5. Of course, the behavior of the system should be the same as that of the
C code version. This was ensured by simulation comparing the output signals for given test cases. As the hardware is
running much faster than the software version, timeout values are extremely different (a factor of 24k). To overcome this
resource-consuming implementation, the model is simply executed less often. As the timer values are originally defined
for the software version in terms of milliseconds, we decided to do a mixture of executing the model less often and
adapting the timeout values of the original model.
Inputs and outputs of the VHDL model are the same as in the software version. These fit neither directly to the MicroBlaze
processor system nor to our internal communication structure. We implemented an interface for the second variant. We
chose this version for two reasons. First, the function can run processor independent, thus reducing the workload of the
processor. Second, the module can easily be added or removed from the internal communication structure without

affecting the other modules. Moreover, the GNoC has a well-defined interface that allows independent testing of the
module.
Figure 5. Hardware module.
Attaching the VHDL model to the GNoC is mainly done by a very small 8-bit processor core (PicoBlaze) not comparable
to 8-bit microcontrollers. The decision for this solution is based on its resource efficiency and flexibility while providing
enough computational performance for the glue logic task. Incoming NoC packets are filtered. The information is targeted
to the roof control function and stored in a special register file. This is read by the hardware task the next time it is
executed. Outgoing information is also transmitted to our small processor. The processor packs the information into
GNoC packages, which will be transmitted to the internal network. Depending on the information, the message is further
processed by the routing modules or in special cases by the application module.
DESIGN FLOW
Identifying and understanding the necessary design flow for an FPGA-based BCU was one main aspect of our case
study. The established design flow for microcontrollers comprises the process for software components. The use of the
FPGA technology requires an extension of the existing design flow. To fulfill these needs, a hardware/software codesign
process must be introduced. A seamless design flow is very important for the development of automotive systems. The
identification and the definition of the interfacing of the different tools must be clear; otherwise, the launch of FPGA-based
systems in the automotive domain is improbable.
Figure 6 shows the design flow used for our system approach. The design process is divided into three paths. The first
path on the left side of the diagram contains the generation of the routing tables for the hardware-accelerated routing unit.
The software part is built in the second path. This part contains the basis software modules (for example, operating
system, system drivers, network management) and the software modules of the application. The right path comprises the
hardware system. Parts of it are the softcore processor, the chip internal communication structure, the bus interfaces, the
routing unit, and the generated application modules.
Most of the applications for the BCU are modeled with Simulink and Stateflow. The software or hardware modules can be
generated by means of code generation, which is part of Simulink. Afterward, the generated modules can be integrated,
depending on their type, in the software or hardware development environment (DEV). The software modules (in C code)
must be integrated on the softcore processor; in our example, it is a 32-bit MicroBlaze processor from Xilinx. The
integration process for the software modules is well known because there is no difference to the design flow for
microcontroller-based systems.
For the automatically generated hardware modules of the applications, the integration process is not established yet in
the automotive field. In our project we have done the design of the hardware part as follows: In the first step the softcore
processor system is built. In the next step this system is coupled with a generic interface of the internal communication
structure. In the hardware DEV the entire system must be integrated, which includes the processor system as well as the

outing unit, the communication interfaces, the internal communication structure, and the hardware application modules,
which are provided by a special library. In the last step the hardware system can be synthesized.
Figure 6. Design flow.
IMPLEMENTATION EXAMPLE
In our case study we have evaluated different approaches for the integration of applications on the BCU. In the first
approach we integrated the entire functionality in software on the softcore processor. In the second approach a part of the
application is implemented in hardware. Among others, this was done for the convertible roof control, which is described
in this section. The demonstration car was from the SL-Class from Mercedes-Benz and has an electrohydraulic roof. The
top opens and closes within 20 seconds. Twelve switches act as sensors for the top control. The actors are seven
hydraulic valves, which are coupled at one pump. The simplified Simulink model of the roof control is shown in Figure 7.
In one variant of our system the top control is integrated on the softcore processor. In a second variant the top control is
realized as a hardware module. Table 1 shows the necessary hardware and memory resources for this module (the
results are based on a Spartan3 FGPA of Xilinx). The hardware module is generated with Simulink HDL Coder from The
MathWorks and synthesized with Integrated System Environment (ISE) software from Xilinx. The module needs 1161
slices on a Spartan3 FPGA from Xilinx. In comparison to the size of the MicroBlaze 32-bit softcore processor, which
allocates about 700 slices, the hardware module of the roof control is inefficient in hardware. We got this result with most
of the application modules. However, the use of automatically generated hardware models has some benefits. The
modules run in parallel and do not influence each other. Moreover, a hardware implementation offers much more
computational power, which can be useful for tasks with high computational demands (for example, multimedia). The
given performance can also be used for ECU prototyping purposes.

Figure 7. Simplified model for the convertible top control.
Hardware Module
(Slices)
Software Module
(KB)
Convertible top function 1162 3.552
Table 1. Comparison of hardware and software realization of the roof control.
In general, the control-flow-based functions need a lot of logic elements in hardware. Therefore, the realization of the
application modules in software is the better way. For functions that must handle a high data volume (for example,
gateway systems or video processing units), a hardware realization can be very performant and resource-efficient.
Examples of such a hardware acceleration unit are the routing modules of our system approach. For CAN-CAN message
routing, the systems needs about 8 ms at a system clock of 24 MHz; compared with a software-based solution (120ms at
80 MHz), the performance benefit of such a system is significant.
CONCLUSION
In current and future electric/electronic architectures, the integration of applications on powerful ECUs is a trend. These
powerful computing units offer the opportunity to reduce the number of ECUs inside a car. Furthermore, the high
computing power enables the possibility to integrate new innovations of automotive applications. The usage of
reconfigurable hardware gives an interesting alternative to the well-known microcontroller-based solutions. A modular
body controller prototype based on FPGA technology was developed and realized in this case study. The prototype
utilizes the advantages of this technology such as parallelism and modularity. The main focus of the project, namely the
integration of several functions on one powerful computing unit and usage of Model-Based Design, is presented in this
paper. Our future work will focus on open questions regarding qualification, toolflow, and the evaluation of the FPGA
technology for integration in AUTOSAR.
REFERENCES
1. J. Eisenmann, J. Luka (Daimler AG), J. Becker, M. Hübner (Karlsruhe Institute of Technology); “Dynamic
reconfiguration for automotive applications”; Design Automation and Test in Europe (DATE) Conference 2005 in
Munich
2. O. Sander, M. Hübner, M. Dreschmann, J. Becker (Karlsruhe Institute of Technology), M. Traub, J. Luka, T. Weber
(Daimler AG); “Modular system concept for a FPGA-based Automotive Gateway”; Elektronik im Kraftfahrzeug, VDI-
Conference 2007 in Baden-Baden
3. J. Eisenmann, J. Luka (Daimler AG); “FPGA-based Electronic Control Units for Comfort Systems in Vehicle”; Design
Automation and Test in Europe Conference 2006 in Munich
4. M. Traub, J. Luka, V. Lauer, T. Weber (Daimler AG), O. Sander, M. Hübner, Prof. Becker (KIT); “Standards for
Electric/Electronic Components and Architectures”; to be published at Convergence 2008 in Detroit
5. Arik Rathner (KIT); “Approach for a FPGA-based BCU”; seminar paper 2007
6. www.mathworks.com
7. www.xilinx.com
8. www.autosar.org
9. Mentor Graphics; “User Handbook for ModelSim”; Version 6.0, 2007
10. The MathWorks; “Simulink HDL Coder User’s Guide”; 2007
11. Robert Bosch GmbH; “Controller Area Network Specification”; Version 2.0, 1991
12. “Local Interconnect Network Specification”; Revision 2.0, 2003
13. “FlexRay Communication System, Protocol Specification”; v2.1, Rev. A, 2006
14. MOST Cooperation; “Media Oriented System Transport Specification”; Rev. 4, 05/2005
15. Bernd Schürmann; “Grundlagen der Rechnerkommunikation”; Vieweg Verlag, ISBN 3-528-15562-0, 2004
16. Xilinx; “MicroBlaze Processor Reference Guide”; UG081 (v7.0), 2007
17. Altera; “Nios II Processor Reference Handbook”; NII5V1-6.1, 2007