Verification Methodology of Sophisticated Automotive Sensor

Interfaces Integrated in Modern System-on-Chip Airbag System

Dipl.-Ing. Dr.-techn. Thang Nguyen

Automotive Power Train and Safety

Infineon Technologies Austria AG

Villach, AUSTRIA

Thang.Nguyen@infineon.com

+43 (5) 1777 6361

M.Sc. Andrei-Daniel Basa

Automotive Technology and Methodology

Infineon Technologies Romania

Bucharest, ROMANIA

Andrei-Daniel.Basa@infineon.com

+40 (31) 860 7714

Abstract — The tremendous growth in silicon integration

capability in recent years, together with the increasing demand of

safety requirements in automotive applications, led to the

integration of single units, constituting an automotive airbag

system into a single System on Chip (SoC) tailored to the specific

application and characterized by the complexity of its digital

core. The development of sophisticated digital algorithms for

airbag peripheral sensor data decoding, processing and

transmitting to the main airbag deployment event, requires also

the development of more complex processes for the verification of

these functionalities to meet the target of a first-time-right design,

which is strongly demanded in the modern automotive electronics

industry. In this context, the paper addresses the verification

challenges of such complex SoC products and presents a novel

verification setup suitable for the verification of complex

automotive sensor interfaces integrated in a modern airbag SoC

system interacting with analogue hardware with the aim to

bridge the gap between ―speed‖ and ―accuracy‖ of classical

simulation of complex ICs. The verification setup includes a full

event-driven simulation at system level and an FPGA with an

analogue test chip prototype for the acceleration of the

verification. At an early phase (before product tape-out), the

setup allows not only to verify the design against its specification,

but also to verify the product in its application context – in-

circuit verification, helping customers to gain confidence later at

the system integration process. Therefore it significantly

improves the quality of the whole design chain as well as the

time-to-market.

Keywords: mixed-abstraction modeling, chip top-level

functional verification, embedded mixed-signal System-on-Chip

application, hardware and firmware co-verification, airbag System-

on-Chip, event-based simulation.

I. INTRODUCTION

A. Modern automotive airbag system application

The increasing number of airbags, having to comply with stricter safety standards (e.g.: ISO 26262), while costs must be reduced has brought automotive airbag system design to a new approach with SoC design. Typically a modern airbag system is a heterogeneous system comprised of sensors, an airbag ECU (Electronic Control Unit) – which consists of an airbag SoC chip set and an airbag main micro-controller (uC) – and actuators (Figure 1). The airbag ECU is hardware within a multiple airbags system, as it controls the deployment of multiple airbags within a car.

During operation the sensors, such as buckle switches, accelerometers or pressure sensors, mounted in key locations of the vehicle, continuously measure the positions of impact, the severity of the collision and other variables. This information is provided to the airbag SoC chipset in form of analogue signals, e.g.: modulated current, via the sensor interfaces. The airbag SoC chipset translates the analogue sensor signals into digital words. The translated digital sensor data is reported to the main uC via the SPI (Serial Peripheral Interface) communication. Based on this information the airbag main uC decides if, where (location) and when the airbag (e.g. actuators) is deployed. In case of deployment, the main uC sends deployment request SPI commands to the airbag SoC chipset, which drives the deployment interfaces (Squib drivers) of the airbag ECU, allowing a high analogue current of up to 2.2A to different squib resistors. Accordingly, these squib resistors are heated up by the high current, which activates the chemical reaction of the chemical compound around the resistors and results in an airbag explosion.

Airbag SoC

Main

µC

Satellite Sensors (upfront & side impact, g-sensor,

buckle switches...)

Airbag ECU

Actuators (Squibs)

Airbag System Overview(Sensors <--> Controller <--> Actuators)

SPI_IFanalogue

analogue

Figure 1: A typical airbag system from bird’s eye view

As all electronic systems, SoC hardware architecture consists of processing elements (processors that run embedded software, so called firmware or functional-specific hardware accelerators), IO devices, storage elements and interconnection structures linking all elements together. According to [1],[2],[3],[4] and [5] the most fundamental characteristic of an SoC is its complexity.

B. The airbag SoC functionalities and the design complexity

Shown in Figure 2, integrating an automotive airbag electronic system into a single SoC controlled by a main uC

978-1-4799-0224-8/13/$31.00 ©2013 IEEE 2335

makes the airbag SoC a very complex device. The main functionalities of the airbag SoC chip include the following:

Intelligent supply management unit consists of Switched Mode Power Supply modules - SMPS (buck and boost converter), the internal Power Supply Generator – iPSG and a CENTRAL power supply control logic, which controls the chip power up and power down stage and monitors the system supply integrity. It provides also logic for failsafe state diagnostic in case of integrity violation.

Remote sensor interfaces supporting different sensor types ranging from acceleration to rotational sensors and compliance to various standards such as PSI5 (Peripheral Sensor Interface) or DSI3 (Distributed System Interface).

Safing engine assisting the main uC in observing the sensor data transmission and in confirming if a deployment event has occurred.

Airbag deployment module – squib drivers and deployment enabling logic – allowing current for the ignition of airbags, covering requirements on deployment timing and current as well as load conditions diagnostic.

ModuleReg_IF

ModuleDigital Logic

Sub-System Digital (RTL)

A/

D_I

F

Digital CORE

SPIHW

DCORE FW

Digital_TOP (RTL)

CENTRAL_Dig (RTL)

(RTL)

SoC Power SupplyModels SoC_PWR

SE_ Safing_Engine

SE_Dig CORE

SPIHW

SE_AFEModel(VHDL)

(RTL) A/

D_I

F SMPS Modules(Buck/Boost

Converter)(VHDL)

iPSG(VHDL)

CENTRAL_AFE(Diagnostic and

Monitoring)Model(VHDL)

LVRs(VHDL)

Supply_net

rese

t

Su

pp

ly_n

et

Su

pp

ly_n

et

Airbag SoC Chipset TL Architecture

clk

72

M

iLVRs(VHDL)

Modules AFE(VHDL)

Remote Sensor_IF

SQB_Driver x Loops HS&LS

Vo

lta

ge

M

ea

sure

me

nt

Wa

tch

do

g Buckle SW

PWR_Train IF (CAN/LIN)

Main

µCSPI_IF

MCU XC23XX

16/32bits

On-Board Sensors

SMPS_Dig and LVRs_Dig (RTL)

Figure 2: Overview of the airbag SoC chipset top-level

implementation architecture

II. PROBLEM DEFINITION: CHALLENGES IN VERIFICATION

OF THE AIRBAG SOC SENSOR INTERFACES

These functionalities are distributed over both, hardware (digital and analog front end (AFE)) and firmware glued on high density logic digital CORE. As a result, this makes verification (computer-based simulation) and validation of the airbag SoC product and especially the sensor interfaces become a challenging task, mainly because of:

Verification for the airbag SoC and its sensor interfaces has to cover real-time embedded mixed signal domains.

Failure during the reception, decoding and processing of sensor data in the airbag controller system can originate unexpected or false deployment events of the airbag system, putting human safety in danger.

Most of the functionalities of sensor interfaces can only be verified at the system level of the chip and of the whole airbag system. The classical mixed-signal simulation approach becomes a bottle neck.

Many verification scenarios of the sensor interfaces such as long-term verification run with checking of millions sensor data frames are not suitable using computer-based simulation.

As well, reducing time-to-market and first time right design in automotive electronics industry, which are key requirements in projects to win customer and market share, have posed a great challenge to the design and verification team.

III. PAPER CONTRIBUTIONS

An effective utilization of different tools and methodologies with a right verification strategy becomes one of the key factors that can significantly support the project facing technical challenges while still maintaining the industry requirements. As such, the paper proposes a novel functional verification setup in complex SoC design for automotive application. The contributions of the paper can be summarized as follows:

The airbag sensor interfaces and sensor models (fully compliant to PSI5 standard protocol) for chip top-level verification and for supporting the design of Field-Programmable Gate Array (FPGA) and an analogue test chip (TC) emulation platform.

New comprehensive functional verification flow of modern automotive airbag sensor interfaces.

The new flow proves to bridge the classical gap between “simulation performance” and “accuracy” in embedded mixed-signal design.

Acceleration of verification can be done when using the emulation platform, as tests can be conducted at real-time speed.

Functional validation of system (in-circuit/in application test) is possible using the approach at an early phase of the design and integration (module and car level) process. This is extremely important for the new ISO 26262 standard.

IV. THE AIRBAG SENSOR INTERFACE SYSTEM MODEL

A. PSI5 communication protocol overview

The PSI5 shown in Figure 3 is widely used in automotive applications where an airbag controller is interfacing to automotive sensors, such as accelerator and pressure sensors, in order to acquire data reporting the operating condition of the vehicle, based on which the decision for the airbag deployment is taken. As illustrated in Figure 3, physically, the sensor interface has two wires. The first wire is for both sensor power supply and data transmission, while the second wire is the connection to ground. The PSI5 protocol is described by the PSI5 consortium in [6].

2336

The PSI5 protocol supports synchronous and asynchronous communication modes. The use of a Time Division Multiple Access (TDMA) scheme allows the PSI5 interface to receive data from up to four sensors when operating in synchronous mode. Point to point connection between a single sensor and the airbag controller is also supported when operating in asynchronous mode, which is mostly used nowadays.

Electronic Control Unit

µc

Transceiver ASIC

Interface

Sensor 1

Sensor 2

Sensor 3 Sensor 4

Peripheral SensorsTwo-Wire Current

Interface

Vsupply/Isense

GND

Figure 3: Different connection topologies of peripheral sensors to

an ECU [6]

Vsupply

time

Isens

time

Tsync

...

... ...... ...

timeslot1

timeslot2

timeslot3

timeslot4

TgapSensor 1 Sensor 2 Sensor 3 Sensor 4

Figure 4: Synchronization mechanism in PSI5 protocol

In synchronous mode, communication between the airbag controller and peripheral sensors occurs by means of a synchronization signal. This mechanism is described in Figure 4. The airbag controller drives the communication with the PSI5 sensors via supply voltage. After detecting a synchronization pulse, each sensor transmits data within a well defined time interval (time slot) with respect to the detection of the synchronization signal.

Data from different sensors are interleaved by a time gap (Tgap) that is greater than a bit time of the sensor communication. The distance between two synchronization pulses (Tsync), together with the length of the message transmitted by each sensor and the bit rate (BR) of the sensor, determines the maximum number of sensors that can be connected per channel. Sensor data is Manchester encoded and transmitted serially to the master via modulation of the current drawn by the sensor itself.

Vsupply

time

Isens

time

Vsupply nominal

... ... ...

TgapT_async

Figure 5: Point to point connection described in PSI5 protocol

(Asynchronous mode)

PSI5 protocol also offers the opportunity to have a point to point connection where only a single PSI5 sensor is connected per channel. This mode of operation is called asynchronous mode and does not require the PSI5 interface to generate synchronization pulses for the communication sensor interface (Figure 5). In asynchronous mode the PSI5 sensor transmits data after a setup time (T_async) accounted from the moment its supply voltage has reached its nominal value. Different sensor data is separated by a gap time Tgap, as in synchronous mode, and its repetition period depends on the message length and the BR of the data.

B. The airbag PSI5 sensor interface model

For the paper demonstration, an airbag sensor interface design compliant with PSI5 protocol with six channels is modeled as shown in Figure 6. In order to prevent system failures mentioned in section II, these sensor interfaces include algorithms for detection of errors in the communication between airbag controller and peripheral sensors (i.e. corruption of sensor data message content) and algorithms for the discrimination of useful sensor data from noise as well as a defined processing logic of the data to be delivered to the external uC unit. The behavior of the sensor interface is summarized below.

Sensor_IF Analog Front End

(model)

PSI5 Sensor Network

+

PSI5 Sensor

PSI5 Sensor

PSI5 Sensor

PSI5 Sensor

Global signals

Isens

PSI5 Sensor Channel

+

DigitalCORE(RTL)

SPIHW

Firmware

Sensor Reg_IF(RTL)

Sensor IF logic (RTL)

A/

D_I

F

Sensor_IF Analog Front End

(model)

ADC

Voltage regulator

Digital Receiver

Data handling

VP5x_in

Configuration

DUT – Airbag SoC Sensor Interface

Airbag SoC Digital TOP LEVEL

S0 S1 S2 S3SPI_IF

SPIStim

PSI5 Sensors

Figure 6: Airbag PSI5 sensor interface model setup and the

simulation test bench

The sensor interface is configurable by the main uC via SPI interface. The sensors (acceleration sensors) will start to transmit data in form of modulated current encoded with Manchester encoding scheme after receiving the synchronization pulse. The sensor interface is partitioned on hardware into two modules: Sensor_IF logic (digital) and Sensor_IF analogue front end (AFE). The hardware is controlled by the digital logic CORE of the airbag SoC chip which contains also the firmware for the decoding of the SPI commands from the main uC and for the processing of sensor data. Described in Figure 6, the Sensor_IF AFE, which includes a voltage regulator to supply the peripheral sensors and ADCs (Analogue-to-Digital Converters), is connected to the sensors and receives the responded modulated current with the Manchester encoding scheme from the sensor. The Sensor_IF logic consists of a digital receiver which is responsible for the decoding of such encoded modulated current. Additionally, the Sensor_IF logic includes a data handling module for checking the sensor message error due to failure of the Sensor_IF AFE or noise on the line. If an error is detected on the being processed sensor data frame, this frame will be immediately discarded. Otherwise it will be written into a receiving buffer (a part of Sensor Ref_IF module) so that the main uC could access these buffers using SPI commands.

The mixed-abstraction modeling approach described in [7] was used for modeling the sensor interface model. Shown also

2337

in Figure 6, the complete Sensor_IF logic and digital logic CORE of the airbag SoC has been intentionally reused from the Register Transfer Level (RTL) implementation to achieve maximum accuracy for the model and reduce the modeling effort. Focus is on the modeling of the Sensor_IF AFE using VHDL with the support of real value. The AFE model is validated against the schematic implementation. Using this approach, the complete sensor interface model was done with least effort but with high accuracy and high simulation performance (no convergence issue).

C. The PSI5 sensor model

In this section a detailed description of the PSI5 sensor model is provided. From configuration point of view, the model offers the following capabilities:

variable data message length (8, 10, 16, 20, 24 bit) with parity bit or CRC for message error check

transmission speeds of 125 kbps or 189 kbps

configurable parameters for both synchronous and asynchronous modes as defined by the PSI5 standard

pre-defined transmitter data or random data

configurable quiescent and response current levels

fault injection like corrupted start bits or CRC

PSI5 Sensor

Supply_mng

Current encoder

VP5x

Isens ...

...

Iq Iresp

Bit rate generator

...

BR sys_clk

Timer

recovered sync

enmode timeslott_async Tgap_async

Message framer

dmsglen

mec

sb_fault

crc_fault

start_txsys_clk

Tbit_clk

Tchip_clk

Manch_encoder

frame_bit

frame_rdy

md_stream

10 0 1 1

‘1’‘1’ ‘1’‘0’ ‘0’ ‘0’ ‘0’

RNG_gen

RNG_data

en_rng

Data_buffer

data2send

Data_mon Data_rdy

CRC

Figure 7: Block diagram of the PSI5 sensor model architecture

The sensor model top-level architecture is illustrated in Figure 7. The BR generator module can be considered as a programmable clock generation unit providing input clocks for the Manchester encoder module (Tbit_clk = BR and Tchip_clk = 2 x BR). The timer block allows the sensor model to support both PSI5 synchronous and asynchronous modes described by the standard. It implements also programmable timeslot counters to enable the sensor data transmission (start_tx) according to the selected mode. In the synchronous, synchronization pulses are produced by the supply management unit - Supply_mng. In case of asynchronous mode, shown in Figure 5, once the sensor is enabled the first data packet is transmitted after a time t_async. Whenever a sensor data is fully transmitted, a time tgap_async is waited for to separate the different sensor packets. The message framer

module constructs the sensor data frame using the following operations:

Assemble in an internal register the data to be transmitted depending on the data message length (dmsglen), method error protection (mec) and the nature of the data (random data, RNG_data, or user programmed data, data_buffer)

Compute the two start bits and the Parity/CRC bits according to a scheme which supports configurable CRC seed

Compute the sensor frame, synchronized by BR clock and send it serially to the next block.

time

Tchip_clk

time

Tbit_clk

time

frame_bit

time

md_stream

‘0’ ‘0’ ‘1’ ‘0’

if rising_edge (Tchip_clk) thenmd_stream <= frame_bit XOR Tbit_clk;

end if;

Figure 8: Description of the Manchester encoding mechanism

The fault injection capability, which is required by ISO 26262 for safety critical systems, is implemented in the message framer module. CRC errors can be injected on the crc_fault pin, while the data preamble errors can be originated using the pin sb_fault. When crc_fault is asserted the CRC appended to the sensor message is inverted with respect to the CRC computed over the sensor data. When sb_fault is asserted the preamble for the current sensor data is set to S0=’0’, S1=’1’ instead of S0=‘0’, S1=’0’, violating the standard sensor frame format.

The output PSI5 sensor data frame from the Message framer is converted into a binary word corresponding to a Manchester encoding scheme described in Figure 9 using the Manchester encoder unit. According to Figure 9 each bit ‘0’ of the data frame is replaced by the couple ’0-1’ and each bit ‘1’ of the data frame is replaced by the couple ‘1-0’. The PSI5 sensor data Manchester encoding implementation is shown in Figure 8. Finally, the output md_stream is processed by the current encoder module, resulting in the “analogue” Manchester encoding modulated current Isens (VHDL implementation with real number support).

isens

time

...

S00

S10

D00

D11

CRC20

CRC11

CRC01

iq

di

Tbit Tchip

Figure 9: Details of sensor Manchester encoded data current

Each sensor has a quiescent current iq, that represents the current sink by the sensor when no data transmission occurs, and a modulated current di. A detailed explanation of the Manchester modulated signal output by the PSI5 sensor is

2338

provided in Figure 9 for the case of CRC. The sensor data is Manchester encoded with a BR of 125kbaud or 189kbaud, configurable by BR. In Figure 9, Tbit corresponds to the BR period of the encoded data, while Tchip indicates half of a Tbit period.

D. System Model validation using FPGA and analogue TC

emulation hardware system

This section provides a short description of the airbag sensor interfaces emulation system using an FPGA and an analogue TC. As shown in Figure 10, the complete RTL of the airbag digital logic including the sensor digital receiver is mapped on the FPGA device. The analogue TC represents the Sensor_IF AFE schematic which will be used later on the airbag SoC final product. The demonstration SUT (System Under Test) allows not only to parametrically evaluate the analogue interfaces but also to test the RTL implementation of the sensor’s digital receiver.

FPGA_SoC_TOP

uC Emulator

Airbag_Dig

PSI/DSI Rx (DUT1)

SP

I H

W I

F

PD

+ E

xt.

IF

TC_PCB

PSI/DSI TC (DUT2)

PD

+ E

xt.

IF

Sensor 1

Sensor 2

Sensor 3

init_sync

Trans_ctrl

GND

Sensors Network

(G-sensor/Sensor

Symulyzer)

Testing/evaluating the new implementation of PSI/DSI Quad-Rx

Paremetric testing of PSI/DSI common AFE

12

/2

4/

36

Mh

Z

Sensor 4

GND

VP5_X

(X=1..6)

SPI_IF

SUT – System Under Test

Figure 10: Airbag sensor interface emulation system for

acceleration of function verification

Figure 11: Airbag SoC FPGA and analogue TC emulation system

Different functionalities of the airbag sensor interfaces are evaluated using the demonstration SUT architecture, especially for those test scenarios which are not suitable using computer-based simulation as mentioned in section II. When designing the emulation system, the sensor model and the Sensor_IF AFE model were heavily used to simulate the whole system’s functionality before implementing it on the FPGA device. Therefore the emulation system is also used to validate the sensor model’s functional behavior. The behavior comparison between simulation and measurement in the lab will be discussed in the next chapter.

V. SYSTEM SIMULATION RESULTS AND DISCUSSION

A. Test scenario for the verification demonstration

For demonstration the simulation test bench shown in Figure 6 and the emulation test bench shown in Figure 10 and Figure 11 are used with the following targets:

Verify the accuracy of the simulation models, e.g. the PSI5 sensor model, the Sensor_IF AFE model and the full airbag SoC sensor interface model. The simulation results will be compared with the measurement on the FPGA and analogue TC emulation system.

Functionally verify the implementation of the RTL, firmware, the analogue schematic and the overall integration by both simulation and measurement before the product is taped out.

Therefore, the following test sequence was used:

1. PSI5 receiver and sensor configuration (via SPI

commands and configuration files): synchronous

mode, 10 bit data message length, 125kbps, even

parity bit.

2. Enable one channel via SPI command

3. Time slot configuration

4. Send uC synchronization pulse

5. Read Rx buffer via SPI command

6. Check if data send by sensors was properly decoded

B. Verification results

Figure 12 shows the behavior of the sensor interface after being configured and enabled via SPI communication. Correct responses of the firmware are demonstrated as the Sensor_IF AFE is activated after the channel enable commands and the voltage as well as current response from the sensor starts to ramp.

Enable channel

Receiver configuration

Vp5x starts to ramp

Sensor wakes up with Isense at quiesent level

Figure 12: Simulation of system configuration and behavior of

the Sensor_IF AFE when channel is activated

In order to verify the sensor data transmission and receiver functionalities, the requesting sensor data SPI command was decoded. The simulation results shown in Figure 13B illustrates the modulated current response from the sensor after the synchronization pulse arrived at the sensor. The sensor data frame 00 0100100001 1b is encoded with the Manchester encoding scheme, in which the first two 0 bits are the start bits S0 & S1 while the last bit is the parity check bit. The real transmitted sensor data is then 0100100001b.

2339

00 0010100001 100 0010100001 1

A) B)

C) D)

Readout from SPI toolMISO readout = 8500C487h ->

Sensor data embedded in the payload = “”1000 0101 0000 0000” -> recovered sensor data @ uC side

= “0010100001”

Sensor payload data = “0010100001”

5 08 0 5 08 0 4 8C 7

Lab MEASUREMENT Computer SIMULATION

Figure 13: Sensor data transceiving verification from sensor to

main micro-controller

Measuring current (Figure 13A) on the sensor transmission line VP5 using the FPGA and analogue TC emulation system in Figure 11 shows a very close behavior to the simulation result using the model. The MISO readout of the sensor data read command on both measurement and simulation - Figure 13C & Figure 13D respectively – shows that the sensor data is transmitted, decoded and processed as specified. This implies that the model and the implementation on the emulation system fit very well together.

C. The new functional verification flow for embedded mixed-

signal SoC product:

This section describes the new verification setup for the airbag SoC as well as its sensor interface verification, which is shown in Figure 14. The new setup includes:

A full event-driven computer based simulation for chip top-level verification using a mixed-abstraction modeling approach.

A hardware accelerated emulation platform using FPGA and analogue TC

MOD& SIM (computer based verification)

Hardware accelerated verification

(FPGA + Analogue TC)

1 – Top-level functional VER

2 – Prototype/Emulation

system developement

Verification & Validation Acceleration

Verification time and cost

reduction

Root cause analysis

Coverage improvement

Bug_fix testing

Figure 14: New verification flow for embedded mixed-signal SoC

product development

Starting by developing accurate models for the functional top-level simulation, these models are also used to support the development of the prototype/emulation system, which is then actively used for accelerating the verification and validation activities. This includes, but is not limited to the following:

Reduction of verification time and cost as test/simulation can be conducted at real-time speed using the emulation hardware.

The verification coverage is significantly improved as a number of critical functional test scenarios (where simulation is not applicable) are possible using the emulation system, e.g.: long-term testing, system failure rate test, system robust test, etc…

Confidence on the product/design quality can be gained as real test data (sensors from real application circuits) is used to test the SUT.

If silicon is back for lab-verification, the flow can be used to improve root-cause analysis effort (in case of bug found), furthermore bug-fixes can be tested in advance before a further tape-out.

VI. CONCLUSION AND OUTLOOK

The modern airbag system design has been introduced and the embedded mixed-signal verification challenges have been discussed and addressed. With many proven advantages, the proposed verification approach with hardware assisted emulation system for functional verification acceleration is currently used as the development state-of-practice for a new airbag SoC chipset. The approach is suggested for future embedded mixed-signal SoC applications with high complexity analogue interfaces.

As an outlook, the authors would like to apply the new approach for the verification of the deployment interfaces where a high precision of interaction between hardware and firmware with a tight timing window is required. Additionally, the FPGA and analogue TC emulation platform could be used to support the uC software development team at an early phase before the airbag SoC is available. Thus, it helps to gain time-to-market for Tier-1 suppliers and OEMs.

ACKNOWLEDGEMENT

The research leading to these results has received funding from the ARTEMIS Joint Undertaking under grant agreement Nr. 295311 and the Austrian Research Promotion Agency FFG under the program "Forschung, Innovation und Technologie für Informationstechnologien (FIT-IT)” (http://vetess.eu/).

REFERENCES

[1] Jerraya, A.A. and W. Wolf, eds. Multiprocessor Systems-on-Chips. The Morgan Kaufmann Series in Systems on Silicon, ed. P. Ashenden and W. Wolf. 2005, Elsevier

[2] Lin, Y.-L.S., Essential Issues in SOC Design - Designing Complex Systems-on-Chip. 2006, Springer

[3] Rashinkar P., Paterson P. and Singh L., System-on-a-chip Verification: Methodology and Techniques, 2002, Kluwer Academic Publishers, USA

[4] Luis, G. and Joao M.Fernandes, Behavioral Modeling for embedded Systems and Technologies: Application for Design and Implementation. 2009, Information Science Reference, New York

[5] Cagkan Erbas, System Level Modeling and Design Space Exploration for Multiprocessor Embedded System-on-Chip Architectures, PhD Thesis, Amsterdam University Press 2006, Amsterdam, Netherlands

[6] PSI5 Consortium, PSI5 – Peripheral Sensor Interface for automotive Application Specification version 2.1 - http://psi5.org/specification/

[7] T. Nguyen and D.Haerler, Mixed-abstraction modeling approach with fault injection for hardware-firmware co-design and functional co-verification of an automotive airbag system-on-chip product, DVCon 2013 - Design Verification Conference 2013, San Jose, USA

2340

Powered by TCPDF (www.tcpdf.org)