EEPW论坛

Embedded Systems Programming (03/16/05, 14:55:00 H EST)

From theory to practice, this article comes from one who's done it all. Hardware/software codesign is the goal of every (well, most) embedded systems designers. To have the hardware and the software both spring forth from the same designer's pen is enough to make any manager glad.

As consumers develop an insatiable[不知足的] desire for instant information, embedded systems are here to both satisfy the need and fuel the desire. These systems, from the consumer gadgets [小玩意] to the safety-critical technology, have permeated[渗透] our lives almost to the point where we depend on them directly or indirectly not just for entertainment but for food, clothing, and shelter[庇护所]. The demand for increased embedding of hardware and software in multifaceted consumer products coupled with rising design complexity and shortening time-to-market is renewing the emphasis on bringing together the various segments of the embedded system design industry. Codesign of hardware and software is back in vogue[流行]. At long last[好容易才], codesign, now known as embedded system-level design, is starting to mature.

This article describes the evolution of codesign, what went wrong with early codesign methods, and its revival and great hope: the transaction-level[事务级] method.

Intro to codesignHardware/software codesign is a loose term that encompasses a large slice of embedded systems design, trade-off analysis, and optimization starting from the abstract function and architecture specification down to the detailed hardware and software implementation. If the method of using "interchangeable parts" introduced by Eli Whitney in 1799 is the precursor[先驱] to the industrial revolution, then hardware/software codesign is the enabler of the embedded systems revolution.

Hardware/software codesign involves analysis and trade-offs: analyzing the hardware and software as they work together and discovering what adjustments or trade-offs you need to make to match your parameters. For example, anytime you debug a software driver on the hardware (or a model of the hardware), and you tweak[拧->调节] the hardware or the software as a result, that's codesign. To put it more simply, any time you run a compiler you're doing codesign. The compiler tries to finagle[欺骗] the software code (to a degree that depends on your optimization flags) to make it match the fixed-hardware processor. In many cases engineers even use hardware hints (for example, the register keyword in C) in the programming language itself to suggest how the optimization or codesign should be done.

The field of codesign, however, has long been a victim of its own visionary[幻想的] breadth[宽度], torn[tear的过去分词] between idealism and realism. Many practitioners[从业者] have proclaimed it dead because its ideals of top-down embedded systems design starting from high abstraction layers have proven too unwieldy. The other camp—the codesign realists[现实主义者]—says the practice is very much alive as bottom-up intellectual property (IP) component assembly.

A version of codesign has now come along[出现] that may please both camps. To make sense of it, let's first look at how codesign evolved.

Rise and decline The codesign concept was born in the 1990s following the widespread adoption of hardware-synthesis tools and rising interest in software synthesis. Until that time, creating software was a manual[手动的] undertaking[任务] for the most part. Microcontrollers were the mainstay[中流砥柱] of embedded systems, and programming them efficiently within strict performance and memory constraints was an art. Most early applications were control systems used in industrial and automotive domains.

In these applications, the system control—the interaction of the controller with the RTOS and the peripherals—was typically designed first, forming a shell into which the data-path components such as arithmetic logic units, multipliers, and shifters would fit. The software was typically used in such systems to add flexibility through programmability. The software wasn't so much [与其说…不如说…] application "feature" software but a soft implementation of the required control functions.

Industry awareness of the toll exacted[强求] by unreliable code and long development times led to academic curiosity[好奇心] in software modeling and automated synthesis. Academic research camps were polarized[两极分化] according to the application domain: a majority studied control-intensive applications while others worked on data-dominated applications.

Early on[在早期], researchers adapted methods for synthesizing hardware logic (for control) and data path (for data) to simultaneously design hardware/software and their interfaces. The motivating idea was to start from a single system-level specification and automatically generate both the hardware and the software to reduce design time and the time spent evaluating different implementation alternatives. At first, the researchers limited their focus to analyzing the trade-offs of low-level hardware/software implementation and the best methods for cosimulation, but complex target architectures made it increasingly hard to adequately analyze and optimize the system at the low hardware/software level. Newer 32-bit microprocessors and a variety of DSPs tailored for different applications were in greater use, and their advanced memory hierarchies with multilevel caches severely limited the accuracy of the abstract models built on function-control abstractions.

(待续...)

[align=right][color=#000066][此贴子已经被作者于2005-3-23 12:51:24编辑过][/color][/align]