PDF整合一切
嵌入式项目由许多部分组成。您确定最终得到的是您最初想要的吗？
组件集成是嵌入式系统设计中最具挑战性的任务之一。设计人员寻求保守的设计风格和可靠的接口和验证技术。
Rolf Ernst，布伦瑞克工业大学
随着嵌入式系统复杂性的增长，系统中越来越多的部分被重用或供应，通常来自外部来源。这些部分范围从单个硬件组件或软件进程到硬件-软件（HW-SW）子系统。它们必须与新开发的部分合作并共享资源，以满足所有设计约束。简而言之，这就是集成任务，理想情况下应该是一个即插即用的过程。然而，这在实践中并没有发生，不仅因为不兼容的接口和通信标准，还因为专业化。
例如，以一个信号处理程序为例，该程序通过仔细重写源代码，使用特殊功能或子字并行性，优化循环、数据传输和内存访问，从而适应了特定的数字信号处理器（DSP）架构。重用这样的DSP程序意味着要么重写代码，要么重用整个DSP架构或其一部分，将最初的软件集成问题转变为硬件-软件集成问题。在特定于应用的指令集处理器（ASIP）上运行的加密算法是另一个例子。DSP和ASIP架构非常适合实现性能和功耗目标，但它们使可移植性以及重用变得更加困难。
遗憾的是，能够自动适配代码的编译器尚不可用——如果设计人员可以避免汇编编码，他们会很高兴。您可以继续列出硬件加速器、专用内存架构、总线等。架构的多样性和适应性似乎是实现竞争系统苛刻设计目标不可避免的趋势。这就是推动ASIP复兴的原因。因此，我们将不得不接受异构嵌入式系统架构及其相应的集成问题。这适用于片上系统（SoC），以及更大的分布式嵌入式系统。
另一方面，存在软件集成的趋势。例如，汽车行业已经习惯于这样一种商业模式，即供应商提供电子控制单元以及实现特定汽车功能的软件，例如发动机控制、仪表板、车窗电机、防抱死制动系统（ABS）和自适应巡航控制（ACC）。集成意味着大约50个控制单元的集合连接到汽车总线，这些总线必须承载整个通信负载。由于诸如ACC之类的分布式汽车功能，这是一项日益困难的任务。为了减少控制单元的数量，应该将软件集成到更少的控制单元上，但这导致了在使用OSEK汽车操作系统（www.osek-vdx.org）的共享处理器上进行可认证软件进程集成的问题。这个特殊的问题是今年在慕尼黑举行的欧洲设计自动化与测试（DATE）会议（www.date-conference.com）的嵌入式软件论坛热点议题会议的一部分。汽车行业只是一个例子。想想电信、家庭平台或移动通信系统中的软件集成。
主要的集成工具是通信基础设施，以及可能的内存基础设施，以及基本软件，即实时操作系统（RTOS）和提供资源共享和接口支持的通信软件。在该列表中，我们可以添加应用程序编程接口（API）软件，这提高了可移植性。
集成挑战
嵌入式系统集成中的三个主要设计任务是
- 组件和子系统接口
- 系统验证
- 通过设计空间探索进行系统优化
前两个任务是通用设计问题，而后一个任务取决于应用程序的成本和优化压力。本文着眼于前两个问题，这两个问题也是系统优化和设计空间探索的先决条件。
接口在RTOS级别得到了很好的发展。存在软件-软件通信原语，例如用于消息传递的队列（管道）、共享变量和用于同步的信号量。这些通信原语将计算与通信分离。通信原语映射到平台相关的功能。这样，可以通过消除实现新的通信原语的需求来更轻松地移植软件。
相比之下，今天使用的硬件描述语言——VHDL和Verilog——仅支持通过电信号进行通信。将硬件组件移植到新设计需要硬件流程适配。软件-硬件通信使用驱动程序，这些驱动程序也必须适应硬件协议。在两侧使用类似的通信原语将使硬件适配和驱动程序开发变得更加容易。
因此，较新的硬件描述语言——例如SpecC，一种C语言扩展（www.SpecC.org），以及SystemC，一个C++类库（www.SystemC.org）——将硬件通信扩展到与RTOS通信相当的抽象原语。借助这些原语，硬件组件功能可以与其与其他系统组件的通信分离，类似于RTOS原语。因此，集成可以专注于实现通信原语，这些原语可以重用于其他组件的集成。新语言的开发正在进行中，但标准和首批工具已经可用，并得到了主要EDA供应商的支持。
接口是必要的，但还不够。各个部分能够正确地相互通信，并不意味着它们能够按要求协同工作。这是一个语义和目标架构性能的问题。两者都必须在系统验证中进行检查。功能验证侧重于系统语义，系统语义应该是独立于实现的。性能验证应验证硬件参数、处理器资源共享和通信性能，以检测性能缺陷，例如瞬时过载或内存溢出。
通常，功能和性能验证都使用原型制作或仿真（“虚拟”原型制作）。原型制作使用不同的目标架构，至少对于设计的某些部分是这样。对于这些部分，原型制作仅允许功能验证。此外，原型制作在开发时间方面成本很高，并且在可用部件或无法到达的环境条件方面存在局限性（想想模拟特定的发动机故障或车祸）。因此，本文主要关注仿真。
尽管嵌入式系统的功能验证可以使用非定时仿真，但性能验证与时序有关，因此需要定时仿真——即事件具有时间标签的仿真。由于定时仿真需要更多的计算时间，因此性能验证是一个瓶颈。因此，能够减少计算时间的组件的抽象时序模型受到了广泛关注。这些模型范围从所谓的“周期精确”模型（按时钟周期对系统行为进行建模）到抽象状态机网络，例如Cadence Design Systems虚拟组件协同设计（VCC）仿真器（www.cadence.com）中使用的模型。
这是否意味着我们所要做的就是开发更快的仿真模型和仿真器？不尽然。考虑图1中的示例。供应商提供了一个子系统1，它由一个传感器（Sens）组成，该传感器向微控制器（CPU）发送信号，该微控制器运行具有抢占式调度的进程系统（即，一个进程的执行可以被另一个进程的执行中断的调度）；其中一个进程是P1。子系统1使用总线A两次，一次读取传感器数据，一次将数据写入硬件组件，该硬件组件可以是周期性生成输出信号的外围设备。传感器信号缓存在CPU内存M1中。供应商提供了工作子系统和仿真模式，用于模拟最坏情况下的CPU负载情况，包括P1的最坏情况执行时间（WCET）。
图1： 资源共享导致子系统之间存在非功能性依赖关系。这种依赖关系可能导致异常，即一个子系统的最佳情况行为对另一个子系统产生最坏情况的影响。检测和管理这些影响是集成的挑战。
集成商决定与DSP子系统2共享总线A，DSP子系统2由知识产权（IP）组件（生成周期性输出数据，例如滤波器或数模转换器）和运行固定周期性调度的DSP组成。在DSP输入端插入一个缓冲区以重新同步数据流。这种集成任务是典型的。集成商现在理所当然地担心子系统1的流量注入到子系统2的失真，这可能会导致端到端系统响应时间延长以及DSP输入端的缓冲区下溢或溢出。集成商不了解内部子系统功能；只有最坏情况下的仿真模式可用。
现在，看看总线负载。图1表明，导致子系统2流量最严重失真的最高瞬时总线负载是由P1的最佳情况执行时间（BCET）引起的，这在子系统设计中不是一个角落案例。因此，很可能这个系统角落案例不会在仿真中被覆盖，并且系统可能会失败。
这个例子展示了一个基本的性能仿真问题。来自功能仿真的仿真模式是不够的，因为它们没有检查两个功能无关的子系统的非功能性依赖关系。子系统角落案例是不够的，因为它们与系统角落案例不匹配。系统集成商无法生成新的角落案例，因为他/她不知道相应的最坏情况子系统行为可能是什么。为了使情况更加复杂，示例中子系统1的通信不仅受到DSP子系统的干扰，还受到其自身的传感器到CPU流量的干扰。不幸的是，典型的总线标准引入了这种非功能性依赖关系。
与标准软件不同，这种不确定的行为在嵌入式系统设计中是不可容忍的，尤其是在涉及生命攸关的功能时。例如，安全气囊晚10毫秒弹出，大约会消耗你头部撞击方向盘所需时间的一半。然而，即使不涉及生命，这种系统故障也可能代价高昂。它们可能使产品无法销售，因为人们通常不愿意接受质量与PC软件相当的嵌入式系统。
一种可能的答案是使用避免非功能性依赖关系的集成技术和策略。时分多址（TDMA）协议为每个逻辑通信通道（即Sens-CPU、CPU-HW、IP-DSP）分配一个固定的时隙，即使通信不活动，该时隙也保持未使用状态。这样，每个逻辑通信通道都获得整体带宽的固定份额，而与其他子系统无关。离散时隙会引入抖动，但这种抖动是有界的，并且可能已经在组件设计中被考虑。这种保守的技术在芯片级别（例如，Sonics Micronetworks使用该技术）以及更大规模的系统（例如用于安全关键型汽车和航空航天应用的时间触发协议（TTP）（www.ttagroup.org））中都被采用。
TDMA技术可以应用于处理器调度，并扩展到软件开发，在软件开发中，描述TDMA性能的优雅而简单的数学方法可以用于系统范围的性能分析和控制，例如加州大学伯克利分校的Giotto工具。（有关Giotto的更多信息，请参阅Th. Henzinger、Ch. Kirsch、R. Majumdar和S. Matic的“嵌入式程序的时间安全性检查”，载于第二届嵌入式软件国际研讨会（EMSOFT）论文集，计算机科学讲义2491，Springer-Verlag，2002年，第76-92页，或http://www-cad.eecs.berkeley.edu/~fresco/giotto/。）
然而，使用TDMA的保守设计会带来性能（和功耗）代价。如果需要短响应时间，或者系统对非周期性和突发事件做出反应，或者负载根据系统场景而变化，那么系统必须进行显著的过度设计。问题在于，即使保守策略中的一个微小变化也会削弱保守属性。例如，在轮询策略中，该策略将未使用的时隙分配给下一个进程或排队的通信，您会看到相同的非功能性依赖关系，即使轮询至少保证了与TDMA相当的最低性能。
性能分析
在求助于保守设计之前，您可能需要仔细研究更正式的性能分析。考虑到复杂的确定性通信模式，统计方法似乎不够充分。它们无法捕捉到非常具体的过载情况，并且可能存在风险或导致过于保守的设计。
高级嵌入式系统工程师可能熟悉为实时计算开发的形式化方法，至少熟悉速率单调调度和分析（RMS和RMA）。RMA展示了这种形式化方法的原理。RMA从单个进程激活（如仿真中使用）抽象到激活模式。基于这些激活模式和进程WCET，它可以推导出可调度性和最坏情况响应时间。
实时计算社区中存在大量关于使用激活模式和WCET作为输入进行可调度性和响应时间测试的工作。WCET通常通过仿真或测量获得。我们最近在形式化程序分析方面看到了重大进展，这导致了首批可用于建模程序执行的商业工具（www.absint.com）。仍然存在一些未解决的问题，例如缓存架构中的耦合效应和BCET分析，但我们可能期望在不久的将来出现形式化分析解决方案，这些解决方案可以取代或补充测量或仿真，前提是对EDA技术和处理器模型进行足够的投资。
如果存在这样的形式化方法，为什么还需要保守设计？主要的限制是这些方法不容易扩展到更大的异构嵌入式系统，例如图1所示的系统。它们涵盖一个处理器或总线，或者最多涵盖具有同构调度的子系统。有一些建议结合了几种不同的调度策略，例如处理器上的RMS和总线上的TDMA（例如，参见P. Pop、P. Eles和Z. Peng的“混合时间/事件触发分布式嵌入式系统的整体调度和分析”，载于硬件/软件协同设计国际研讨会（CODES02）论文集，第187-192页，科罗拉多州埃斯特斯帕克，2002年），但我不知道有任何通用的连贯“整体”方法可以涵盖像图1那样的系统。
再次考虑图1。我们可以将系统划分为围绕总线A分组的本地调度的通信组件，总线A具有自己的资源仲裁协议。这些组件发送和接收消息，这些消息可以组合成消息流。
图2突出了这些消息流。通过一些相对简单的数学运算，您可以将消息流转换为激活模式，以便将发送组件的分析结果传播到下一个组件的分析算法。这也适用于总线。这种转换称为事件模型接口（EMIF）。继续传播和分析，直到到达输出。如果所有输入流都可用，则可以分析组件。
图2： 目前在实践中研究了几种异构嵌入式系统分析方法。一种方法遵循集成过程，并使用事件模型接口将本地子系统分析结果集成到全局端到端分析中。
这样，全局性能分析就变成了事件流分析问题。流中的循环，例如CPU和总线A之间的循环（双向流），通过迭代解决。最终，您还可以计算DSP输入端所需的缓冲区大小。（有关更多详细信息，请参阅K. Richter、M. Jersak、R. Ernst的“MpSoC性能验证的形式化方法”，IEEE Computer，2002年4月，或www.spi-project.org）。其他研究人员研究了基于流的全局分析，模型略有不同（L. Thiele、S. Chakraborty和M. Naedele的“硬实时系统调度的实时演算”，载于电路与系统国际研讨会（ISCAS 2000）论文集，第101-104页，瑞士日内瓦，第4卷，2000年3月）。基于流的分析已应用于电信、汽车和多媒体的早期实际示例，即使专家知识仍然是必要的，并且尚无易于使用的工具。
下一步是什么？
鉴于嵌入式系统复杂性的发展，基于仿真的性能验证似乎正在慢慢失去动力。这让今天从事安全关键型应用的人们感到担忧，并且随着系统复杂性的增长，这将成为任何集成商的关键问题。仅靠保守技术并不能从根本上解决功耗、成本和性能问题。形式化方法作为基于仿真的性能验证的替代方案，具有许多优点，但必须扩展到适用于异构嵌入式系统的全局分析方法。真正的中长期替代方案似乎是保守设计与分析性能验证。保守技术可以用于可靠的性能验证方法不适用或因任何原因效率低下（例如，抽象形式模型导致范围过宽）的情况。
当包含连续时间模型以将嵌入式系统与其物理环境一起仿真时，定时仿真仍然可以发挥重要作用，并且似乎是不可避免的。然而，鉴于分析方法的进步，我们应该重新考虑是否将大部分精力投入到改进定时事件驱动仿真上，还是将更多精力投入到复杂架构的性能分析的形式化方法上。
ROLF ERNST目前的研究兴趣包括嵌入式架构、高级综合、硬件/软件协同设计和嵌入式系统工程。
最初发表于Queue杂志第1卷第2期——
在数字图书馆中评论本文
更多相关文章
George W. Fitzmaurice, Azam Khan, William Buxton, Gordon Kurtenbach, Ravin Balakrishnan - 通过设备多样化社会实现感知数据访问
自ATM和杂货店UPC收银台等“信息设备”推出以来，已经过去了十年以上。对于办公环境，Mark Weiser于1991年开始阐述普适计算（UbiComp）的概念，并指出了该趋势的一些显著特征。嵌入式计算也变得越来越普遍。例如，微处理器正被嵌入到看似传统的钢笔中，这些钢笔可以记住它们写了什么。汽车中的防抱死制动系统由模糊逻辑控制。
Homayoun Shahri - 模糊硬件和软件之间的界限
在芯片上数百万门电路技术可用性的推动下，一种新的设计范例正在兴起。这种新范例允许在一个芯片上集成和实现整个系统。
Ivan Goddard - 嵌入式系统中的劳动分工
越来越多的嵌入式应用需要比单个处理器（即使是使用高性能架构（如超长指令字（VLIW）或超标量）的重度流水线处理器）所能提供的更多的处理能力。简单地提高时钟频率在嵌入式领域通常是不可行的，因为更高的时钟频率需要成比例的更多功率，而功率在嵌入式系统中通常是稀缺的商品。多处理（应用程序在两个或多个处理器上同时运行）是在固定功率预算内获得更多处理器周期的自然途径。
Telle Whitney, George Neville-Neil - SoC：软件、硬件、噩梦、幸福
片上系统（SoC）设计方法允许设计人员从较小的工作模块或系统创建复杂的硅系统。通过提供一种在包含许多现有设计组件的更大环境中轻松支持专有功能的方法，SoC设计将硅设计工艺向更广泛的受众开放。
© 保留所有权利。