automotive electronics - trends and challenges

8/2/2019 Automotive Electronics - Trends and Challenges

1/13

Paper Number

Automotive Electronics: Trends and Challenges

Alberto Sangiovanni-VincentellThe Edgar L. and Harold H. Buttner Chair of Electrical Engineering and Computer Science, University of California at

Berkeley

Copyright 2000 Society of Automotive Engineers, Inc.

ABSTRACT

The car as a self-contained microcosm is undergoingradical changes due to the advances of electronictechnology. We need to rethink what a car really is andthe role of electronics in it. Electronics is now essential to

control the movements of a car, of the chemical andelectrical processes taking place in it, to entertain thepassengers, to establish connectivity with the rest of theworld, to ensure safety. What will an automobilemanufacturers core competence become in the next fewyears? Will electronics be the essential element in carmanufacturing and design? We will address some ofthese issues and we will present some importantdevelopments in the area of system design that canstrongly impact the way in which a car is designed.

INTRODUCTION

The world of electronics is witnessing a revolution in theway products are conceived, designed and implemented.The ever growing importance of the web, the advent ofmicroprocessors of great computational power, theexplosion of wireless communication, the development ofnew generations of integrated sensors and actuators arechanging the world in which we live and work. The newkey wordsare:

transparent electronics, i.e., electronics has to beinvisible to the user; it has to help unobtrusively.

pervasive computing, i.e., electronics is everywhere;

all common use objects will have an electronicdimension. intelligent environments, i.e., the environment will

react to us with the use of electronic components.They will recognize who we are and what we like.

wearable computing, i.e., the new devices will be wornas a watch or a hat. They will become part of ourclothes. Some of these devices will be tags that willcontain all-important information about us.

write once, run everywhere, i.e., any information wewrite down will be recorded and digested by the

intelligent environment. We will never have to enter thesame information twice.

know more, carry less, i.e., the environment will beable to know more about us so that we will not needto carry all the access paraphernalia we need today:keys, credit cards, personal I.D. access cards

access codes will soon be forgotten.The car as a self-contained microcosm is experiencing asimilar revolution. We need to rethink what a car really isand the role of electronics in it. Electronics is nowessential to control the movements of a car, of thechemical and electrical processes taking place in it, toentertain the passengers, to establish connectivity withthe rest of the world, to ensure safety. What will anautomobile manufacturers core competence become inthe next few years? Will electronics be the essentiaelement in car manufacturing and design?

The challenges and opportunities are related to

how to integrate the mechanical and the electronicsworlds, i.e., how to make mechatronics a reality inthe automotive world,

how to integrate the different motion control andpower-train control functions so that importansynergies can be exploited,

how to combine entertainment, communication andnavigation subsystems,

how to couple the world of electronics where the lifetime of a product is around 2 years and shrinking,with the automotive world, where the product life timeis 10 years and possibly growing.

how to develop new services based on electronicstechnology

how are the markets shaping up (for example, whatwill be the size of the after-market sales forautomotive electronics?)

We will pose these questions while quickly reviewingsome of the most important technology and producdevelopments of the past few years. The entire electronicsindustry is undergoing a major restructuring that isfavoring horizontal integration and vertical disintegration. Inthis framework, we point out how collaboration among


2/13

different industry segment is essential to bring newproducts to market. The main part of the paper is aboutsystem design methodology that focuses on two mainprinciples: orthogonalization of concerns and platform-based design. System design is definitely the mostimportant technology to master to increase the qualityand the value of the electronic component of the car.

CONSIDERATIONS ON THE FUTURE OF

ELECTRONICS AND INTEGRATED CIRCUITS

DEVICES, INFRASTRACTURE AND BUSINESSORGANIZATION

By the year 2002, it is estimated that more informationappliances will be sold to consumers than PCs (BusinessWeek, March 1999). This new market includes small,mobile, and ergonomic devices that provide information,entertainment, and communications capabilities toconsumer electronics, industrial automation, retailautomation, and medical markets. These devices requirecomplex electronic design and system integration,

delivered in the short time frames of consumerelectronics. The system design challenge of the nextdecades is the dramatic expansion of this spectrum ofdiversity. The introduction of small, low-power, embeddeddevices will accelerate, as microelectronic mechanicalsystem (MEMS) technology becomes available.Microscopic devices, powered by ambient energy in theirenvironment, will be able to sense numerous fields,position, velocity, and acceleration, and communicatewith substantial bandwidth in the near area. Larger, morepowerful systems within the infrastructure will be driven bythe continued improvements in storage density, memory

density, processing capability, and system-areainterconnects as single board systems are eclipsed bycomplete systems on a chip.

Data movement and transformation is of central

importance in such applications. Future devices will benetwork-connected, channeling streams of data into theinfrastructure, with moderate processing on the fly. Otherswill have narrow, application-specific UIs. They will behighly adaptable and configured automatically, and yetprovide strong guarantees of availability and performance.Applications will not be centered within a single device,but stretched over several, forming a path through the

infrastructure. In such applications, the ability of thesystem designer to specific, manage, and verify thefunctionality and performance concurrent behaviors isessential.

Electronics in the automotive domain has been growing byleaps and bounds. There are three basic domains for theelectronics for the car:

Power-train management; Body electronics, including dashboard and

temperature control;

Infotainment, a horrible neologism for theelectronic subsystems devoted to the informationprocessing, communication with the outside worldand entertainment.

The first domain is very typical of a transportation systemand is characterized by tight safety and efficiencyconstraints. Control algorithms are core competencetogether with software and mixed mechanical-electrica

hardware design and implementation.

Body control involves the management of a distributedsystem that resembles more and more a network withprotocols that are likely to have different requirementsthan standard communication protocols. Guaranteedservices are the essence here.

The infotainment system is more amenable to side effectsfrom other industrial domains that are growing andprogressing in the technology race at a faster rate thanwhat I have seen in the automotive domain. This is thedomain where most profits are to be gained in the short-

medium term. Customers are now starting to make theirbuying decision with an eye more towards theinfotainment environment of a car rather than towards theperformance of its engine and its handling. Hence, theessential question of what will be the core competence ofa car company. Will the electronic components be thecar and the mechanical components an accessory?

A recent quote from Daimler-Chrysler executives saysthat more than 80% of innovation in the automotivedomain will be in electronic components. It is then clearthat this domain will be the battlefield among players indifferent industrial segments: consumer electronics

wireless communication, car electronics, camanufacturing. I believe that the winners will be able toconjugate the knowledge of the car as a microcosm withthe knowledge of electronic design and technologyStrategic relationships have already been formed to tacklethe most difficult problems. I also believe that theinteraction and the potential integration of the threeenvironments will be essential to propose interestingsolutions.

SUPPLIER CHAIN FOR ELECTRONIC SYSTEMS

No single company will be able to master the design andthe production of these complex devices and of thenecessary infrastructure. Due to more and more stringenttime-to-market constraints, the electronics industry is restructuring so that system level design companies likeNokia focus more and more on product definition andmarketing, while outsourcing the design and engineeringof the actual products to specialized design servicescompanies like Cadence Design Systems. The design ofsystem products is itself the result of the collaborationamong Intellectual Property (IP) providers and systemintegrators. The production is then deferred to specializedmanufacturing companies thus resulting in substantia


3/13

investment savings and better time-to-market. This trendhas been visible for the past few years in boardmanufacturing where companies like Solectron andFlextronics have been taking the lead in contractmanufacturing but is now also quite popular in theIntegrated Circuit domain where foundries like TSMC,UMC and Chartered Semiconductors are growing at a veryfast rate, fueled by the success of fab-less semiconductorcompanies and by the interest of system companies like

Cisco to invest in proprietary design technologyindependent of standard semiconductor companies. Ibelieve that the companies that will be able to leveragemaximally this new business organization will be the onesto dominate.

To be able to leverage this situation, a new design flowhas to be put in place. The importance of clean interfacesand unambiguous specifications will be essential. Inaddition, the thorny issue of IP protection and IP propertyhas to be addressed. In the automotive domain, this iseven more important as the supplier chain is deeper thanin other industrial segments. Automotive manufacturers

such as Mercedes and BMW must manage internaldevelopment groups as well as outside groups like Boschwho then work in collaboration with semiconductorcompanies and possibly with printed circuit boardmanufacturers. Hence, best business practices have to bedeveloped if we do not want to enter into an era even morelitigious than the present one.

ELECTRONIC SYSTEM DESIGN: ISSUES ANDSOLUTIONS

The overall goal of electronic embedded system design isto balance production costs with development time andcost in view of performance and functionality

considerations. Manufacturing cost depends mainly on thehardware components of the product. Minimizingproduction cost is the result of a balance betweencompeting criteria. If one considers an integrated circuitimplementation, the size of the chip is an important factorin determining production cost. Minimizing the size of thechip implies tailoring the hardware architecture to thefunctionality of the product. However, the cost of a state-of-the-art fabrication facility continues to rise: it isestimated that a new 0.18m high-volume manufacturingplant costs approximately $2B today.

In addition, the NRE costs associated with the design andtooling of complex chips are growing rapidly. The ITRSpredicts that while manufacturing complex System-on-Chip designs will be practical, at least down to 50nmminimum feature sizes, the production of practical masksand exposure systemswill likely be a major bottleneck forthe development of such chips. That is, the cost of maskswill grow even more rapidly for these fine geometries,

adding even more to the up-front NRE for a new design. Asingle mask set and probe card cost for a state-of-the-artchip is over $.5M for a complex part today [1], up fromless than $100K a decade ago (note: this does not

include the design cost). At 0.15m technologySEMATECH estimates we will be entering the regime ofthe "million dollar mask set." In addition, the cost ofdeveloping and implementing a comprehensive test fosuch complex designs will continue to represent anincreasing fraction of a total design cost unless newapproaches are developed. These increasing costs arestrongly prejudicing manufacturers towards parts thahave guaranteed high-volume production form a single

mask set (or that are likely to have high volumeproduction, if successful.) Such applications alsotranslate to better response time and higher priorities attimes when global manufacturing resources are in shortsupply.

As a consequence of this evolution of the IntegratedCircuit world, if one could determine a common hardwaredenominator (which we refer to as a hardware platformthat could be shared across multiple applicationsproduction volume increases and overall costs mayeventually be (much) lower than in the case when the chipis customized for the application.

Of course, while production volume will drive overall costdown by amortizing NRE, it is important to consider thefinal size of the implementation as well since a platformthat can support the functionality and performancerequired for a high-end product may end up being tooexpensive for other lower-complexity products. Today thechoice of a platform architecture and implementation ismuch more an art than a science. We believe that a nextgeneration, successful system design methodology mus

assist designers in the process of designing, evaluating

and programming such platform architectures, with

metrics and with early assessments of the capability of a

given platform to meet design constraints

As the complexity of the products under designincreases, the development efforts increase dramaticallyAt the same time, the market dynamics for electronicssystems push for shorter and shorter development times.It will be soon imperative to keep to a strict design timebudget, no matter how complex the design problem, withas little as six months from initial specification to a finaland correct implementation. To keep these efforts incheck and at the same time meet the design timerequirements a design methodology that favors reuse and

early error detection is essential. The use oprogrammability as a mechanism for making low-cost, insitu design iterations is also very important in thesesituations. In this regard, we expect the majority of high-volume platforms developed to be programmable, either athe logic/interconnect level (e.g. via FPGA) or usingsoftware. However, as explained in more detail laterconventional Von Neumann architectures are unlikely tobe sufficient to meet the power, performance and costtargets of this next generation of electronic systemsFundamental, new approaches to the programming o

silicon-based systems must be developed and deployed.


4/13

Both reuse and early error detection imply that the designactivity must be defined rigorously, so that all phases areclearly identified and appropriate checks are enforced. Tobe effective, a design methodology that addressescomplex systems must start at high levels of abstraction.In most of the embedded system design companies aswell as IC design companies, designers are familiar withworking at levels of abstraction that are too close toimplementation so that sharing design components and

verifying designs before prototypes are built is nearlyimpossible. Today, most IC designers think of the highestlevel of abstraction for their design an RTL languagedescription. For embedded system designers, assemblylanguage or at best C language is the way to capture andto implement the design. These levels are clearly too lowfor complex system design. The productivity offered by theexpressive power of RTL languages is way below critical,lacking a support for software implementations. Inparticular, we believe that the lack of appropriate

methodology and tool support for modeling of concurrency

in its various forms is an essential limiting factor in the

use of both RTL and commonly used programming

languages to express design complexity.

Design reuse is most effective in reducing cost anddevelopment time when the components to be shared areclose to the final implementation. On the other hand, it isnot always possible or desirable to share designs at thislevel, since minimal variations in specification can result indifferent, albeit similar, implementations. However, movinghigher in abstraction can eliminate the differences amongdesigns, so that the higher level of abstraction can beshared and only a minimal amount of work needs to becarried out to achieve final implementation. The ultimategoal in this regard is to create a library of functions, along

with associated hardware and software implementations,that can be used for all new designs. It is important tohave a multiple levels of functionality supported in such alibrary, since it is often the case that the lower levels thatare closer to the physical implementation changebecause of the advances in technology, while the higherlevels tend to be stable across product versions.

We believe that it is most likely that the preferredapproaches to the implementation of complex embeddedsystems will include the following aspects: Design time and cost are likely to dominate the

decision-making process for system designers.Therefore, design reuse in all its shapes and forms,as well as just-in-time, low-cost design debugtechniques, will be of paramount importance.Flexibility is essential to be able to map an ever-growing functionality onto a continuously evolvingproblem domain and set of associated hardwareimplementation options.

Designs must be captured at the highest level ofabstraction to be able to exploit all the degrees offreedom that are available. Such a level of abstraction

should not make any distinction between hardwareand software, since such a distinction is theconsequence of a design decision.

The implementation of efficient, reliable, and robustapproaches to the design, implementation, and

programming of concurrent systems is essential. Inessence, whether the silicon is implemented as asingle, large chip or as a collection of smaller chipsinteracting across a distance, the problems

associated with concurrent processing and concurrencommunication must be dealt with in a uniform and

scaleable manner. In any large-scale embeddedsystems program, concurrency must be consideredas a first class citizen at all levels of abstraction andin both hardware and software.

Concurrency implies communication amongcomponents of the design. Communication is toooften intertwined with the behavior of the componentsof the design so that it is very difficult to separate outhe two domains. Separating communication andbehavior is essential to dominate system designcomplexity. In particular, if in a design component

behaviors and communications are intertwined, it isvery difficult to re-use components since their behavioris tightly dependent on the communication with othercomponents of the original design. In additioncommunication can be described at various levels ofabstraction, thus exposing the potential oimplementing communication behavior in manydifferent forms according to the available resources.Today this freedom is often not exploited.

Next-generation systems will most likely use a fewhighly complex (Moores Law Limited) part-types, butmany more energy/power-cost-efficient, mediumcomplexity (O(10M-100M) gates in 50nm technology)

chips, working concurrently to implement solutions tocomplex sensing, computing, and signaling/actuatingproblems.

These chips will most likely be developed as aninstance of a particular platform. That is, rather thanbeing assembled from a collection of independentlydeveloped blocks of silicon functionality, they will bederived from a specific family of micro-architecturespossibly oriented toward a particular class oproblems, that can be modified (extended or reduced)by the system developer. These platforms will beextended mostly through the use of large blocks of

functionality (for example, in the form of coprocessors), but they will also likely supporextensibility in the memory/communicationarchitecture as well. When selecting a platform, costsize, energy consumption, flexibility must be takeninto account. Since a platform has much wideapplicability than ASICs, design decisions are crucialA less than excellent choice may result in economicdebacle. Hence, design methods and tools thaoptimize the platform-selection process are veryimportant.


5/13

These platforms will be highly programmable, at avariety of levels of granularity. Because of this feature,mapping an application into a platform efficiently willrequire a set of tools for software design thatresemble more and more logic synthesis tools. Webelieve this to be a very fruitful research area.

SYSTEM LEVEL DESIGN METHODOLOGY

An essential component of a new system designparadigm is the orthogonalization1 of concerns, i.e., theseparation of the various aspects of design to allow moreeffective exploration of alternative solutions. An example ofthis paradigm is the orthogonalization betweenfunctionality and timing exploited in the synchronousdesign methodology that has been so successful in digitaldesign. In this case, provided that the signal propagationdelays in combinational blocks are all within the clockcycle, verifying the correct behavior of the design isrestricted to the functionality of the combinational blocksthus achieving a major design speed-up factor versus the

more liberal asynchronous design methodology. Othersmore powerful paradigms must be applied to systemdesign to make the problem solvable, let alone efficientlyso. One pillar of a design methodology that we haveproposed over the years [2,3,4] is the separation between:

Function (what the system is supposed to do) andarchitecture (how it does it);

Communication and computation.

The mapping of function to architecture is an essentialstep from conception to implementation. In the recent

past, there has been a significant attention in the researchand industrial community to the topic of Hardware-Software Co-design. The problem to be solved here iscoordinating the design of the parts of the system to beimplemented as software and the parts to be implementedas hardware blocks, avoiding the HW/SW integrationproblem that has marred the electronics system industryfor so long. We actually believe that worrying abouthardware-software boundaries without considering higherlevels of abstraction is the wrong approach. HW/SWdesign and verification happens after some essentialdecisions have been already made, and this is whatmakes the verification and the synthesis problem hard.

SW is really the form that a behavior is taking if it ismapped into a programmable microprocessor or DSP.The motivations behind this choice can be performance ofthe application on this particular processor, or the need forflexibility and adaptivity. The origin of HW and SW is inbehavior that the system must implement. The choice ofan architecture, i.e. of a collection of components thatcan be either software programmable, re-configurable or

1 We refer to orthogonalization (see orthogonal bases in

mathematics) versus separation to stress the independence of the axes

along which we perform the decomposition.

customized, is the other important step in design. Werecall the basic tenet of our proposed design methodology(see Figure 1) next.

Figure 1: Overall Organization of the Methodology

FUNCTION AND COMMUNICATION-BASED DESIGN

We say that a system implements a set of functions,where a function is an abstract view of the behavior of anaspect of the system. This set of functions is theinput/output characterization of the system with respect to

its environment. It has no notion of implementationassociated with it. For example, when the engine of a castarts (input), the display of the number of revolutions per

minute of the engine (output) is a function, while whenthe engine starts, the display in digital form of the number

of revolutions per minute on the LCD panel is not afunction. In this case, we already decided that the displaydevice is an LCD and that the format of the data is digitalSimilarly, when the driver moves the direction indicator(input), the display of a sign that the direction indicator is

used until it is returned in its base position is a functionwhile when the driver moves the direction indicator, the

emission of an intermittent sound until it is returned to itsbase positionis not a function.

The notion of function depends very much on the level ofabstraction at which the design is entered. For examplethe decision whether to use sound or some other visualindication about the direction indicator may not be a freeparameter of the design. Consequently, the seconddescription of the example is indeed a function since thespecification is in terms of sound. However, even in thiscase, it is important to realize that there is a higher levelof abstraction where the decision about the type of signais made. This may uncover new designs that were not

System

Function

System

Microarchitecture

Mapping

Function on

Microarchitecture

Implementation

of System

Refine

12

3

4

System

Function

System

Microarchitecture

Mapping

Function on

Microarchitecture

Implementation

of System

Refine

System

Function

System

Microarchitecture

System

Function

System

Microarchitecture

Mapping

Function on

Microarchitecture

Implementation

of System

Refine

12

3

4


6/13

even considered because of the entry level of the design.Our point is that no design decision should ever be madeimplicitly and that capturing the design at higher levels ofabstraction yields better designs in the end.

The functions to be included in a product may be left tothe decision of the designer or may be imposed by thecustomer. If there are design decisions involved, then thedecisions are grouped in a design phase called function

(or sometimes feature) design. The decisions may belimited or range quite widely.

The description of the function the system has toimplement is captured using a particular language thatmay or may not be formal. In the past, natural languagewas the most used form of design capture. The languageused for capturing functional specifications is oftenapplication dependent. For example, for controlapplications, Matlab is used to capture algorithms. Forseveral applications, computer languages such as C areused. However, these languages often lack the semanticconstructs to be able to specify concurrency. We believe

that the most important point for functional specification isthe underlying mathematical model, often called model ofcomputation.

As opposed to the informal nature of component-baseddesign often used to design software today [5], wepromote the use of formal models and transformations insystem design so that verification and synthesis can beapplied to advantage in the design methodology. In fact,verification is effective if complexity is handled byformalization, abstraction and decomposition [6]. Further,the concept itself of synthesis can be applied only if theprecise mathematical meaning of a description of the

design is applied. It is then important to start the designprocess from a high-level abstraction that can beimplemented in a wide variety of ways. Theimplementation process is a sequence of steps thatremove choice from the formal model. In other words, theabstract representation of the design should contain allthe correct implementations in the sense that the behaviorof the implementation should be consistent with theabstract model behavior. Whenever a behavior is notspecified in the abstract model, the implicit assumption isthat such behavior is a dont-care in the implementationspace. In the implementation domain, the abstract model

is source of non-deterministic behavior. Theimplementation process progresses towards adeterministic system. It is important to underline that waytoo often system design starts with a systemspecification that is burdened by unnecessary referencesto implementations resulting in over-determinedrepresentations with respect to designer intent thatobviously yield under-optimized designs.

In the domain of formal model of system behavior, it iscommon to find the term Model of Computation, aconcept that has its roots in language theory. This termrefers more appropriately to mathematical models that

specify the semantic of computation and of concurrencyIn fact, concurrency models are the most importandifferentiating factors among models of computationEdward Lee has correctly stressed the importance ofallowing the designer to express designs making use ofany such models of computation, or at least of theprincipal ones, thus yielding a so-called heterogeneousenvironment for system design. In his approach tosimulation and verification, assembling a system

description out of modules represented in different modelsof computation yields the problem of arbitratingcommunication among the different models. The conceptof communication among different models of computationmust be carefully explored and understood [7].

This difficulty has actually motivated our approach tocommunication-based design, where communicationtakes the driver seat in the overall system designmethodology. In this approach, communication can bespecified somewhat independently of the modules thatcompose the design. In fact, two approaches can beapplied here. In the first case, we are interested in

communication mechanisms that work in anyenvironment, i.e., independent of the formal models andspecifications of the behavior of the components. This is avery appealing approach if one emphasizes ease ocomponent assembly. However, it is rather obvious thatthe designer may end up with an implementation that isquite inefficient, especially for high-volume embeddedsystems applications where production cost is veryimportant. The other approach is to specify thecommunication behavior and then to use a successiverefinement process for optimizing the communicationwhere the refinement process can leverage all that isknown about the modules to interconnect. In this case,

the correctness of the overall behavior is not insured bythe communication mechanism but by the design processof the communication itself. In this case, a synthesisapproach is most appealing since it reduces the risk ofmaking mistakes and it may use powerful optimizationtechniques to reduce design cost and time.

The most important models of computation that have beenproposed to date are based on three basic models: FiniteState Machines, Data Flow and Discrete Event [7]. Almodels have their strengths and weaknesses. It is animportant differentiating factor to be able to use these

models at their best. Note that each model is composable(can be assembled) in a particular way that guaranteesthat some properties of the single components aremaintained in the overall system. Communication andtime representation in each model of computation arestrictly intertwined. In fact, in a synchronous systemcommunication can take place only at precise instants oftime thus reducing the risk of unpredictable behaviorSynchronous systems are notoriously more expensive toimplement and often less performing thus opening thedoor to asynchronous implementations. In this latter casethat is often the choice for large system design, particularcare has to be exercised to avoid undesired and


7/13

unexpected behaviors. The balance between synchronousand asynchronous implementations is possibly the mostchallenging aspect of system design. Globally-asynchronous-locally-synchronous (GALS)communication mechanisms are probably a goodcompromise in the implementation space [2].

The view of communication in these models ofcomputation is sometimes at a level of abstraction that is

too low. We would like to be able to specify abstractcommunication patterns with high-level constraints thatare not implying yet a particular model of communication.For example, it is our opinion that an essential aspect ofcommunication is loss-lessness. We argue that theremust exist a level of abstraction that is high enough torequire that communication take place with no losses.The synchronous-asynchronous mechanism, theprotocols used and so on, are just implementationchoices that either guarantee loss-lessness or that have agood chance of ensuring that no data is lost where itmatters but that needs extensive verification to make surethat this is indeed the case. For example, Kahns process

networks [7] are important Data Flow models thatguarantee lossless communication at the highest level ofabstraction by assuming an ideal buffering scheme thathas unbounded buffer size. Clearly, the unbounded buffersize is a non-implementable way of guaranteeing loss-lessness. When moving towards implementable designs,this assumption has to be removed. A buffer can beprovided to store temporarily data that are exchangedamong processes but it must be of finite size. The choiceof the size of the buffer is crucial. Unfortunately decidingwhether a finite buffer implementation exists thatguarantees loss-lessness is not theoretically feasible inthe general case, but there are cases for which the

optimal buffer size can be found. In others, one has tohope for the best for buffer overwrite not to occur or has toprovide additional mechanism that composed with thefinite buffer implementation still guarantees that no losstakes place. For example, a send-receive protocol can beput in place to prevent buffer over-write to occur. Note thatin this case the refinement process is quite complex andinvolves the use of composite processes. Today, there islittle that is known about a general approach tocommunication design that has some of the feature thatwe have exposed, even though we have proposed a familyof models that are related to each other as successive

refinements [8].

Approaches to the isolation of communication andcomputation, and how to refine the communicationspecification towards an implementation [9] have beenpresented elsewhere. In some cases, we have been ableto determine a synthesis procedure for the communicationthat guarantees some properties. In our opinion, thisformalism and the successive refinement process opens avery appealing window to system design with unexploredavenues in component-based software design. It is ouropinion that the latest advances in component-basedsoftware design and in software engineering are

converging, albeit slowly and probably unconsciouslytowards a more formal model of communication amongmodules.

MICRO-ARCHITECTURE

In most design approaches, the next stage of the designprocess involves the evaluation of tradeoffs across whatwe refer to as the architecture/micro-architecture

boundary, and at this point in our presentation, the classof structural compositions that implement the architectureis of primary concern. While the word architecture is usedin many meanings and contexts, we adhere to thedefinitions put forward in [10]: the architecturedefines aninterface specification that describes the functionality ofan implementation, while being independent of the actuaimplementation. The micro-architecture, on the othehand, defines how this functionality is actually realized asa composition of modules and components, along withtheir associated software.

The instruction-set architecture of a microprocessor is agood example of an architecture: it defines what functionsthe processor supports, without defining how thesefunctions are actually realized. The micro-architecture ofthe processor is defined by the organization and thehardware of the processor. These terms can easily beextended to cover a much wider range of implementationoptions. At this point, the design decisions are madeconcerning what will eventually be implemented assoftware or as hardware.

Consistent with the above definitions, in our work wedescribe a micro-architecture as a set of interconnected

components (either abstract or with a physical dimension)that is used to implement a function. For example, anLCD, a physical component of a micro-architecture, canbe used to display the number of revolutions per minute ofan automotive engine. In this case, the component has aconcrete, physical representation. In other cases, it mayhave a more abstract representation. In general, acomponent is an element with specified interfaces andexplicit context dependency. The micro-architecturedetermines the final hardware implementation and hence iis strictly related to the concept of platform [11,12] thatwill be presented in greater detail later on.

The most important micro-architecture for the majority ofembedded designs consists of microprocessorsperipherals, dedicated logic blocks and memories. Forsome products, this micro-architecture is completely or inpart fixed. In the case of automotive body electronics, theactual placement of the electronic components inside thebody of the car and their interconnections is kept mostlyfixed, while the single components, i.e., the processors,may vary to a certain extent. A fixed micro-architecturesimplifies the design problem a great dealespecially thesoftware part todaybut limits design optimality. Thetrade-off is not easy to achieve.


8/13

In addition, the communication among micro-architectureblocks must be handled with great care. Itscharacteristics make the composition of blocks easy ordifficult to achieve. Standards are useful to achievecomponent re-use. Busses are typical interconnectionstructures intended to favor re-use. Unfortunately, thespecification of standard busses such as the PCI bus ishardly formal. This makes the design of the interfaces at

best haphazard. Ultimately, we believe the verification ofsuch interconnection interfaces will be the limiting factorin design productivity. In addition, we are experimentingwith different interconnect structures such as on-chipnetworks.

MAPPING

The essential design step that allows moving down thelevels of the design flow is the mapping process, wherethe functions to be implemented are assigned (mapped) tothe components of the micro-architecture. For example,the computations needed to display a set of signals may

all be mapped to the same processor or to two differentcomponents of the micro-architecture (e.g., amicroprocessor and a DSP). The mapping processdetermines the performance and the cost of the design.To measure exactly the performance of the design and itscost in terms of used resources, it is often necessary tocomplete the design, leading to a number of time-consuming design cycles. This is a motivation for using amore rigorous design methodology. When the mappingstep is carried out, our choice is dictated by estimatesofthe performance of the implementation of that function (orpart of it) onto the micro-architecture component.Estimates can be provided either by the manufacturers of

the components (e.g., IC manufacturers) or by systemdesigners. Designers use their experience and someanalysis to develop estimation models that can be easilyevaluated to allow for fast design exploration and yet areaccurate enough to choose a good micro-architecture.Given the importance of this step in any applicationdomain, automated tools and environments shouldsupport effectively the mapping of functions to micro-architectures.

The mapping process is best carried out interactively inthe design environment. The output of the process is

either: A mapped micro-architecture iteratively refinedtowards the final implementation with a set ofconstraints on each mapped component (derived fromthe top-level design constraints) or

A set of diagnostics to the micro-architecture andfunction selection phase in case the estimationprocess signals that design constraints may not bemet with the present micro-architecture and functionset. In this case, if possible, an alternative micro-architecture is selected. Otherwise, we have to workin the function space by either reducing the number of

functions to be supported or their demands in terms ofperformance.

LINK TO IMPLEMENTATION

This phase is entered once the mapped micro-architecturehas been estimated as capable of meeting the designconstraints. The next major issue to be tackled isimplementing the components of the micro-architecture

This requires the development of an appropriate hardwareblock or of the software needed to make theprogrammable components perform the appropriatecomputations. This step brings the design to the finalimplementation stage. The hardware block may be foundin an existing library or may need a special purposeimplementation as dedicated logic. In this case, it may befurther decomposed into sub-blocks until either we findwhat we need in a library or we decide to implement it bycustom design. The software components may existalready in an appropriate library or may need furthedecomposition into a set of sub-components, thusexposing what we call the fractal (self-similar) nature o

design, i.e., the design problem repeats itself at everylevel of the design hierarchy into a sequence of nestedfunction-(architecture)-micro-architecture-mappingprocesses.

APPLICATIONS

This methodology is not empty rhetoric, but it has beenalready tested in advanced industrial environments. Inparticular, complex system designs have been cast in thisframework and implemented in the field of automotiveelectronic subsystems, as detailed in three other papersof this conference, and consumer electronics [13]. Its

basic aspects have been incorporated in POLIS [2]Ptolemy [14] and in an at least an industrial product [34], VCC by Cadence, and we know of other tools that arebeing developed based on these concepts.

Philips VideoTop

COSY is an EEC project on system design andverification involving industry (Cadence, Philips, Siemens)and academia (University of Paris Marie-Curie, Politecnicodi Torino, University of Tubingen)[13]. The main goal wasto apply the methodology outlined above (and modifying it

whenever necessary) to industrial system design. Themain driver was VideoTop, a subsystem that incorporatesthe main functionality of a digital video broadcast system.

The system receives an MPEG2 transport stream, wherethe user selects the channels to be decoded. Theassociated video streams are then unscrambled, de-multiplexed, and decoded. The user may also define postprocessing operations on the decoded streams, such aszooming and composition (picture-in-picture). Thefunctional specifications required the followingcomponents:


9/13

An MPEG2 (ISO/IEC 13818-2) de-multiplexer. An MPEG2 parser. An MPEG2 decoder (H.262 compliant up to main

profile and high level). A video re-sizer with a zoom factor from 0.16 to

10. (Controlled by the user.) A video mixer for a number of arbitrary sized video

images. (Positions controlled by the user.) A User interface

The functional specifications were captured using a formalmodel of computations (YAPI [15]) derived from Kahnsprocess networks. The model consisted of

62 processes 206 communication arcs 25,000 C/C++ lines2

According to our methodology, the functionalspecifications were analyzed and simulated executing theY-API program. The simulation time on a Linux Pentium450Mhz was about 80 times slower than real-time

behavior. The micro-architecture selection started with thefollowing basic blocks: a MIPS PR39K with 1 SRAMblock and PSOS as RTOS. We tried a full softwareimplementation and one with a number of functionsmapped in hardware resulting in a system with 4 busses,14 application-specific co-processors and 17 softwaretasks running on the microprocessor [16]. The all-softwaresolution had an estimate running time using the methodsdescribed above that was 160 times slower than themixed hardware-software solution. The most relevanthardware blocks were identified by performance analysis.Top of the list was the Frame-Buffer Memory-Manager (T-memory). Some additional mappings are under study now

to see whether a different micro-architecture with fewer co-processors could be safely used. Rather surprisingly giventhe complexity of the system, the estimation resultsobtained with VCC were within 5% of a cycle accuratesimulator developed at Philips, TSS, thus demonstratingthat estimation is feasible and a real help in quickarchitectural evaluations. The modeling of the micro-architecture and of the functional part of the design keptthe communication part of the design separate from thecomputation part [17]. This resulted in an accurateanalysis of the communication performance of thesystem. A major design effort in Philips is to apply the

principles of Platform-based design and rapid prototypingto their most important new generation products.

Magneti-Marelli Automotive Engine Control

This design [18] had many different features with respectto the previous one: it has a strong control component andtight safety constraints. In addition, the application had a

2 The number of lines of code in a functional specification

corresponds in general to MANY more lines of actual implementation

code. This is a sizable example!

large part of legacy design. The functionality of the engine-control automotive electronic subsystem consists of thefollowing components:

Failure detection and recovery of input sensors Computation of engine phase, status and angle,

crankshaft revolution speed and acceleration Injection and ignition control law Injection and ignition actuation drivers

The existing implementation had 135,000 line of source Ccode without comments. The first task was to extract theprecise functionality from the implementation. This wasdone by using a CFSM-based representation resulting in89 CFSMs and 56 timers. The behavior of the actuatorsand of part of the sensors was completely re-written in theformal model. For the ignition and injection control law, weencapsulated the legacy C code into 18 CFSMsrepresenting concurrent processes. The software was redesigned using the architecture described in the nextsection so that the mapping into different micro-architecture could be done with relative ease. In particular

we were able to test three different CPUs and, for each,two different software partitions to verify functionality andreal-time behavior. In addition, we explored three differentarchitectures for the I/O subsystem: one with a fulsoftware implementation, one with the use of a particularperipheral for timing functions (provided by the CPUvendor) and one with a highly optimized full hardwareperipheral of new design.

The performance estimation was performed with VCC andresulted in an error with respect to a prototype board withreal hardware of only 11%. The implementation of thefunctionality on the three platforms is under way. For two

of them it is almost completed resulting in software reusability of more than 86%. We also used thefunctionality captured in semi-formal terms to design anew dual processor architecture that is under design atST Microelectronics.

PLATFORM-BASED DESIGN

When mapping the functionality of the system to anintegrated circuit, the economics of chip design andmanufacturing are essential to determine the quality and

the cost of the system. Since the mask set and designcost for Deep Sub-Micron implementations is predicted tobe overwhelming, it is important to find commonarchitectures that can support a variety of applications aswell as the future evolutions of a given application. Toreduce design costs, re-use is a must. In particular, sincesystem designers will use more and more frequentlysoftware to implement their products, there is a need fordesign methodologies that allow the substantial re-use ofsoftware. This implies that the basic micro-architecture othe implementation is essentially fixed, i.e., the principacomponents should remain the same within a certain


10/13

Figure 2. Top-down and Bottom-up Approaches to Platform

Specification

degree of parameterization. For embedded systems,which we believe are going to be the dominant share ofthe electronics market, the basic micro-architectureconsists of programmable cores, I/O subsystem andmemories. A family of micro-architectures that allowsubstantial re-use of software is what we call a hardware platform. We believe that hardware platforms will take thelions share of the IC market. However, the concept ofhardware platform by itself is not enough to achieve thelevel of application software re-use we are looking for. Tobe useful, the hardware platform has to be abstracted at alevel where the application software sees a high-level

interface to the hardware that we call ApplicationProgram Interface or API. There is a software layer thatis used to perform this abstraction. This layer wraps thedifferent parts of the hardware platform: the programmablecores and the memory subsystem via a Real-TimeOperating System (RTOS), the I/O subsystem via theDevice Drivers, and the network connection via thenetwork communication subsystem. This layer is calledthe software platform. The combination of the hardwareand the software platforms is called the system platform.

HARDWARE PLATFORMS

Seen from the application domain, the constraints thatdetermine the hardware platform are often given in termsof performance and size. To sustain a set of functions fora particular application, a CPU should be able to run atleast at a given speed and the memory system should beof at least a given number of bytes. Since each product ischaracterized by a different set of functions, theconstraints identify different hardware platforms whereapplications that are more complex yield strongerarchitectural constraints. Coming from the hardwarespace, production and design costs imply addinghardware platform constraints and consequently reducing

the number of choices. The intersection of the two sets ofconstraints defines the hardware platforms that can beused for the final product. Note that, as a result of thisprocess, we may have a hardware platform instance thatis over-designed for a given product, that is, some of thepower of the micro-architecture is not used to implementthe functionality of that product. Over-design is verycommon for the PC platform. In several applications, theover-designed micro-architecture has been a perfec

vehicle to deliver new software products and extend theapplication space. We believe that some degree of overdesign will be soon accepted in the embedded systemcommunity to improve design costs and time-to-marketHence, the design of a hardware platform is the result ofa trade-off in a complex space that includes:

The size of the application space that can besupported by the micro-architectures belonging to thehardware platform. This represents the flexibility of thehardware platform;

The size of the micro-architecture space that satisfiesthe constraints embodied in the hardware platform

definition. This represents the degrees of freedom thatmicro-architecture providers have in designing theihardware platform instances.

Once a hardware platform has been selected, then thedesign process consists of exploring the remaining designspace with the constraints set by the hardware platform.These constraints cannot only be on the componentsthemselves but also on their communication mechanismWhen we march towards implementation by selectingcomponents that satisfy the architectural constraintsdefining a platform, we perform a successive refinementprocess where details are added in a disciplined way to

produce a hardware platform instance.

Ideally, the design process in this framework starts withthe determination of the set of constraints that defines thehardware platform for a given application. In the case of aparticular product, we advocate to start the designprocess before splitting the market into high-end and low-end products. The platform thus identified can then berefined towards implementation by adding the missinginformation about components and communicationschemes. If indeed we keep the platform unique at alllevels, we may find that the cost for the low-end market is

too high. At this point then, we may decide to introducetwo platform instances differentiated in terms operipherals, memory size and CPU power for the twomarket segments. On the other hand, by defining thenecessary constraints in view of our approach, we mayfind that a platform exists that covers both the low-endand the high-end market with great design cost and timeto-market improvements.

Hardware platform-based design optimizes globally thevarious design parameters including, as a measure ooptimality, NRE costs in both production and designHardware platform-based design is neither a top-down no

System

Design-Space

Exploration

Microarchitectural SpaceMicroarchitectural Instance

Application Instance

Application Space

System

Design-Space

Exploration

Microarchitectural SpaceMicroarchitectural Instance


Application Space


11/13

a bottom-up design methodology. Rather, it is a meet-in-the-middle approach. In a pure top-down design process,application specification is the starting point for the designprocess. The sequence of design decisions drives thedesigner toward a solution that minimizes the cost of themicro-architecture. Figure 2 shows the single applicationapproach, the bottom of the figure shows the set of micro-architectures that could implement that application. Thedesign process selects the most attractive solution as

defined by a cost function. In a bottom-up approach, agiven micro-architecture (instance of the architecturalspace) is designed to support a set of differentapplications that are often vaguely defined and is ingeneral much based on designer intuition and marketinginputs. In general, this is the approach taken by ICcompanies that try to maximize the number ofapplications (hence, the production volume) of theirplatforms.

SOFTWARE PLATFORM

The concept of hardware platform by itself is not enough

to achieve the level of application software re-use we arelooking for. To be useful, the hardware platform has to beabstracted at a level where the application software seesa high-level interface to the hardware that we callApplication Program Interface (API) or ProgrammersModel. There is a software layer that is used to performthis abstraction (Figure 3). This layer wraps the essentialparts of the hardware platform:

The programmable cores and the memory subsystemvia a Real Time Operating System (RTOS),

The I/O subsystem via the Device Drivers, and The network connection via the network

communication subsystem3.

This layer is called the software platform. In ourconceptual framework, the programming language is theabstraction of the ISA, while the API is the abstraction ofa multiplicity of computational resources (concurrencymodel provided by the RTOS) and available peripherals(Device Drivers). 4 There are different efforts that try tostandardize the API or Programmers Model. In ourframework, the API or Programmers Model is a uniqueabstract representation of the hardware platform. With anAPI so defined, the application software can be re-used for

every platform instance.

Of course, the higher the abstraction layer at which aplatform is defined, the more instances it contains. Forexample, to share source code, we need to have thesame operating system but not necessarily the sameinstruction set, while to share binary code, we need to

3 In some cases, the entire software layer, including the Device

Drivers and the network communication subsystem is called RTOS.4 There are several languages that abstract or embed the

concurrency model directly, avoiding the RTOS abstraction.

add the architectural constraints that force to use thesame ISA, thus greatly restricting the range oarchitectural choices.

Output DevicesInput devices

Hardware Platform

I O

Hardware

Software

network

Software Platform

Application Software Platform API

RTOS

BIOS

Device Drivers

Ne

tworkCommunication

Software Platform

Figure 3: Layered software structure

In our framework, the RTOS is responsible for thescheduling of the available computing resources and othe communication between them and the memorysubsystem. Note that in most of the embedded systemapplications, the available computing resources consist ofa single microprocessor. However, in general, we canimagine a multiple core hardware platform where theRTOS schedules software processes across differencomputing engines.

There is a battle that is taking place in this domain toestablish a standard RTOS for embedded applications.For example, traditional embedded software vendors suchas ISI and WindRiver are now competing with Microsofthat is trying to enter this domain by offering WindowsCE, a stripped down version of the API of its Windowsoperating system. In our opinion, if the conceptuaframework we offer here is accepted, the precise definitionof the hardware platform and of the API should allow tosynthesize automatically and in an optimal way most ofthe software layer, a radical departure from the standardmodels borrowed from the PC world. Software re-use, i.eplatform re-targetability, can be extended to these layers

(middle-ware) hopefully resulting more effective than binarycompatibility.


12/13

Figure 4. Platform Abstraction and Design Flow

SYSTEM PLATFORMS

In summary, the development of programmable solutioninvolves understanding the application domain, developingan architecture and micro-architecture that is specializedto that application domain, as well as the development ofsoftware development tools to program the specializedarchitecture.

One of the major challenges in this regard is developing

an understanding what it means to program a complexsystem efficiently. The central question to be addressedhere is: "What is the programmers' model?" Or "Howshould the programmer view the underlying hardware andinput/output systems?" On the one hand, we want to hideas many of the details of the underlying implementationas possible, while on the other we want to make visible asufficient level of control that the application programmercan develop an efficient solution--in terms of performance,power, and reliable functionality.

The basic ideas of system platform and platform-baseddesign are captured in Figure . The vertex of the twocones represents the API or Programmers Model, i.e.,the abstraction of the hardware platform. A systemdesigner maps its application into the abstractrepresentation that includes a family of micro-architectures that can be chosen to optimize cost,efficiency, energy consumption and flexibility. Themapping of the application into the actual architecture inthe family specified by the Programmers Model or APIcan be carried out, at least in part, automatically if a setof appropriate software tools (e.g., software synthesis,RTOS synthesis, device-driver synthesis) is available. It is

clear that the synthesis tools have to be aware of thearchitecture features as well as of the API.

In the design space, there is an obvious trade-off betweenthe level of abstraction of the Programmers Model and thenumber and diversity of the platform instances coveredThe more abstract the Programmers Model the richer isthe set of platform instances but the more difficult it is tochoose the optimal platform instance and map

automatically into it. Hence, we envision a number ofsystem platforms that will be handled with somewhatdifferent abstractions and tools. For example, moretraditional platforms that include a small number ostandard components such as microprocessors andDSPs will have an API that is simpler to handle thanreconfigurable architectures. In the next section, we willshow examples of application of the concepts exposed sofar. One is related to the design of next generationwireless systems, the other on a class of reconfigurablearchitectures, their Programmers Model and tools to mapapplications onto an architecture.

CONCLUSION

We have presented some considerations about the futureof electronic devices and infrastructures as they affect theworld of car manufacturing and design. In particular, stressed the issues related to the choice and design ofintegrated platforms. I argued that a rigorous designmethodology based on separation of concerns isessential. I presented a novel concept of hardwaresoftware and system platforms that could be used toreduce substantially design time and cost. The challengesahead of us are great, but the opportunities are enormousWe are on the edge of a revolution in the way a car isconceived and designed.

ACKNOWLEDGMENTS

Several people were instrumental in building the visionpresented in this paper: the initial inspiration came fromDr. Pecchini, General Manager of the Power-train Divisionof Magneti-Marelli; the first environment built on theseideas was developed in close collaboration with ProfLuciano Lavagno, University of Udine and CadenceLaboratories; the mathematical formalism came from thejoint work with Max Chiodo of Cadence Design Systems

Inc. and Luciano Lavagno; the VCC architecture was builwith Dr. Jim Rowson. Dr. Alberto Ferrari shared his workon platform-based design and was the main actor in theapplication of the methodology to the engine controproblem. Dr. Wolfgang Reitzle formerly with BMW andnow with Ford was a very strong supporter of the workpresented here. Dr. Patrick Popp of BMW TechnologyCenter in Palo Alto provided resources for the project andshared its vision. Giovanni Gaviani of Magneti-MarellPower-train Division gave his inputs and important viewsinto the future of engines and cars. This research hasbeen supported by the Giga-scale Silicon Research

PlatformDesign-Space

Exploration

PlatformSpecification

Architectural Space

Application Space


Platform Instance

SystemPlatform

PlatformDesign-Space

Exploration

PlatformSpecification

Architectural Space

Application Space


Platform Instance

SystemPlatform


13/13

Center and the Consiglio Nazionale delle Ricerche,Progetto MADESSII.

REFERENCES

1. M. Pinto, CTO Lucent Microelectronics, private communication, June 1999.2. F. Balarin et al., Hardware-Software Co-Design of Embedded Systems: The POLIS Approach, Kluwer Publishing Co.

1998.3. J. Rowson and A. Sangiovanni-Vincentelli, System Level Design, EE Times, 1996.4. J. Rowson and A. Sangiovanni-Vincentelli, Interface-based Design, Proceedings of the 34th Design Automation

Conference(DAC-97). pp. 178-183, Las Vegas, June 1997.5. C. Szyperski, Component Software: Beyond Object-Oriented Software, ACM Press, Addison-Wesley 19986. A. Sangiovanni-Vincentelli, R. McGeer and A. Saldanha, Verification of Integrated Circuits and Systems, Proc. Of 1996

Design Automation Conference, June 1996.7. E. Lee and A. Sangiovanni-Vincentelli, A Unified Framework for Comparing Models of Computation, IEEE Trans. on

Computer Aided Design of Integrated Circuits and Systems, Vol. 17, N. 12, pp. 1217-1229, December 1998.8. M.Sgroi, L.Lavagno, A.Sangiovanni-Vincentelli, Formal Models for Embedded System Design, To appear in IEEE Design

& Test of Computers. Special Issue on System Design, 2000.9. J.L. da Silva Jr., M. Sgroi, F. De Bernardinis, S.F. Li, A. Sangiovanni-Vincentelli, J. Rabaey Wireless Protocols Design

Challenges and Opportunities, 8th International Workshop on Hardware/Software Co-Design Codes/CASHE '00, DiegoCA May 2000.

10. C. G. Bell and A. Newell, "Computer Structures: Readings and Examples," McGraw-Hill, New York, 1971.11. A. Ferrari and A. Sangiovanni-Vincentelli, System Design: Traditional Concepts and New Paradigms, Proceedings of the1999 Int. Conf. On Comp. Des., Austin, Oct. 1999.

12. H. Chang et al., Surviving the SOC Revolution: Platform-based Design, Kluwer Academic Publishing, 1999.13. J-Y. Brunel, A. Sangiovanni-Vincentelli and Rainer Kress, COSY: a methodology for system design based on reusable

hardware & software IP's, in: J-Y. Roger (ed.), Technologies for the Information Society, IOS Press, pp. 709-716, June1998

14. J. Davis II, M. Goel, C. Hylands, B. Kienhuis, E. A. Lee, Jie Liu, X. Liu, L. Muliadi, S. Neuendorffer, J. Reekie, N. SmythJ. Tsay and Y. Xiong, An Oveview of the Ptolemy Project, ERL Technical Report UCB/ERL No. M99/37, Dept. EECS,University of California, Berkeley, CA 94720, July 1999.

15. E.A. de Kock, G. Essink, W. Smits, van der Wolf, J-Y. Brunel, W. Kruijtzer, P. Lieverse and K. Vissers, YAPIApplication Modeling for Signal Processing Systems, DAC2000, Los Angeles, June 2000

16. H. Kenter, C. Passerone, W. Smits, Y. Watanabe and A. Sangiovanni-Vincentelli, Designing Digital Video Systems

Modeling and Scheduling, CODES99, Rome, May 199917. J-Y. Brunel, W. Kruijtzer, H. Kenter, F. Ptrot, L. Pasquier, E. de Kock and W. Smits, COSY Communication IPs,

DAC2000, Los Angeles, June 200018. M. Baleani, A. Ferrari, A. Sangiovanni-Vincentelli and C. Turchetti, Hardware-Software Co-design of an Engine

Management System, Proc. of DATE 2K, Paris, March 2000.

automotive electronics - trends and challenges

Documents