X hits on this document

PDF document






3 / 11



current systems is essential. Whether imple- menting the silicon as a single, large chip or a collection of smaller chips interacting across a distance, designers must deal with concurrent processing and communication in a uniform and scalable manner. In any large-scale embedded system, designers must consider concurrency a first-class citizen at all abstrac- tion levels and in both hardware and software.

Separation of concerns: communication and behavior. Concurrency implies communica- tion among design components. Communi- cation is too often intertwined with design component behavior, making it difficult to separate the two. Separating communication and behavior is essential to handling system design complexity. It is difficult to reuse com- ponents if their behavior depends on com- munication with other components of the original design. In addition, because design- ers can describe communication at various abstraction levels, they can potentially imple- ment communication behavior in many forms according to the available resources. Toda , designers seldom exploit this freedom.

Multple chips. Next-generation systems will probably use a few highly complex (Moore’s law–limited) part types, and many more ener- gy- and power-efficient, medium-complexity chips (with 10 million to 100 million gates in 50-nm technology). All these chips will work concurrently to solve complex sensing, com- puting, signaling, and actuating problems.

Platform-based design. System developers will most likely develop these chips as instances of a particular platform. That is, rather than assembling the chips from a collection of inde- pendently developed blocks of silicon func- tionality, system developers will derive them from a specific microarchitecture family, or platform, possibly aimed at a particular class of problems. System developers can modify (extend or reduce) these platforms. The plat- forms will support extensibility mainly through the use of large blocks of functional- ity (for example, in the form of coprocessors), but they will support extensibility in the mem- ory and communication architecture as well. When selecting a platform, designers must consider cost, size, energy consumption, and


flexibility. A platform has much wider applic- ability than an application-specific IC (ASIC), so design decisions are crucial. A less than excellent choice can result in an economic debacle. Hence, design methods and tools that optimize the platform selection process are very important.

Software programmability. Platforms will be highly programmable at various granularity levels—at instruction level for microproces- sors, at gate level for field-programmable gate array (FPGA) blocks. Consequentl , mapping an application into a platform efficiently will require a set of software design tools that resemble logic synthesis tools. This will be a fruitful research area.

Current automotive system-level design

Automobiles’ real-time and safety-critical electronics systems are implemented as dis- tributed architectures that typically include several ECUs communicating via one or more networked broadcast buses. These buses are controlled by communication protocols such as controller area network (CAN), time-trig- gered protocol (TTP), local interconnect net- work (LIN), and FlexRay.

Each ECU includes

  • application and diagnostic software;

  • base software—for example, real-time operating system (RTOS) and commu- nication layers;

  • one or more microcontrollers with local memories and bus controllers with one or more channels, to support redundan- cy for fault-tolerant systems and complex bus architectures such as constellations and star couplers; and

  • optional dual-ported RAMs for com- munications between bus controllers and microcontrollers and between CPUs within the same ECU.

Automotive applications (such as control systems for steering and braking) have intro- duced a new design dimension—the system’s distributed nature—that adds complexity yet also provides the potential for optimizations such as reducing the number of ECUs needed. In fact, better use of each ECU potentially reduces the number of ECUs in a distributed

Document info
Document views38
Page views38
Page last viewedWed Jan 18 02:08:34 UTC 2017