抽象工具排解系统设计复杂性
点击数：7642 次 录入时间：03-04 11:59:12 整理：http://www.55dianzi.com DSP/FPGA技术
嵌入式开发工具不断包含更高层次的抽象来平衡设计复杂性的增长 要点
抽象通过隐藏细节来降低复杂性。
抽象不会减少某项设计的细节数量。
自动化开发工具可简化以前的创新设计思路和实现方法，并使之商品化。
抽象隐藏细节，但不应该妨碍您检查细节。
复杂性是相对的。如果您无法在特定环境内描绘问题的特性并了解问题，那么复杂性就会使您无法解决问题。同时，复杂性为你提供制造出与众不同产品的机会。再则，复杂性如果被你攻克，就会成为您搞出与众不同设计的基础，并成为竞争对手的障碍，尽管是临时障碍。如果没有足够的复杂性，就很难提供独特的增值功能， 这是因为竞争对手可以很容易地仿制您的开发成果，并在他们的产品中增加这些功能。
一条工程经验法则是：设计小组能够以最低成本，在最短的开发时间内交付组合有最佳功能的产品，条件是他们只关注其中的两个要素，牺牲第三个要素。在一个竞争的领域内，至关重要的是要实现所有这三个要素，这又会提高设计成果的总复杂性（附文《无法满足的胃口》）。幸好，您不必彻底了解产品的每一个细节就能使用它。使用能支持特定领域的抽象工具或能为自己正在研制的系统创建特定抽象的工具，就是一种降低设计复杂性、提高开发效率的技术。
抽象是对某系统的细节进行组织的过程，这样您就可以专注于总体情况的关键要素。抽象并不会减少——甚至还可能增加——您必须为某项设计而要处理的细节数量。然而，抽象能够组织这些细节，以便您能减少你为设计中任何一部分必须考虑的细节数量。建立有用抽象的挑战性在于根据环境和谁将使用这些抽象，确定哪些性能是必不可少的，哪些性能是可以忽略的。抽象是智能框架，从多个方面对某个系统进行抽象也许是很有用的。设计师和用户也许需要使用同一系统的不同抽象。对于分层抽象来说，工作在每个抽象层次的设计师也许需要与一组不同的细节打交道。
对某个系统适当地进行抽象，可以为设计小组的每名成员降低系统复杂性，这是因为您可以避免每位设计师去考虑不相关的细节。实际上，您是在简化和限定每一位设计师必须面对的条件范围。抽象某个系统，可能有利于汇总系统微观行为，以便能在宏观层次揭示微观行为，使之概念化，再进行处置。有时，不必了解各事件的具体顺序就可以从存储器中提取数据，或对这些数据进行算术运算。然而有些时候，例如，当您的系统对连续数据流进行实时的计算密集型操作时，了解并控制这两种机制的细节对于项目的成功是至关重要的。
抽象某个系统可以帮助您鉴别、隔离并管理一个系统的逻辑部件之间在计算和接口两个方面的相关性，这样您就能在各部分中解决大问题。如果您缺乏恰当的词汇和其它符号工具来表述某个问题，您就会在解决该问题时面临严重的障碍。恰当地抽象某个系统，可以为您提供词汇和符号集，从而在设计小组成员之间就各个部分及其相互关系进行有意义的沟通。恰当的词汇和符号集是适用于特定应用和特定领域的。一个标准的或通用的符号集可能无法使您充分表述您正在努力解决的系统和问题，它可能会使您偏向采用一种次优方法。
工具、工具、工具
产品设计正在一代一代地增加占用更多处理能力的复杂功能，而产品设计周期比以往任何时候都短。为了跟上这些设计日益提高的复杂性，开发小组可以依靠以下手段：重复使用既有设计；获得第三方知识产权 (IP) 的许可证；使用各种抽象或隐藏目标平台实现细节的工具。汇编器、编译器、建模工具、代码发生器、操作系统和外设驱动程序都能隐藏目标处理平台的细节，而且一般都能提高设计师的工作效率。这几类工具通常不提供应用级抽象；它们按分层方式工作，从而抽象目标实现细节并使之自动化，而无需了解系统的行为。
另一类代码发生器，比如 CeloxICa 公司和 Stretch 公司的产品，有助于把 C 源码自动转换成硬件块。这些工具使您能够保持一致的软件开发方法，并仍能受益于采用并行单元的硬件处理速度加快。ACCelChip 公司和 Catalytic 公司的代码发生器工作于更高的层次，直接依靠 Matlab 文件，来生成可合成的 RTL，或把浮点模型转换成定点目标代码。
应用抽象工具试图使系统行为与实现方法无关。Aonix公司、The MathWorks公司、National Instruments公司、Teja 公司提供的工具，能为十分关键的信号安全处理或高度并行的多处理器应用系统提供特定域抽象。特定域抽象工具包括合适的符号工具和结构，而这些工具与结构使您能更自然地表述和探索该域中的设计方法，不过在目标域之外，它们的用处通常是有限的。通用抽象工具，如 I-Logix 公司和 IBM 公司的 UML（统一建模语言）工具， 使您能够创建自己的抽象，而且在更广的应用范围内都很有用，但要依靠您运用您的工程专业知识来构建有意义的特定域抽象。
图 1，UML 是OMG公司 的模型驱动体系结构的基础。与平台无关的模型包含系统行为，而特定平台模型根据特定平台映射规则和与平台无关模型的标记，包含实现细则。MDA（模型驱动的体系结构）开发工具使系统行为细节的建模与实现方法细节的建模无关，具体做法是将这些模型分割成与UML 平台无关的模型和特定平台模型（图 1）。与平台无关模型不包括技术实现细节，侧重于描述系统的功能和行为。MDA 开发工具应用映射模板来产生特定平台模型。为了实现这种转换，您必须精确调节与平台无关的模型，并对它做注释，以便加进语义学和规则，用以生成代码。MDA 开发工具根据这些模型产生机器生成的代码，您可以对照行为模型来测试已生成代码的正确性。如果您改变行为模型或实现模型，则重新生成的代码始终会利用这些变化。
只要对较低层次实现细节的生成进行抽象和自动化，这些工具就能提供一种使设计能在各种目标平台之间移植，并使设计块能被反复使用的机制。然而，抽象只能实现移植机制。例如，如果目标处理器没有代码生成器，您就必须人工移植设计实现。除了这些益处之外，随着更高层次的工具在目标级变得更成熟、更便于使用、更有效，能够维持既有设计细节并实质性参与嵌入式设计的人数会相应增多（图 2）。拥有技巧和知识以便使用较低级别工具进行设计的人现在要比能使用较高级工具进行设计的人少。
图 2，当开发工具充分支持更高层次的抽象时，熟练的设计人员的数量相应增加。没有免费的午餐
高级开发工具带来很多好处，但那些首先上市、提供更强大功能、程序包更小、功耗更低、成本更低的嵌入式设计，常常把平台的资源推向新的极限。根据 eClips 公司提供的电子邮件警告订阅请求和网页搜索流量数据显示，每个月排最前的三个软件关键字肯定是 assembly（汇编）、C 和 C++。assembly 每个月的排名都这么前可能令人惊讶，除非您认为编译器和代码生成器无法适应所有新颖的专用数据和资源优化。
使您能够尽快完成设计的开发工具功能落后于创新技术的首次使用。编译器和代码生成器等开发工具包含了创造这些工具的编程人员的多年经验，而输入模型或源代码语言，即使具有专有的扩展功能，也无法包含每种创新或新颖数据的表示和资源使用的规范。除非某种功能具有得到证明的价值并以某种类似形式存在，否则工具开发商不太可能增加并改进这一功能。当编译器或代码生成器包含某种自动化功能或启动功能时，它才会使以前成为某人标新立异手段的那种功能变成商品。
设计师为使最新一代产品与众不同，寄希望于产品功能、大小、功耗和成本组合足够复杂，成为竞争对手的障碍。当高级开发工具包含各种简化复杂性的抽象和自动化工具时，您必须增加复杂性，使之远远超前于开发工具抽象的产品，才能维持您的竞争地位。
种种苦恼最终促使设计师在其设计得与众不同的部分采用更高层次的抽象。如果您采用的抽象很糟糕，那么，尽管您做出了了不起的努力，您得到的结果很可能还是很糟糕，因此重要的是您在使用不恰当或低效率的抽象时，应该尽快认识到这一点。使用了不恰当的抽象，会有种种先兆，其中包括：要求您想出临时解决办法来应付抽象中的缺陷；无法在不显著影响其它层次的情况下改进分层抽象的每一个层次；组件之间缺乏足够接口；必须重复多个组件之间的结构或操作。如果采用一种更高层次的抽象并没有带来工作效率的提高，您就不可以采用它。
使用抽象需要付出代价。根据定义，当您抽象某个事物时，您隐藏了一些细节来获得复杂性和开发工作效率上的优势，但您这么做，就失去了控制这些细节的能力。如果您需要控制这些细节，您就需要某种机制来打破抽象。编译器可通过支持内联汇编来提供这种机制。并非所有建模工具及其依靠的代码发生器都能提供类似机制。事实上，建模工具必须比简单的内联汇编提供更多这类机制，比如反映模型规范低层变化的“反向注解”，从而使设计师能在适当的抽象层次控制某个细节，同时不会使设计文档和设计验证 变得更复杂。
有时，即使是有用的抽象也会失效。例如，对一个大的 2 维数组做迭代，可能得到不同的性能表现，这取决于您如何组织内存，以及你是横向还是纵向通过数组。有效对付这几类抽象失效的唯一方法，就是了解工具正在抽象的对象以及它正实现这一抽象的方法。这一必要条件会给您的开发小组增加学习负担，同时也说明为什么各种抽象决不应该妨碍您检查和了解抽象的细节，尽管这些抽象可能隐藏了细节。 [1] [2] 下一页
本文关键字：暂无联系方式DSP/FPGA技术，单片机-工控设备 - DSP/FPGA技术
