我们最近看了一下莱迪思的传感器集线器方法．我们已经看到了许多实现传感器中心的其他方法在过去，但所有这些都是基于软件的;这只是一个软件在哪里执行的问题。莱迪思的方法是硬件，这引发了各种各样的新问题。

对我来说，最大的危险信号是，在设计阶段将任务从软件转移到硬件并不是一件简单的事情。(在很大程度上，使用自动生成硬件的工具，试图把它留在软件领域，是一个不切实际的目标，似乎在很大程度上已经被亲切地放回了架子。)在我寻求解决这部分问题的过程中，我发现传感器中心的世界不仅仅是全软件和全硬件。这使得设计问题更加复杂。

所以在接下来的几页里，我想首先探索一些不同的传感器集线器设计;之后，我们将讨论设计流程的含义。归根结底，从架构的角度来看，这是一个分区问题。我认为，根据定义，传感器集线器本身就是将软件从AP中分区出来的结果，但现在它不仅仅是软件分区:它是软件/硬件分区。

因为我已经介绍了它们，所以在我们回到设计流问题之前，我不打算深入研究全软件和全硬件方法。在这一点上，我们感兴趣的是目前市场上可用的两个可供选择的体系结构:一个来自句传感器还有一个来自QuickLogic．我们之前已经在较高的层次上讨论过它们，所以在这里我们将进一步深入了解它们是如何划分的。

我该怎么做呢?

值得一提的是，所有的传感器处理在某种程度上都涉及到硬件。正如Movea的Bob Whyte所指出的，大多数传感器的专用集成电路(ASIC)将处理低级的a -to- d转换、校准、抽取和串行化，然后交付到总线上。我们将要描述的函数的级别比这些更高，而且关键的是，它们影响多个传感器的融合，而不仅仅是单个传感器数据的处理。

在这个更高的层次上，决定什么进入硬件，什么进入软件是一个经典的决定。硬件通常提供更高的性能和更低的功耗(普通的可编程逻辑在这里是例外)。软件提供了灵活性，有时还降低了成本，因为您使用一块硬件(处理器)来处理所有事情，而不是为每个自定义功能创建自定义逻辑。这些自定义函数会占用大量的硅空间，特别是在需要管道和复制来提高性能的情况下。

只有当不同的函数在不同的时间执行时，使用处理器处理所有事情才有效。如果它们必须是完全并发的，那么就需要使用多个处理器或硬件。我们在这里描述的函数不属于这一类，所以并发本身并不是一个关键问题

我们将讨论的硬件选项要么是完全定制的硬件，要么是专门针对该角色进行优化的可编程设备。因此，我们可以假设硬件——无论是否可编程——将会更快、更低功耗;软件将是灵活的。

成本?这个我就不讲了。系统开发人员的解决方案成本可能不是解决方案提供者的成本。这里有一个“价格对价值，而不是成本”的问题，两者的差异就是利润。因此，可能会有一些价格高但成本低的解决方案。我还没有看到任何拆除，所以我将在讨论中省略成本。我知道，像个真正的工程师。

这留给我们的是灵活性和力量/性能。简单。什么时候你需要灵活性?在我们的环境中，当您预期算法的变化时，您需要它。这些更改甚至可能需要应用于部署在现场的系统，但是，至少，您需要减少必须执行的不同硬件设计的数量。

即使你的客户从不更新他们的传感器集线器，你的算法也会在未来几年内得到改进，所以你可能每3或6个月就会改变你所交付的内容。你不希望频繁地更换硬件;面具太危险太贵了。fpga带来了一些灵活性，尽管我们将很快讨论的设计流程意味着这不能被认为是理所当然的。出于我们的目的，我认为fpga是半柔性的。

因此，划分问题就变成了:哪些稳定的部分可以从硬件的性能和性能中受益，哪些部分将来可能会发生变化?我过去提到过传感器融合算法似乎正在发生变化，从主要由计算四元数之类的数学组成，到本质上更具启发式。数学可以很确定;启发式，就其本质而言，并不是那么精确。

因此，一个明显的划分是在硬件中进行数学运算，而将启发式和其他模糊的东西保留在软件中。这就是PNI传感器在他们的SENtral传感器集线器芯片中所做的。该设备包含硬件和软件，其内容不是用户可编程的(除了存储在寄存器中的几个关键参数)。他们强化的每个数学函数都在单个循环中执行。他们使用ARC处理器处理软件中保存的部分。

这种带有可定制指令集的处理器的使用并不独特或令人惊讶。当权力成为敌人时，周期就是邪恶的。所以你要在每个循环中做尽可能多的事情。然后你可以把时钟的速度调低;中央设备运行10mhz时钟(与典型的微控制器150+ MHz相比)。它们通过使用ROM而不是RAM进一步降低了功耗(当然，这是以牺牲一些灵活性为代价的)。自定义CISC的另一个好处是更少的指令获取;这进一步降低了功率。

QuickLogic的解决方案更加细致入微。他们有1000个逻辑单元来处理所有事情;这并不多。他们说，32×32倍增器可以吞掉这么多的细胞，通过传感器融合，你不仅仅是在做乘法;你在做矩阵乘法。那么如何做到这一点呢?

他们用硬门构建了一个乘数，时间多路复用，并为各种计算共享它。这由一个微编码的状态机管理。

然后，除此之外，还安装了两个自定义指令CISC处理器。它们类似于ARC或Tensilica处理器，但它们不是特别的ARC或Tensilica。一个处理器管理传感器，每20毫秒轮询一次并存储数据。另一个处理器获取存储的数据并处理融合算法。

传感器轮询是串行进行的;轮询率可能取决于所涉及的传感器类型。有些传感器，如温度和湿度传感器，对变化缓慢的现象进行采样，因此可以减少轮询次数。另一方面，面向运动的传感器则需要更频繁的登录。

他们使用的时钟频率很低:30千赫。是的，有个“k”。如果使用的传感器数量超过了在该频率下可以连续轮询的数量，则可能必须稍微提高。

我想这是一个很好的地方，在这里记下我在其他地方说过的东西，结果证明是不正确的。我已经说过，多核还没有用于软件实现。显然这是不正确的，因为QuickLogic解决方案有一个微编码的状态机和两个并行运行的CISC处理器。这并不是为了实现所需的并发性，而是一种分解问题以管理复杂性的方法。

当然，在CISC处理器中只能完成这么多的融合。因此，当QuickLogic认为他们已经离开了简单的融合领域，进入了更复杂的上下文领域时，他们就会遵从AP。为了避免美联社运行得太辛苦，他们依赖于上下文的概念——如果这意味着“目前正在发生的事情”往往会慢慢改变，所以他们每15分钟左右就会向美联社提供新的数据。这让美联社有时间睡觉，如果没有其他事情发生的话。

现在我们有了四种传感器集线器变体，总结在图1中:

• 在微控制器中实现的传统软件，该微控制器可以是外部的，也可以与传感器配置在一起;
• QuickLogic;部分固定硬件，部分可编程硬件，部分微码，部分软件;
• PNI传感器:部分固定硬件，部分“固定”软件(带寄存器设置);
• Lattice:所有可编程硬件。

图1。传感器中心硬件/软件分区选项。

我该怎么设计呢?

现在，给定这些接近传感器中心的非常不同的方式，这些设备的用户应该如何实现算法?这里有几个不同的角度。

让我们从传统的微控制器集线器开始。融合算法往往从高层次开始，由算法骑师使用Matlab等工具创建。Matlab创建了“科学”代码，然后必须将其转换为现实世界中的“工程”代码，以便在特定系统中的特定处理器上运行。

如果系统实现是面向软件的，那么这个过程是最简单的。这并不意味着没有工作要做;这些微控制器很小，算法必须使用尽可能少的功率运行。所以有很多优化和代码重写可能是必要的。臃肿软件不适用。但是，这是一个软件问题，将通用代码转换为特定代码。没有什么奇怪。

同样相对简单的是PNI传感器解决方案，原因完全不同:它的功能是固定的，保存几个寄存器值的可能设置。他们说他们花了很多时间来优化他们的硬件和软件，所以如果他们的客户能够改变功能，这项工作就不会是微不足道的。

复杂度等级中的下一个是格点解。这不是一个难度的问题，而是一个努力和设计文化的问题。首先，输入是软件，输出是硬件。是的，有像Calypto的Catapult C这样的工具可以帮助将不定时的C代码转换为RTL硬件语言，但这是工作，而且不是微不足道或便宜的。这个项目很可能是一个完全的硬件设计，没有任何工具的帮助。这意味着硬件工程师;特别是FPGA设计人员。即使你使用工具，它仍然是一个硬件项目。

转换过程增加了设计时间表的时间。现在，软件的优势在于，它可以在车门即将关闭的时候冲到火车上，追踪鞋子上的卫生纸，并在产品发布时设法登上火车。见鬼，有人甚至可以在火车开动后往车窗里扔几个袋子。这不是硬件文化。

是的，莱迪思的设备是可编程的，所以最后一分钟或现场更改是可能的。但是，虽然在软件程序中添加或移动一些软件指令通常不是什么大问题，但如果FPGA内容发生变化，就很难知道什么可能是大问题。软件中看似微不足道的算法变化可能会变成硬件上的巨大变化——尤其是在固定了引脚之后。

这并不是说不能做到;只是——你们有人试过用微软的Word作为页面布局工具吗?它本来就没设计好?你知道的，画框上有流动的文字之类的?你让页面看起来完全是你想要的样子，然后做了一个微小的改变，突然之间，图纸被扣到各种你从未想过的奇怪的地方，现在你花了半个小时试图建立一个新的稳定的页面布局，其中包括造成如此多混乱的微小改变。我并不想通过将fpga与微软软件进行比较来侮辱它们，但您可以了解到:看似微小的调整可能会导致严重的头痛。所以硬件可编程性不像软件可编程性那样宽容。因此我在上面将其命名为“半柔性”。

另一个悬而未决的大问题是，在Lattice设备中融合了多少传感器?它们是非常小的占地面积，低功耗的设备，但它还没有被证明可以做什么。当然，他们比QuickLogic设备有更多的LEs(忽略乘法器-是的，我知道，这真的不公平)，但你可以看到QuickLogic在他们的设备中实现融合所做的各种技巧。这不是软件到硬件的死记硬背转换;它涉及一个精心设计的底层微体系结构。我不得不说，我在QuickLogic的谈话结束后，感觉他们真的对问题进行了非常详细的思考。也许晶格设备中额外的le使这种杂技变得不那么必要，但需要时间来证明所需的门的数量。

最后，我们看看QuickLogic设备用户的设计过程。尽管他们的芯片是使用FPGA技术构建的，但它并不是定位为FPGA;这是一个可定制的传感器中枢。这意味着什么呢?在最简单的层面上，它带有一些由sensor Platforms完成的罐装传感器融合算法。如果你对它提供的功能感到满意，还需要一点:

• 上下文感知(大概是在一个有限的水平上，因为他们说他们将大部分上下文推送到AP)，
• 步统计,
• 磁力计多样性，以及
• 缓冲

除此之外，还有一个自定义工具，可以让用户指定要使用的传感器和算法。这一切都很好，但所需的输出是由AP加载到FPGA的位流。鉴于该设备没有作为带有FPGA工具的FPGA公开销售，该位流是如何生成的?传感器和算法可以影响两个CISC处理器——不仅影响在处理器上运行的代码，还影响自定义指令。CISC处理器是软核，所以一旦它们的配置和指令确定，它们就必须变成门。

这就是QuickLogic进入设计流程的地方。在指定了设计的各个关键方面之后，这些信息就会传递给QuickLogic。他们完成任务，将比特流交给设计师，以便集成到引导Flash中。

这使得QuickLogic的设计流程保持在软件或系统工程师的级别;QuickLogic执行硬件生成步骤。用户不创建RTL或微码。

因此，这四种接近传感器中心的方式导致了四种完全不同的实现解决方案的方式，如图2所示:

• 优化微控制器中的通用软件
• PNI传感器的中央有限寄存器调整
• Lattice的软件到硬件转换
• 系统级规范加上QuickLogic的QuickLogic在环。

图2。传感器集线器的设计流程和工作人员。

请注意，进行FPGA设计可能会对组织产生影响，或者如果公司没有内部技能，则可能需要外包解决方案。如果他们被证明太受欢迎，被设计工作淹没，QuickLogic的方法可能无法很好地扩展;他们需要准备一个B计划，以防他们遇到这样的问题。

在我们(暂时)结束对传感器中心的研究之前，正如前面提到的怀特所指出的，还有一个不确定因素即将出现:Android 4.4对传感器中心有特定的要求。虽然Android本身并不是一个“标准”，但它也可能是。当事情达到标准水平时，你就失去了灵活性。当你失去灵活性时，软件就变得不那么有价值了。

所以，在下一篇文章在本系列文章中，我们将着眼于Android 4.4的传感器中心需求。它们可能会产生更多硬件传感器集线器。或者听起来是这样的……

*进一步思考，并发可能有助于简化同步。传感器数据必须有时间戳，以便来自不同传感器的样本可以相互关联，因为传感器是连续轮询的。理论上，这可以通过并行轮询来解决，但到目前为止，频率还不够高，无法达到这种复杂程度。

更多信息:

点阵传感器管理

PNI传感器中心

QuickLogic传感器集线器

• 
• 
• 
• 
•