嵌入式系统的设计原则以及关于寄存器及其域的种种考虑

    嵌入式系统设计中，软件和硬件的接口问题经常困扰软件开发工程师。正确理解接口在处理器与高级语言开发环境方面的约束条件，可以加速整个系统设计，并为改进系统的质量、性能和可靠性以及缩短开发周期和减少成本提供保证，本文从两个设计实例的比较入手，介绍了嵌入式系统的设计原则以及关于寄存器及其域的种种考虑。

    嵌入式系统设计通常分为两个部分：硬件设计和软件开发。这两部分任务通常由不同的设计小组负责，相互间很少有覆盖的地方。由于软件小组很少涉足前面的硬件设计，采用这种方式进行开发经常会遇到问题，特别是硬件与软件开发环境之间的接口性能较差时，会导致系统开发时间延长、开发成本提高，最终推迟产品的上市。

    最理想的解决方案是软件小组参与硬件设计，但是在时间安排、资金和人员方面往往又是不实际的。一种变通的方法是创建一套硬件接口规范来加速软件开发流程。从软件开发者的角度来理解最优化的硬件接口设计能有效地防止软件开发中出现不必要的硬件问题，这种方法对硬件设计流程造成的影响也很小。

    嵌入式系统结构的一般模型

    从系统角度看，嵌入式系统是多种系统要素之间的很多接口的集合，这里罗列的主要资源是系统处理器。处理器接口可以分成两大类，分别标识为本地总线和硬件总线。值得注意的是，本文中的总线是根据处理器利用资源时的访问类型单独定义的，与具体的硬件连接没有对应关系。

    本地总线是资源与处理器之间的接口总线，它允许无限制的连续访问。无限制访问意味着处理器能够利用其内部数据类型（如字节、字和双字）访问一个资源的所有要素；连续访问是指所有资源要素占用的资源地址空间是连续的，中间没有任何间隔。RAM和EPROM就是与本地总线接口的常见范例。

    硬件总线与资源的连接通常有某些限制，如大小、位置、寻址、地址空间或重定位等。只接受字写入的I/O端口，或者使用前必须先作映射的PCI总线上的外围芯片是硬件总线接口的一些实例。采用硬件总线连接对软件设计工程师访问资源有一定的限制，可能在软件设计、开发和集成过程中产生复杂代码和代码错误。

    正确的硬件总线接口设计能够加快软件设计进程，通常也能加快硬件验证速度。本文重点介绍与可编程逻辑资源相连接的硬件总线的设计与实现。

    系统定义的实例

    这里考虑两种不同的硬件实现方式。该系统是处理器控制的三轴伺服系统，本部分的系统设计仅限于位置反馈控制的设计，因此有助于我们专注于硬件接口的实现。

    该系统的两种实现方式都实现了处理器与用户ASIC（或FPGA）的接口，从而为三轴伺服提供驱动与反馈信息。每个系统中的ASIC必须利用32位数据总线使处理器与三套驱动/反馈资源连接。每种资源包含有一个带符号的10位驱动寄存器、一个带符号的8位位置寄存器和一个3位的错误状态寄存器，任何一个位置位都表示一种错误状态，由它产生轴驱动（axis drive）的关闭信息。

    图1和图2表示了一种寄存器接口的可能实现方式，分别标识为系统实现A和系统实现B。为了描述方便，后文以系统A和系统B分别指代这两种实现。

    当采用VHDL（或其它高级硬件设计方法）实现时，这两种硬件接口的设计复杂性几乎是相等的。系统A显得稍微高效些，因为其寄存器地址译码相对简单些，所采用的硬件数量也比系统B少。为了减少与处理器接口的可编程器件中逻辑单元的数量，大多数硬件设计工程师会选择系统A的实现方式。

    表1所示的伪随机码为轴驱动程序，可用于A、B两个系统。伪随机码设计用于基于先进处理器的系统实现，并运行于实时操作系统，以通用轴控制程序的三份独立挎贝（或任务实例）实现轴的控制。当使用系统A中定义的接口时只需伪随机码中那些带星号的代码行。

    很明显，即使在代码原型阶段系统B所需的代码也比系统A少很多。系统B中的硬件设计要稍微复杂一些，但能减轻软件开发的负担。后文将回顾这两个实例系统和伪随机码。

    在阅读本文时，硬件设计工程师可能会产生这个问题：“为什么第一个设计的效率要比第二个低？”。两种实现方式控制轴向操作的参数是相同的，而第一种方法所需的可编程硬件器件数量显然要比第二种少。为了正确回答这个问题，设计工程师必须从系统的角度来看待这个设计，而不是硬件设计工程师惯用的“逻辑门”角度。下一部分将阐述硬件设计工程师开发系统硬件接口时常会遇到的一些概念，将进一步讨论这些技术，并检查将这些概念应用于实例系统设计后的结果。

    为了满足项目要求，对整个系统结构进行优化时需要在硬件与软件实现之间作出折衷，现实中是没有项目能满足这里提到的所有理想软件接口要求的。对理想状态的认识有助于硬件设计工程师识别并消除影响软件设计的一些障碍。

    设计原则

    1. 采用标准总线访问

    有效的嵌入式硬件接口设计的一般原则是：对软件设计工程师来说，硬件设计应确保对硬件资源的访问尽可能透明。处理器使用所有标准的读写指令可以实现透明访问，而不用考虑前面的访问内容或时序。

    像页寄存器设置、地址线上的写数据编码等都可能严重影响代码的开发，并常常需要开发标准访问与所需特殊访问之间完成相互转换的驱动程序。

    通常不可避免要采用一些特殊总线，但需要慎重考虑特殊访问空间的使用选择，因为这种情况会给系统软件设计带来一定的困难。系统A采用了只写寄存器，因此要求系统软件提供“影子”内存（Shadow memory）来保存写入到资源的数据。而系统B由于允许所有的寄存器都可读写，因此没有这种限制。

    2. 开发基于处理器的资源接口

    硬件设计工程师习惯于从下至上分析资源接口问题以及与系统总线的连接，而通过分析处理器在系统中对资源的访问过程则更好。

    “处理器与资源”间的接口常常是最重要的接口，在硬件设计流程中它的效率应是最优先考虑的对象。统一规划整个系统的资源访问对于正确理解由硬件设计选择所引起的访问限制很重要。

    现有最先进的系统包含有存储控制器和可再映射总线，它们会改变处理器与资源接口之间的访问类型。一般地说，一个不合格的硬件接口设计在软件小组试图与实际资源连接前是不可能反映出来的，这一点对于设计硬件接口很重要。

    3. 系统内存映射的创建与维护

    对于一个好的系统设计来说，所有资源的存储器映射都非常重要。如前所述，存储器映射的设计应考虑到具体处理器要求，而不是简单地说明一个资源所解码的地址线类型。如果采用的是寄存器可配置资源，如PCI总线，硬件设计工程师应在存储器映射中配置所有与该资源有关的配置寄存器，并提供用以创建硬件验证所需的静态映射的配置寄存器初始化值。

    硬件设计工程师还必须认真考虑动态重配置的优越性。在可重配置总线上没有新增（或减少）资源的系统能演变成一个静态映射，方法是强迫配置寄存器在系统复位后回复到同一值。这个“静态”系统图为硬件集成和软件开发提供了一个稳定的统一结构，同时还避免了在系统代码中使用易产生错误的指针操作。

    最后，随着系统的不断成熟，存储器映射也必须不断完善，并随着软硬件开发的进展不断改进。

    4. 统一的访问模式

    当前的嵌入式系统由于复杂度的提高，通常由多人共同合作进行设计。每个硬件部件的设计必须与整体一致，这样才能开发出统一的资源访问模式。如果不同功能模块的访问不一致的话，在软件开发期间就会产生潜在的访问限制错误，从而可能需要为每个子系统设计专门的软件驱动程序。对不同逻辑块的不一致访问也会使硬件集成和验证变得困难重重。

    例如设计工程师在调试器上编辑4个十六进制数字并不能保证处理器会使用一个16位的读/写周期，因此，对软件开发和硬件集成中使用调试工具设置多种类型的限制访问也具有一定的困难。这样看来，评估仿真器处理多个限制性访问地址空间的能力就非常有用，特别是在用“限制外”访问方式触发总线故障的处理器结构中。

    寄存器设计

    既然硬件设计工程师的重点已经从逻辑门和总线转移到了系统设计，我们再来审视一下任何处理器系统中最常用到的寄存器设计。寄存器接口允许高速访问资源，其访问的效率对系统的性能有很大的影响。

    寄存器的结构与访问

    设计工程师应该精心选择硬件寄存器大小，使处理器能最有效地进行硬件访问。一般来说，总是采用系统内部整数访问方式。寄存器应该被译码为连续的组（没有地址空档），这样可以加速指针或阵列索引对寄存器的访问。任何可写的寄存器也应该是以同样的格式可读，这样可以避免使用本地存储器来缓存这些寄存器值。

    控制一个子系统的寄存器应该以相同的结构形式在一起分组，使软件能使用通用的驱动程序对它们进行访问。当设计中需要多个同一类型的子系统时这点尤其重要。

    为了避免被编码成独立进程的软件任务之间发生冲突，独立的子系统不能在系统处理器访问期间共享可写寄存器。这些“独立”的软件进程在访问共享寄存器时会产生竞争，除非在系统代码中使用不可中断的读/写驱动程序。根据操作系统的不同，多个进程共享寄存器甚至可能会产生功能调用的额外开销。访问共享寄存器的同时还有执行其它进程的做法是错误的，也是软件设计的通病，会导致间歇性的系统故障，影响集成和测试系统软件的进度。

    系统A违反了很多上文提到的原则，如采用只写寄存器，共享控制和状态寄存器，以及没有为每个轴提供公共的寄存器映射。系统A必须用专门的驱动程序来缓冲写输出数据，移位并屏蔽轴驱动与位置信息，并防止轴驱动寄存器内容被为每个轴任务编写的代码所影响。系统B由于分离并重组了与每个轴有关的寄存器，因此能克服这些问题。

    寄存器复位内容

    硬件设计工程师应仔细考虑系统的复位状态。硬件设计通常采用启动程序来取得系统启动后的控制权，并将系统初始化到一个安全的状态。系统复位后应将硬件置于一个确定的安全状态，并且硬件应持续保持安全状态直到系统软件初始化完成为止。代码也应在软件控制下复位硬件以帮助调试、自检和原始代码的开发。

    系统A不控制驱动寄存器的复位内容，需要代码的介入来将所有三个轴的驱动寄存器设置为零。这种结构会产生严重的系统设计问题，因为处理器通常是保持在复位状态，直到FPGA和ASIC加电并得到配置后处理器才正常工作。如果开发人员使用仿真器，那么在集成过程中系统A还会出现另外的问题：被仿真器控制的处理器在系统加电后可能需要很长的初始化时间才能正常工作。在软件取得控制权之前系统A和B的轴都处于随机驱动状态。

    系统B在加电后会将所有轴驱动寄存器设为零，它对轴驱动设置的控制并不依赖于启动时间。因为系统B没有隐藏的状态机，因此在本设计中没有必要考虑增加额外的软件复位寄存器。

    寄存器域设计

    大多数资源接口所包含的数据项并不正好适合一个寄存器。这种情况下，硬件设计工程师必须将一个寄存器分成若干域。合理的域结构对系统性能来说非常重要，与寄存器接口设计有相似的影响。有效的域接口设计规则类似于寄存器设计规则，但设计工程师还需要特别注意域的顺序与放置，还要对寄存器中未用到一些字节作一定的处理。

    1. 寄存器的域

    域被定义为寄存器中若干位的子集，主要用于报告或控制资源的一个功能要素。在硬件设计中最常用的域类型有：1. 布尔域：真或假，通常是一位；2. 多位状态域和控制域：多位用于报告或控制内部相关功能；3. 列举状态域和控制域：多个位的集合，其中每个位代表了一种不同的硬件状态；4. 数字域：多个位组合在一起用来代表一定的数量值。

    从软件使用者角度看，最有效的域结构是每个寄存器只用一个域。这种理想的软件结构可能导致硬件实现效率低，因此一个好的系统设计需要在软硬件设计之间作出折衷，在每个寄存器中应放置多个域。

    下文将着重讨论一个寄存器中假设存在多个域的情况，不过，当对资源的某个特殊参数进行的有效访问将严重影响系统软件性能时，硬件设计工程师仍应该考虑使用单个域的寄存器。

    2. 域结构

    前文提到的用于寄存器的结构概念同样也适合于寄存器内部的域。一个寄存器应该只包含属于设计中同一功能要素的域，并且该寄存器中的所有可写域都应该是可读的。

    那些包含有属于多个功能要素的域的寄存器同样需要特殊驱动程序支持，这样才能使多个进程安全地访问每个域。而配置为“只写”功能的域需要分配影子内存来保存寄存器域中的前一状态值。硬件设计工程师原来设想的简单的“屏蔽/写”操作现在变成了繁杂的多步功能调用，首先必须禁止中断和任务切换，然后读本地存储器，屏蔽输入输出值，再进行硬件寄存器写，最后开放中断和多任务切换。如果寄存器中所有域能得到有效安排，通过一个软件任务就能访问全部域的话，上述情况就能得到有效避免。

    由于系统A将属于不相关功能的多个域组合放在一个寄存器中，因此它需要使用特殊的驱动程序。而系统B则遵循“单个寄存器内的域按任务进行组织”的原则，将每个域放置在属于自己的专用寄存器中，因此能高效地访问资源中的每个轴参数。

    3. 十六进制数字对齐

    硬件设计工程师还应该明白针对处理器和软件开发环境进行对齐约束。如果将域放置在错误的地址上而超出字的边界，将迫使软件设计工程师只能按块访问每个域，进而增加访问复杂性，降低访问的速度。在调试过程中，用零值填充域是非常有用的，可以使每个域的最低位对齐十六进制数字（4位）的边界：当在逻辑分析仪、调试仪或仿真器上显示寄存器情况时，十六进制数字对齐会有助于域值的可视化提取。系统A的寄存器域是没有对齐的，因此从原始的十六进制数据中提取域值很困难。由于控制域没有对齐，在查错时屏蔽测试输入也十分困难。而系统B的所有域都是按十六进制偶数数字对齐，因此通过寄存器读可以很容易地确定每个域的状态，并且能方便地将某个域设为指定值。

    4. 域位置的分配与顺序

    寄存器内域的设置也会严重影响软件实现的效率。布尔域和多位域通常与位置无关，但当列举域和数字域被放置在寄存器的最低位（LSB）时对它们的访问效率通常是最高的（LSB的实际位数取决于处理器类型，位0不一定是LSB）。将域配置在寄存器的LSB中可以有效地消除对域内容屏蔽后的移位操作，也使测试设备或进行可视化检查的调试仪访问寄存器时能更容易地识别域值。

    系统A中用于轴2和轴3的域值在使用前必须要求软件进行屏蔽和移位。而系统B则将所有数字域配置在寄存器的LSB中，从而能完成更有效的访问。系统B的集成性也更好，资源寄存器的十六进制数据能真正分离成正确的域值。

    5. 未用数据位

    寄存器中的未用位同样也会影响软件实现的效率。所有未用位应回归为零，并且写入操作时无需对它们作特殊的处理，这样可以避免不必要的屏蔽与清除操作。这个规则的唯一一个例外是包含数字域为2的补码的寄存器，并且在寄存器中剩余的最高位（MSB）没有用的情况。在这种情况下，使硬件实现符号将域的MSB扩展到未用位就非常有用。以这种方式扩展的数字域能够被处理器直接访问，因为带符号的数值无需软件符号的扩展。当对特殊的数字域变量的访问速度严重影响整体系统性能时，将该类型的域与“单个寄存器单个域”结合起来考虑将非常有用。由于无需屏蔽或符号扩展，这些域能以内部数据访问的方式直接访问。

    当系统A中需要从寄存器提取域值时，要求软件对每个数字域值进行符号扩展，而系统B允许通过对寄存器的内部整数访问直接访问域值。

    6. 域类型选择

    域类型的正确选择也能极大地提高软件实现效率。在打开或关闭独立资源功能时布尔域是最有效的。要注意的是，只有当寄存器是可读写时单位域才容易编码。如果硬件寄存器对域的访问有限制，就需要专门的缓冲器（有可能再加上一个专门的驱动程序）来保存当前的内容。限制性访问同时也会限制一些编程构造的使用，如位域（bit field），从而影响系统代码的可读性，且无助于减少编程错误。

    当表达资源状态的数据需要占用一定范围的值时数字域就很有用。当一个域能保持正值和负值使用时，带符号的表达式通常需要更多的软件工作。另外，还要避免在数字域中对其它数据进行编码（如利用域符号表示一个不相关的资源状态）。

    从硬件实现来看，多位域更有效，但在写入系统代码时会增加代码的复杂度。列举类型通常能更好地反映资源中相关功能的实际可用性，可以有效防止冲突功能的采用（如将存储器块切换到本地总线上）。列举类型还应提供这样的可选项：无条件允许切换之间存在“停放带”，无条件允许系统软件中存在“先中断再实现”的代码切换。

    系统A中对轴驱动域的“只写”访问使软件对目标域的访问效率很低，必须用RAM保存写过程中不作修改的过去的轴内容。系统B中由于每个寄存器都只有一个域并允许读写操作，因此不存在这样的问题。

    实例系统的性能评估

    为了评估最终系统软件的性能，将列表1中的伪随机码正确转换成C代码并同时用于A、B系统中，然后利用内部存储器中的结构模拟每个系统的硬件接口。代码中应避免使用位域，因为标准C实现不能在限制性访问的地址空间上正确工作。系统代码模拟运行于PowerPC，编译工具采用的是Green Hills MultiC，目标操作系统是VxWorks，编译器设置在中级优化度（目的是帮助调试，并允许设计工程师把每条汇编指令与每一行C代码联系起来）。

    表1列出了伪随机码的每一行，并给出了每个系统实现所用到的汇编指令与功能调用数量。另外还对两个实现所用的代码执行速度进行测试。子程序升级系统B轴的速度要比系统A快5.3倍，这主要归功于任务阻塞与去阻塞功能调用的去除。要注意的是实际系统中的加速效果可能并不明显，因为实际的硬件访问时间对总的执行时间影响最大。

    在实验中要提升两个实现所用编译器的优化度，结果发现优化度的提高对系统B无效，对系统A来说只是减少了很少的代码，并且速度却稍有降低。这样的结果表明，系统B的硬件接口在轴域的资源访问上非常接近内部访问的效能。

    另外，为了对两种实现所用到的硬件设备进行评估，要用VHDL对硬件接口进行编码，然后用赛灵思的Webpack软件进行综合，并把设计映射到赛灵思的Virtex FPGA中。采用Virtex系列芯片的结果是系统A要消耗56个功能片（slice），系统B要消耗85个功能片。V300E-PQ240器件总共具有3072个片，因此系统A占用可用资源的1.8%，系统B则占2.8%。9500系列器件的内部资源更有限些，比如XC95288XL-PQ208，系统A将占用该器件可用资源的18%，系统B则占30%。

    仔细考察这两个设计发现，系统B所用的额外资源中最主要的驱动源是组合型轴寻址方案。为了验证这一结果，重新组织寄存器映射，以便将每个轴作为一个独立资源使用，单个轴映射按地址位边界对齐。这一变通的实现方式保留了系统B的所有软件接口优点，同时减少了整体硬件器件的使用，Virtex系列器件的片利用率能降低2.3%，9500系列的利用率能降低22%。

    硬件设计会极大地影响系统软件实现的复杂性和质量。一个好的硬件设计要求设计人员能根据硬件实现与最终软件设计环境的复杂性做出决定，正确理解硬件接口设计对软件开发流程的影响能极大地改进系统质量、性能和可靠性，同时减少系统开发的周期与成本。