📄 00000010.htm
字号:
<?xml version="1.0" encoding="gb2312"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=gb2312"/><title>嵌入式系统的开发 afh </title></head><body><center><h1>BBS 水木清华站∶精华区</h1></center><a name="top"></a>发信人: beary (京酱肉丝), 信区: Embedded <br />标 题: 嵌入式系统的开发 <br />发信站: BBS 水木清华站 (Fri May 19 17:59:09 2000) <br /> <br />1. Introduction <br />Approximately 3 billion embedded CPUs are sold each year, with smaller (4-, <br />8-, and 16-bit) CPUs dominating by quantity and aggregate dollar amount [1]. <br /> Yet, most research and tool development seems to be focussed on the needs o <br />f high-end desktop and military/aerospace embedded computing. This paper see <br />ks to expand the area of discussion to encompass a wide range of embedded sy <br />stems. <br />The extreme diversity of embedded applications makes generalizations difficu <br />lt. Nonetheless, there is emerging interest in the entire range of embedded <br />systems (e.g., [2], [3], [4], [5], [6]) and the related field of hardware/so <br />ftware codesign (e.g., [7]). <br />This paper and the accompanying tutorial seek to identify significant areas <br />in which embedded computer design differs from more traditional desktop comp <br />uter design. They also present "design challenges" encountered in the course <br /> of designing several real systems. These challenges are both opportunities <br />to improve methodology and tool support as well as impediments to deploying <br />such support to embedded system design teams. In some cases research and dev <br />elopment has already begun in these areas -- and in other cases it has not. <br />The observations in this paper come from the author's experience with commer <br />cial as well as military applications, development methodologies, and life-c <br />ycle support. All characterizations are implicitly qualified to indicate a t <br />ypical, representative, or perhaps simply an anecdotal case rather than a de <br />finitive statement about all embedded systems. While it is understood that e <br />ach embedded system has its own set of unique requirements, it is hoped that <br /> the generalizations and examples presented here will provide a broad-brush <br />basis for discussion and evolution of CAD tools and design methodologies. <br />2. Example Embedded Systems <br />Figure 1 shows one possible organization for an embedded system. <br />Figure 1. An embedded system encompasses the CPU as well as many other resou <br />rces. <br />In addition to the CPU and memory hierarchy, there are a variety of interfac <br />es that enable the system to measure, manipulate, and otherwise interact wit <br />h the external environment. Some differences with desktop computing may be: <br />· The human interface may be as simple as a flashing light or as complicate <br />d as real-time robotic vision. <br />· The diagnostic port may be used for diagnosing the system that is being c <br />ontrolled -- not just for diagnosing the computer. <br />· Special-purpose field programmable (FPGA), application specific (ASIC), o <br />r even non-digital hardware may be used to increase performance or safety. <br />· Software often has a fixed function, and is specific to the application. <br />In addition to the emphasis on interaction with the external world, embedded <br /> systems also provide functionality specific to their applications. Instead <br />of executing spreadsheets, word processing and engineering analysis, embedde <br />d systems typically execute control laws, finite state machines, and signal <br />processing algorithms. They must often detect and react to faults in both th <br />e computing and surrounding electromechanical systems, and must manipulate a <br />pplication-specific user interface devices. <br />Table 1. Four example embedded systems with approximate attributes. <br />In order to make the discussion more concrete, we shall discuss four example <br /> systems (Table 1). Each example portrays a real system in current productio <br />n, but has been slightly genericized to represent a broader cross-section of <br /> applications as well as protect proprietary interests. The four examples ar <br />e a Signal Processing system, a Mission Critical control system, a Distribut <br />ed control system, and a Small consumer electronic system. The Signal Proces <br />sing and Mission Critical systems are representative of traditional military <br />/aerospace embedded systems, but in fact are becoming more applicable to gen <br />eral commercial applications over time. <br />Using these four examples to illustrate points, the following sections descr <br />ibe the different areas of concern for embedded system design: computer desi <br />gn, system-level design, life-cycle support, business model support, and des <br />ign culture adaptation. <br />Desktop computing design methodology and tool support is to a large degree c <br />oncerned with initial design of the digital system itself. To be sure, exper <br />ienced designers are cognizant of other aspects, but with the recent emphasi <br />s on quantitative design (e.g., [8]) life-cycle issues that aren't readily q <br />uantified could be left out of the optimization process. However, such an ap <br />proach is insufficient to create embedded systems that can effectively compe <br />te in the marketplace. This is because in many cases the issue is not whethe <br />r design of an immensely complex system is feasible, but rather whether a re <br />latively modest system can be highly optimized for life-cycle cost and effec <br />tiveness. <br />While traditional digital design CAD tools can make a computer designer more <br /> efficient, they may not deal with the central issue -- embedded design is a <br />bout the system, not about the computer. In desktop computing, design often <br />focuses on building the fastest CPU, then supporting it as required for maxi <br />mum computing speed. In embedded systems the combination of the external int <br />erfaces (sensors, actuators) and the control or sequencing algorithms is or <br />primary importance. The CPU simply exists as a way to implement those functi <br />ons. The following experiment should serve to illustrate this point: ask a r <br />oomful of people what kind of CPU is in the personal computer or workstation <br /> they use. Then ask the same people which CPU is used for the engine control <br />ler in their car (and whether the CPU type influenced the purchasing decisio <br />n). <br />In high-end embedded systems, the tools used for desktop computer design are <br /> invaluable. However, many embedded systems both large and small must meet a <br />dditional requirements that are beyond the scope of what is typically handle <br />d by design automation. These additional needs fall into the categories of s <br />pecial computer design requirements, system-level requirements, life-cycle s <br />upport issues, business model compatibility, and design culture issues. <br />3. Computer Design Requirements <br />Embedded computers typically have tight constraints on both functionality an <br />d implementation. In particular, they must guarantee real time operation rea <br />ctive to external events, conform to size and weight limits, budget power an <br />d cooling consumption, satisfy safety and reliability requirements, and meet <br /> tight cost targets. <br />3.1. Real time/reactive operation <br />Real time system operation means that the correctness of a computation depen <br />ds, in part, on the time at which it is delivered. In many cases the system <br />design must take into account worst case performance. Predicting the worst c <br />ase may be difficult on complicated architectures, leading to overly pessimi <br />stic estimates erring on the side of caution. The Signal Processing and Miss <br />ion Critical example systems have a significant requirement for real time op <br />eration in order to meet external I/O and control stability requirements. <br />Reactive computation means that the software executes in response to externa <br />l events. These events may be periodic, in which case scheduling of events t <br />o guarantee performance may be possible. On the other hand, many events may <br />be aperiodic, in which case the maximum event arrival rate must be estimated <br /> in order to accommodate worst case situations. Most embedded systems have a <br /> significant reactive component. <br />Design challenge: <br />· Worst case design analyses without undue pessimism in the face of hardwar <br />e with statistical performance characteristics (e.g., cache memory [9]). <br />⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -