78.htm

pcb设计资料初学者难得的入门资料包含工厂制作过程

s no longer in production, depending on the availability of a replacement sy <br>
stem. This problem is a significant concern on the Distributed example syste <br>
m. <br>
Design challenge: <br>
· Cost-effectively update old designs to incorporate new components. <br>
6. Business model <br>
The business models under which embedded systems are developed can vary as w <br>
idely as the applications themselves. Costs, cycle time, and the role of pro <br>
duct families are all crucial business issues that affect design decisions. <br>

6.1. Design vs. production costs <br>
Design costs, also called Non-Recurring Engineering costs (NRE), are of majo <br>
r importance when few of a particular embedded system are being built. Conve <br>
rsely, production costs are important in high-volume production. Embedded sy <br>
stems vary from single units to millions of units, and so span the range of <br>
tradeoffs between design versus production costs. <br>
At the low-volume end of the spectrum, CAD tools can help designers complete <br>
 their work with a minimum of effort. However, at the high-volume end of the <br>
 spectrum the designs may be simple enough and engineering cost such a small <br>
 fraction of total system cost that extensive hand-optimization is performed <br>
 in order to reduce production costs. <br>
CAD tools may be able to outperform an average engineer at all times, and a <br>
superior engineer on very large designs (because of the limits of human capa <br>
city to deal with complexity and repetition). However, in small designs some <br>
 embedded computer designers believe that a superior human engineer can outp <br>
erform CAD tools. In the Small system example a programmer squeezed software <br>
 into a few hundred bytes of memory by hand when the compiler produced overl <br>
y large output that needed more memory than was available. It can readily be <br>
 debated whether CAD tools or humans are "better" designers, but CAD tools f <br>
ace skepticism in areas that require extraordinary optimization for size, pe <br>
rformance, or cost. <br>
Design challenge: <br>

· Intelligently trade off design time versus production cost. <br>
6.2. Cycle time <br>
The cycle time between identification of a product opportunity and product d <br>
eployment (also called Time to Market) can be quite long for embedded system <br>
s. In many cases the electronics are not the driving force; instead, product <br>
 schedules are driven by concerns such as tooling for mechanical components <br>
and manufacturing process design. Superficially, this would seem to imply th <br>
at design time for the electronics is not an overriding concern, but this is <br>
 only partially true. <br>
Because the computer system may have the most malleable design, it may absor <br>
b the brunt of changes. For example, redesign of hardware was required on th <br>
e Mission Critical example system when it was found that additional sensors <br>
and actuators were needed to meet system performance goals. On the Small exa <br>
mple system, delays in making masked ROM changes in order to revise software <br>
 dominate concerns about modifications (and programmable memory is too expen <br>
sive). So, although the initial design is often not in the critical path to <br>
product deployment, redesign of the computer system may need to be done quic <br>
kly to resolve problems. <br>
Design challenge: <br>
· Rapid redesign to accommodate changing form factors, control algorithms, <br>
and functionality requirements. <br>
6.3. Product families <br>

In many cases embedded system designs are not unique, and there are a variet <br>
y of systems of various prices and capabilities forming a product family. To <br>
 the extent that system designers can reuse components, they lower the total <br>
 cost of all systems in the product family. <br>
However, there is a dynamic tension between overly general solutions that sa <br>
tisfy a large number of niche requirements, and specifically optimized desig <br>
ns for each point in a product family space. Also, there may be cases in whi <br>
ch contradictory requirements between similar systems prevent the use of a s <br>
ingle subsystem design. In the Mission Critical and Small examples different <br>
 customers require different interfaces between the embedded system and thei <br>
r equipment. In the Distributed example regulatory agencies impose different <br>
 safety-critical behavior requirements depending on the geographic area in w <br>
hich the system is deployed. <br>
Design challenge: <br>
· Customize designs while minimizing component variant proliferation. <br>
7. Design culture <br>
Design is a social activity as well as a technical activity. The design of d <br>
esktop computers, and CPUs in particular, has matured in terms of becoming m <br>
ore quantitative in recent years. With this new maturity has come an emphasi <br>
s on simulation and CAD tools to provide engineering tradeoffs based on accu <br>
rate performance and cost predictions. <br>
Computer designers venturing into the embedded arena must realize that their <br>

 culture (and the underlying tool infrastructure) are unlike what is commonl <br>
y practiced in some other engineering disciplines. But, because embedded sys <br>
tem design requires a confluence of engineering skills, successful computer <br>
designers and design methodologies must find a harmonious compromise with th <br>
e techniques and methodologies of other disciplines as well as company manag <br>
ement. Also, in many cases the engineers building embedded computer systems <br>
are not actually trained in computer engineering (or, perhaps not even elect <br>
rical engineering), and so are not attuned to the culture and methodologies <br>
of desktop computer design. <br>
7.1. Computer culture vs. other cultures <br>
A specific problem is that computer design tools have progressed to the poin <br>
t that many believe it is more cost-effective to do extensive simulation tha <br>
n build successive prototypes. However, in the mechanical arena much existin <br>
g practice strongly favors prototyping with less exhaustive up-front analysi <br>
s. Thus, it may be difficult to convince project managers (who may be applic <br>
ation area specialists rather than computer specialists) to spend limited ca <br>
pital budgets on CAD tools and defer the gratification of early prototype de <br>
velopment in favor of simulation. <br>
Design challenge: <br>
· Make simulation-based computer design accessible to non-specialists. <br>
7.2. Accounting for cost of engineering design <br>
One area of common concern is the effectiveness of using engineers in any de <br>

sign discipline. But, some computer design CAD tools are very expensive, and <br>
 in general organizations have difficulty trading off capital and tool costs <br>
 against engineering time. This means that computer designers may be deprive <br>
d of CAD tools that would reduce the total cost of designing a system. <br>
Also, in high-volume applications engineering costs can be relatively small <br>
when compared to production costs. Often, the number of engineers is fixed, <br>
and book-kept as a constant expense that is decoupled from the profitability <br>
 of any particular system design, as is the case in all four example systems <br>
. This can be referred to as the "Engineers Are Free" syndrome. But, while t <br>
he cost of engineering time may have a small impact on product costs, the un <br>
availability of enough engineers to do work on all the products being design <br>
ed can have a significant opportunity cost (which is, in general, unmeasured <br>
). <br>
Design challenge: <br>
· Improved productivity via using tools and methodologies may be better rec <br>
eived by managers if it is perceived to increase the number of products that <br>
 can be designed, rather than merely the efficiency of engineers on any give <br>
n product design effort. This is a subtle but, in practice, important distin <br>
ction. <br>
7.3. Inertia <br>
In general, the cost of change in an organization is high both in terms of m <br>
oney and organizational disruption. The computer industry can be thought of <br>

as being forced to change by inexorable exponential growth in hardware capab <br>
ilities. However, the impact of this growth seems to have been delayed in em <br>
bedded system development. In part this is because of the long time that ela <br>
pses between new technology introduction and wide-scale use in inexpensive s <br>
ystems. Thus, it may simply be that complex designs will force updated CAD t <br>
ools and design methodologies to be adopted for embedded systems in the near <br>
 future. <br>
On the other hand, the latest computer design technologies may not have been <br>
 adopted by many embedded system makers because they aren't necessary. Tool <br>
development that concentrates on the ability to handle millions of transisto <br>
rs may simply not be relevant to designers of systems using 4- and 8-bit mic <br>
roprocessors that constitute the bulk of the embedded CPU market. And, even <br>
if they are useful, the need for them may not be compelling enough to justif <br>
y the pain and up-front expense of change so long as older techniques work. <br>
That is not to say that new tools aren't needed, but rather that the force o <br>
f cultural inertia will only permit adoption of low-cost tools with signific <br>
ant advantages to the problem at hand. <br>
Design challenge: <br>
· Find/create design tools and methodologies that provide unique, compellin <br>
g advantages for embedded design. <br>
8. Conclusions <br>
Many embedded systems have requirements that differ significantly both in de <br>

tails and in scope from desktop computers. In particular, the demands of the <br>
 specific application and the interface with external equipment may dominate <br>
 the system design. Also, long life-cycles and in some cases extreme cost se <br>
nsitivity require more attention to optimization based on these goals rather <br>
 than maximizing the computational throughput. <br>
The business and cultural climates in many embedded system design situations <br>
 are such that traditional simulation-based computer design techniques may n <br>
ot be viable in their current form. Such methodologies may not be cost-effec <br>
tive given constraints on categories of expenditures, may not be seen as wor <br>
thwhile by non-computer-trained professionals, or may simply be solving the <br>
wrong problems. <br>
Recent interest in hardware/software codesign is a step in the right directi <br>
on, as it permits tradeoffs between hardware and software that are critical <br>
for more cost-effective embedded systems. However, to be successful future t <br>
ools may well need to increase scope even further to include life-cycle issu <br>
es and business issues. <br>
The tutorial slide presentation presented at the conference augments this pa <br>
per, and may be found at: http://www.cs.cmu.edu/~koopman/iccd96 <br>
  <br>
-- <br>
※ 来源:·BBS 水木清华站 smth.org·[FROM: 202.204.8.215] <br>
</small><hr>
<p align="center">[<a href="嵌入式系统.htm">回到开始</a>][<a href="57.htm">上一层</a>][<a href="79.htm">下一篇</a>]
<p align="center"><a href="http://cterm.163.net">欢迎访问Cterm主页</a></p>
</table>
</body>
</html>