An Automated Flow for Integrating Hardware IP into the Automotive Systems Engineering Process Jan-Hendrik Oetjens Ralph Görgen Joachim Gerlach Wolfgang Nebel Robert Bosch GmbH OFFIS Institute Robert Bosch GmbH Carl v. Ossietzky University AE/EIM3 R&D Division Transportation AE/EIM3 Embedded Hardware-/ Postfach 1342 Escherweg 2 Postfach 1342 Software-Systems 72703 Reutlingen 26121 Oldenburg 72703 Reutlingen 26111 Oldenburg Jan-Hendrik.Oetjens Ralph.Goergen Joachim.Gerlach nebel@informatik. @de.bosch.com @offis.de @de.bosch.com uni-oldenburg.de Abstract during system integration is possible in an earlier stage of the systems engineering process. This contribution shows and discusses the require- Most of the companies’ system development processes ments and constraints that an industrial engineering follow – at least, in their basic principals – the well- process defines for the integration of hardware IP into known V model [1]. In our specific case, there is running the system development flow. It describes the developed an additional boundary through that V model. It partitions strategy for automating the step of making hardware de- the process steps into tasks to be done within our semi- scriptions available in a MATLAB/Simulink based system conductor division and tasks to be done within the corre- modeling and validation environment. It also explains the sponding system divisions (see Figure 1). The prior men- transformation technique on which that strategy is based. tioned acts as a supplier of the hardware parts of the over- An application of the strategy is shown in terms of an all system for the latter. Such boundaries also exist in industrial automotive electronic hardware IP block. many other companies whereas the exact boundary shape in the V model may differ. In our case, the system divi- sions are responsible for the engineering of the system 1. Introduction application, the definition of the coarse grain system ar- chitecture and the assembling of the system by integrating The domain of automotive electronics system design is all components (mechanical parts, sensors, hardware IP, characterized by specific constraints and environmental software, etc.). An aspect that arises from that partitioning conditions that significantly differ from those in other is that both sides, systems engineering and semiconductor design domains like mobile communications, multimedia development, have different views on the system and its or high performance computing. This results from the fact constraints, different understandings and know how, and that automotive electronics systems are often involved in different design methods, tools, and environments. This safety critical car functions that have to be highly reliable makes a seamless interaction of both sides an ambitious and robust over a long lifetime, and are used in harsh en- and highly important challenge. vironments in terms of vibrations, temperature changes, or electromagnetic interferences. These specific con- System System Design Test straints have to be considered during all steps of the System automotive electronics systems engineering process. This Engineering contribution describes a methodology developed at the Architecture Integration semiconductor division of Robert Bosch GmbH in coop- Design Test eration with OFFIS Institute for Information Technology, Design Semiconductor which provides a seamless and automated strategy for Development making intellectual property (IP) hardware models avail- Module Module able on higher levels of model abstraction. This allows Design Test Validation considering hardware IP accurately during the system modeling and exploration phase. Hence, the identification of incorrect system behavior or problems that may arise Implementation Figure 1. V model for system engineering 978-3-9810801-5-5/DATE09 © 2009 EDAA In automotive electronics system design, the modeling ual coding step is time-consuming and error-prone. Addi- and validation of heterogeneous system behavior on a tionally, the effort to keep the hardware description and high level of abstraction (at the systems engineering the Simulink model compliant (e.g., after several adapta- level) is often done using MATLAB/Simulink. For the tion or configuration steps on hardware side) is quite design of the integrated circuits (at the semiconductor high. Therefore, this step is often skipped in practical use development level), traditional register-transfer level due to the tape-out schedule, which is a handicap for an hardware description languages like VHDL and Verilog efficient reuse. play a major role. Regarding the “design” arc of the V model a typical strategy for crossing the boundary be- 3. Related work tween systems engineering and semiconductor develop- ment can be divided in two steps. Firstly, a natural lan- Because co-simulation and manual generation of C guage specification document is derived for the system code are often not applicable in practical use, an approach parts to be implemented in hardware from the Simulink for the automatic generation of C/C++ code from hard- model (to be done at the systems engineering level or in ware descriptions is necessary. Tools for generating C++ tight cooperation of both levels). Secondly, engineering code that can be embedded into a Simulink environment of the hardware component is started (at the semiconduc- already exist on the market. Known commercial ap- tor development level) based on this document. Vice proaches in this area are VTOC [2] and Model Studio [3]. versa – regarding the “validation” arc of the V model – VTOC is a model generator that allows generating C++ the hardware component can be considered at systems models from Verilog hardware descriptions. The gener- engineering level at the earliest after the whole hardware ated models can be embedded into HDL or SystemC envi- development task has finished and all system components ronments via wrappers for the Verilog PLI (Program Lan- are available for their integration in a physical prototype. guage Interface) and SystemC. The model generator This means that a more accurate Simulink model of the Model Studio allows generating and validating software developed hardware IP, which would allow starting the models. Models created by this tool can be embedded into system validation task already at model level, does not several system level design tools as well as HDL simula- exist. This lack becomes more dramatically in the context tors and SystemC environments. An API is generated, of current system-level design methodologies like plat- which provides visibility to the model’s content. form-based design or component-based design. There- Both approaches do not intend to produce user- fore, an efficient reuse of existing hardware IP is highly readable code. Whereas user-readable code is required if crucial. a manual transition to a more abstract modeling of parts The paper is organized as follows: In section 2, exist- of the generated code is planned. These parts may be ei- ing strategies for implementing cycle-accurate Simulink ther performance-critical or their RT-level implementa- models are discussed. Section 3 outlines related work in tion is insignificant for the system model’s application the automatic generation of executable models from HDL (ALUs, memory banks, protocol interfaces, etc.). Some code. Section 4 presents our approach using a conversion non-commercial approaches generate SystemC code that into a SystemC model and its integration into Simulink. allows manual adaptations [4] [5]. This class of tools is The described approach was used to integrate an automo- characterized by a mapping of a subset of an HDL to al- tive hardware IP into Simulink, which is presented in sec- most equivalent SystemC code. The original HDL hard- tion 5. Finally, section 6 concludes with an outlook on ware description is reproduced by a generated code that future work. uses the available SystemC constructs. If there is no equivalent construct a comparable one is chosen, which is 2. Existing strategies functionally equivalent in most cases. Even if there is no comparable SystemC construct, the HDL construct is not Existing strategies to overcome this lack include the part of the supported subset. Thus, the supported subset of co-simulation of hardware descriptions and Simulink these tools is significantly smaller than the synthesizable models at systems engineering level. This is expensive in subset of the HDL. An equivalent behavior of the gener- terms of effort and costs because the expertise and envi- ated SystemC model is not guaranteed due to an impre- ronment for simulating hardware does usually not exist on cise language mapping. that level. In case of external customers, another aspect is that co-simulation usually requires the source code of the 4. SystemC-based approach hardware description, which might be critical due to non- disclosure reasons. Other strategies include the manual Our approach for an automated transformation of generation of C code descriptions for the hardware func- hardware descriptions into Simulink models also uses tionality to be embedded into Simulink via S-functions. In SystemC as an intermediate layer. The approach can be practical use, this is often not feasible due since the man- derived in two steps. In a first step, a VHDL hardware description is converted into a functional equivalent Sys- used to define the structure of the XML representation of temC model. This step is done using a company-internal a design for the particular language.