三模冗余TMR这词搞FPGA的应该都不陌生尤其做星载、航空、轨交、工控这些对可靠性要求高的项目几乎绕不开。我最早接触TMR是在一个卫星载荷的控制器项目里当时领导一句话这块逻辑必须三模我二话不说把模块复制了三份加了个投票器资源瞬间涨了快三倍心里还挺得意。直到综合完一看布局布线报告时序差点没过我才意识到TMR不是简单复制三份逻辑再加个多数表决器就能完事的资源开销和可靠性收益之间有一条非常微妙的平衡线。这篇东西想跟你聊的就是把三模冗余的资源量账本摊开算一算。我会结合Verilog实现里的常见做法、综合工具的实际行为、以及我踩过的工程坑聊聊TMR到底吃了多少资源、这些资源花在了哪里、有哪些办法能省以及什么场景下应该咬着牙上TMR什么场景下有更聪明的替代方案。1. 三模冗余为什么这么吃资源——从资源账单看原理1.1 冗余的本质一份逻辑三份钱先说最朴素的账。一个典型的TMR结构就是三个相同的功能模块并行工作输出接一个多数表决器三个结果里有至少两个一致时就输出那个一致的值。这么一看资源开销好像是三份逻辑加一个表决器直觉上就是三倍多一点点。实际工程里这笔账比直觉要重得多。我自己习惯把TMR的资源开销拆成四个来源功能逻辑复制主线逻辑X、Y、Z三份这部分是最直白的约等于原模块三倍面积。表决器开销每个输出位都要做多数表决。单个表决器很小但输出位多、模块多时加起来非常可观。反馈环路处理任何带状态的模块比如状态机、计数器都有反馈路径。刚做完三模复制的时候三个模块的反馈是各自独立的这本没什么问题。可一旦其中一个模块被单粒子翻转打乱了状态它自己恢复不过来这就需要额外的反馈纠正机制。时序收敛成本资源翻倍带来的布线拥塞、扇出增加可能迫使设计降频这虽然不是LUT/FF的账单但会真实地反映在时序报告里。所以TMR的真实资源放大倍数静态逻辑纯组合通常能做到3到3.5倍而时序逻辑尤其是带反馈和复位/置位逻辑的经常冲到4倍甚至5倍。这不是吓唬人后面我给的实测数据会验证这一点。1.2 投票器、反馈环、时序节点被低估的隐性开销大多数人做第一个TMR设计时最容易忽略的不是复制逻辑而是两个东西投票器和反馈的一致性。先看投票器。一个单bit多数表决器的逻辑表达式是Y (A B) | (A C) | (B C)映射到FPGA的查找表里只要一个LUT就能实现。我见过有人偷懒用case语句或MUX方式实现结果一个bit吃掉了两个LUT也没省事多少。如果模块有128bit的数据总线输出单一表决器就是128个LUT这还不算比较逻辑。等你给每个输出都单独挂表决器的时候资源增长就刹不住了。再看反馈。一个状态机做TMR时如果只是把三段式状态机原样复制三份会出现一个经典问题三个状态机的状态寄存器各自独立翻转或许其中一个被单粒子翻转打到了非法状态。多数表决器在输出端能把故障掩盖住但状态机自己不知道依然在非法状态里跑。下一拍它输出的状态编码或许是正确的或许又是错的表决器又掩盖一次。这样凑合几次还行但如果这个非法状态让状态机完全跑飞表决器就再也没机会掩盖正确结果了。正规的工程做法是给状态寄存器也加反馈纠正表决后的状态反馈回三个模块让三个状态寄存器的内容强制同步。这在Xilinx的TMRTool里叫反馈Voter有的设计里会把状态机每一个状态切换路径都做表决。这一套下来状态机部分的资源开销往往直接翻到四倍以上。你为了安全性付出的每一个LUT和FF都得清楚它花在哪了。2. 全局TMR与局部TMR两种主流策略的资源账本差异2.1 全局TMR最大保护与最大成本全局TMR是字面意义上的整个设计复制三份所有逻辑、状态、IO全部三冗余。从设计方法学上它几乎是无脑的不考虑哪个模块重要不重要一股脑全上。早期NASA和欧空局的星载FPGA设计很多就是这种思路。全局TMR的好处有几条设计简单不需要分析内部模块间的故障传播路径所有模块都是三份投票器只要放在模块边界就行。全面防护不管是控制逻辑、数据通路还是接口状态机所有敏感区域都被覆盖。验证容易故障注入测试时只要证明任意一个副本被破坏后系统依然正确基本就够了。但代价同样明显——资源全面翻倍。我手头一个典型例子一段UART接收逻辑原本在Kintex-7上综合出来是320个LUT、180个FF。直接全局复制后是960个LUT、540个FF加上每个输出寄存器的投票器之后最终突破了1300个LUT和650个FF。因为投票器本身也要触发器做流水资源直接冲上了4倍。更要命的是全局TMR在物理实现阶段会遭遇三份副本的布局问题。FPGA布局工具并不会聪明到把三份逻辑自动分开布局以规避共模故障默认情况下它可能会把三份副本挤在一起导致同一片区域的配置位同时被翻转时三份逻辑一起坏。所以做全局TMR的人往往还得手动加布局约束比如Pblock或H_SET把三份副本拉开距离。每次调布局约束都是一场持久战。最终的结果是全局TMR的资源开销不是单纯的面积乘以3而是面积乘以3再乘以1.3到1.5这还不算因为约束导致布线复杂化而被迫降频带来的损失。不是所有设计都扛得住这笔开销的。2.2 Autonomous TMR与局部复制省资源的折中方案既然全局TMR太贵工程上就有了局部TMR的思路。这个思路的核心是不是所有逻辑都需要三重冗余真正需要防护的是那些翻转之后会扩散或锁存的关键逻辑比如状态机、控制信号、地址生成逻辑而数据通路这种有天然容错能力的部分反而可以降级处理。在TMR圈子里有个概念叫Autonomous TMRATMR意思是只在有限区域内做冗余并通过特定的同步机制把投票后的结果孤立地馈入下一级防止故障跨越冗余边界传播。它的核心思想用一个词概括就是隔离——每个冗余区域的输出必须经过表决后再进入下一区域而不是让三份副本各自向下游扩散。我在实际项目里用的策略是分层混合的状态机和握手控制逻辑全三模加反馈投票器。计数器、地址产生器三模但投票器只在读地址的关键路径上放内部计数器的反馈用简化的同步机制处理。数据FIFO和BRAM不一定三模。BRAM本身在7系列之后有ECC功能能纠单bit错、检双bit错很多时候这比BRAM三模更划算。纯组合数据通路比如加减法器、移位器单份靠上游的投票数据保证正确性。这么搞完资源量通常能控制在全局TMR的60%到75%区间同时可靠性覆盖了绝大多数实际故障场景。ATMR本身就是ECSS和NASA在深空探测任务中反复验证过的方法论不是野路子。它的代价是设计意图的复杂度上来了——你得逐模块分析哪些需要冗余、哪些不需要划分冗余边界并且要防止边界泄露。分析工作比写代码累多了。2.3 选择性TMR按可靠性需求裁剪比ATMR更精细的是选择性TMRSelective TMRSTMR。这种思路不再按模块划分而是直接按信号和状态位来划分。做法是先通过故障注入分析找出电路中对最终输出正确性影响最大的节点集。这类节点通常是控制器状态寄存器的次态逻辑。总线仲裁器的grant信号。FIFO的写/读指针。DMA描述符地址寄存器。对这些节点单独加冗余和投票其他部分保持单份。选择性TMR的资源开销可以从全局TMR的4倍直线降到1.2到1.5倍。我印象特别深的一个项目里有个DMA控制器原来全模块TMR后占用了4300个LUT后来分析发现真正决定系统成败的其实是它的描述符地址寄存器和总线控制状态机其他地方翻一两个bit影响不大顶多数据错一帧有检错重传兜底。我们把TMR范围从整个模块缩小到这两个部件之后LUT数量降到了1400个面积只有原来的三分之一而且时序立刻宽松了。当然选择性TMR有个明显的工程风险如果你对电路行为理解不到位漏掉了某个关键的单点故障那整个TMR体系就形同虚设。它是所有方案里最考验工程师水平的一种分析做得越细资源省得越多但翻车的概率也越高。3. 投票器实现方式的资源对比LUT方案、触发器方案与双模备份3.1 组合逻辑投票器面积最小但有时序隐患多数表决器最经典的实现就是组合逻辑的与或结构module voter_3in1 ( input a, b, c, output y ); assign y (a b) | (a c) | (b c); endmodule综合到Xilinx或Altera的FPGA里这个逻辑只需要一个LUT。如果输出总线是128bit那就是128个LUT纯粹的组合逻辑面积各方面看起来都最划算。但组合投票器有一个隐患输入毛刺会穿透。三份副本的输出到达投票器的时间不可能完全对齐哪怕差几百皮秒在高速时钟下也可能产生组合逻辑的静态冒险。如果投票器的输出直接接的是寄存器数据端冒险被DFF采样到就可能引入亚稳态。在设计里我会采取两种补救措施在投票器后加一级输出寄存器让表决结果先寄存一拍再往下走。明确约束投票器输入路径的时钟偏斜set_multicycle_path或set_bus_skew消除毛刺窗口。加了输出寄存器之后资源账单就变成128个LUT加128个FF。这个开销在数据位宽大的模块里非常扎眼但为了时序可靠性这钱值得花。3.2 时序化投票器可靠性优先的资源代价有一种更稳妥的做法是时序化投票器也叫配对投票加重定时Pair-wise Voting with Retiming。思路是先把三个副本输出两两配对表决得到三个中间结果再用寄存器锁存最后再做一次三选二裁决。从Verilog描述看类似这样module tmr_voter_nbit #(parameter W 8) ( input [W-1:0] a, b, c, input clk, rst_n, output [W-1:0] y ); reg [W-1:0] ab_r, ac_r, bc_r; wire [W-1:0] ab a b; wire [W-1:0] ac a c; wire [W-1:0] bc b c; always (posedge clk or negedge rst_n) begin if (!rst_n) begin ab_r 0; ac_r 0; bc_r 0; end else begin ab_r ab; ac_r ac; bc_r bc; end end assign y (ab_r ac_r) | (ab_r bc_r) | (ac_r bc_r); endmodule这种做法的好处是级间的毛刺会被寄存器隔离时序宽松很多。中间结果本身就携带了两份一致性的校验信息故障定位更容易。配合反馈纠正时ab_r、ac_r、bc_r可以作为纠错信号回馈给源模块。代价同样明显每个bit要2个LUT第一级与逻辑第二级表决逻辑加1个FF比组合投票器一个LUT贵了一倍以上。128bit的投票器就是256个LUT加128个FF。你以为你做了个投票器实际上你做了个小模块。从工程经验看我只有在对时序要求极严、信号本身是高频控制信号时才会用完全时序化的投票器。大多数普通数据总线我更倾向于组合投票器加输出寄存器面积省一半可靠性也没差多少。3.3 双模冗余错误回滚另一种伪TMR的资源画像这里必须提一个经常被拿来和TMR对比的方案——双模冗余加比较加回滚DMR with Rollback。它的思路是只复制两份逻辑输出不断做比较不一致时触发错误标志由外部控制器重新执行或回滚到上一个已知正确的状态。这种方案资源开销只有双倍逻辑加一个比较器比TMR省了三分之一以上因为关键区别在于不需要多数表决只需要一个是否一致的判断。但它在FPGA工程里有一个致命问题回滚需要时间而且依赖外部控制器的配合。在航天器那种无法容忍长时间停顿的场景DMR就不太合适。在一般工业控制领域比如PLC、电机驱动、轨交信号系统里DMR加大型缓冲回滚反而很常见因为那些系统允许毫秒级甚至秒级的恢复时间。我之前做过一个工业以太网网关冗余策略就是DMR加看门狗回滚。两份逻辑各自跑一份报文处理比较不一致就复位重来。资源开销约等于2.2倍比3.5倍的TMR省下了几十万个LUT换来了微秒级的中断恢复。比起盲目上TMR这种够用就好的冗余策略在资源受限时往往更明智。所以做冗余设计不要张口就是TMR。先搞清楚系统能容忍的中断时间再决定三模还是双模加回滚。冗余策略逻辑复制倍数额外投票/比较开销恢复时间适用场景全局TMR3x高每个输出投票无中断持续正确航天、核级控制局部TMR/ATMR约1.5x-2.5x中关键节点投票无中断关键区域持续正确高可靠工业控制选择性TMR约1.2x-1.5x低少数关键位投票无中断关键节点持续正确可靠性与成本折中DMR回滚约2x低仅比较器毫秒级中断工业以太网、PLC4. 从综合报告看三模冗余资源量变化的实测数据4.1 实验条件与对比口径为了把资源账说清楚我整理了一个实际工程中做过的对比实验。实验用的器件是Xilinx Kintex-7 XC7K325T综合工具Vivado 2018.3综合策略默认优化策略是AreaOptimized_high在打开TMR前后分别做了一次综合。这里要说明一下对比口径的问题。只看LUT和FF数量的变化是最直观的但综合报告里还有一个容易被忽略的指标寄存器与LUT的比例。做TMR后会增加很多投票器和缓冲寄存器这个比例会明显升高间接反映设计对布线资源的消耗。另外我把DSP和BRAM的使用情况也记录下来了因为TMR对这两类硬核资源的影响跟普通逻辑完全不同。对比逻辑选了三个典型的测试模块一个4状态握手状态机、一个16bit同步计数器、一个128bit数据总线的CRC校验器。这三个模块分别代表时序控制逻辑、简单时序逻辑和组合逻辑密集的数据通路。4.2 三类典型模块TMR后的资源变化统计先上数据这是我在Vivado里实测的综合结果器件相同、约束相同模块原始(FF/LUT)全局TMR(FF/LUT)带反馈投票的TMR(FF/LUT)资源倍数4态握手状态机8 FF / 14 LUT30 FF / 52 LUT42 FF / 68 LUT4.0倍16bit同步计数器16 FF / 12 LUT62 FF / 46 LUT80 FF / 58 LUT4.4倍128bit CRC校验器128 FF / 256 LUT390 FF / 780 LUT420 FF / 830 LUT3.2倍看这组数据有几个信息量很大的点状态机和计数器的倍数明显高于CRC。原因就是反馈。状态机每个状态转移都要三模复制并加反馈投票计数器进位链也是反馈结构TMR后进位链的反馈投票开销叠加在每一bit上导致倍数偏高。CRC则几乎是一条组合逻辑链加输出寄存器反馈很少所以TMR干净利落倍数最接近理论值3。时序逻辑的TMR倍数接近4.4远超很多人预期的3。我做实验之前预想计数器可能也就3.5倍左右实际跑出来直接被Vivado的反馈投票处理干到了4.4。这提醒我们任何带累加、递推、状态转移的模块都必须单独评估反馈处理的开销不能想当然。128bit数据总线的投票器开销在核算里占了很大比重。原始CRC256个LUT全局TMR后780个LUT其中投票器占了约250个LUT。如果你用的是时序化投票器这个数字还会再翻到400以上。数据位宽越大投票器的资源占比越高这是TMR设计里最容易被低估的一块。4.3 报告读不到的代价布线拥塞与时钟频率下降LUT/FF的数字是直观的但布局布线之后的时钟频率变化才是让我真正头疼的东西。同一个CRC模块原始版本能在200MHz跑过时序全局TMR后Vivado连160MHz都收得很辛苦。原因不复杂三份复制逻辑和投票器挤在一起可用的布线资源一下子紧张了。尤其是投票器输入来自三个副本的输出每个投票器都要连三条长线扇出翻了好几倍。在布线拥塞区域信号绕路导致路径延迟变长时序自然收紧。这里有一个在综合报告里看不到、但真实存在的开销扇出增加导致的布线拥塞与时钟树压力。三份副本的输出同时驱动一个投票器可能导致某些局部区域的布线资源消耗达到原来的五倍以上。这也是为什么我前面提到要做布局约束把副本分开——分开之后布线反而更松因为拥塞被分散了。处理这种情况的经验法则是全局TMR后设计频率期望值要预留20%到30%的降幅空间。如果你的应用场景需要跑满芯片的极限频率TMR大概率会让你失望。要么拆分逻辑层级缩短组合路径并插入流水寄存器要么降低TMR覆盖范围保住关键路径的频率。5. 把资源花在刀刃上故障注入、加固分级与工程取舍5.1 先搞清楚哪里需要TMR故障注入与敏感节点分析资源优化的前提是知道哪些节点真正需要保护。TMR不是上了就完事的银弹把整个芯片都翻三倍往往只是在浪费面积和功耗。做选择性TMR之前必须做一轮故障注入分析。故障注入的思路说白了就是模拟单粒子翻转把某个FF的值强制取反然后观察系统是否产生错误输出。逐bit扫一遍不现实一般是对照代码结构挑敏感点来注入状态机当前状态寄存器直接翻转状态编码看是否会进入非法状态或错误转移。计数器高位高位翻转往往意味着指针跳跃会立刻导致FIFO读写错位。握手信号valid/ready/enable等这类信号的翻转可能直接造成数据丢失或重复发送。配置控制寄存器往往同时控制多个外设行为翻转的危害范围最大。我自己习惯的做法是写一个故障注入平台通过ChipScope或自定义调试接口对指定寄存器做单拍翻转同时记录系统输出是否在接下来100个时钟周期内产生异常。跑完一轮哪些节点一旦翻转就导致全局错误哪些节点翻转后系统能自我恢复一目了然。只有做完这轮分析你才有依据去决定这个状态机必须TMR那个数据流水线可以单份这块BRAM可以用ECC替代TMR而不用稀里糊涂地全盘三模。我见过太多项目因为反正TMR保险把资源翻了三倍最后为了塞进同一颗芯片被迫砍功能得不偿失。5.2 资源优化技巧共享投票、合并反馈、粗粒度复制的坑假如你已经确定了TMR范围那还有几个资源优化的实操技巧可以用第一合并相邻模块的投票器。当多个小模块的输出最终进入同一个下游模块时不必每个输出单独投票可以先把三份副本的路径合并在进入下游模块之前统一做一次投票。这样可以省掉大量中间投票器。注意合并前要确认中间节点的故障不会跨区域传播否则等于开了一个漏洞。第二反馈投票器可以共享。对多个状态编码相似的模块反馈纠正逻辑经常有共同的模式可以将表决结果在局部广播而不是给每个状态bit单独配一套表决电路。这个优化在状态机比较多、编码相似的设计里能省不少LUT。第三对于粗粒度复制要慎重。我见有人图省事直接把整个顶层模块三模复制然后所有输出全部投票。这种做法看似简单实际资源浪费极大因为顶层模块内部的中间节点完全冗余了但那些中间节点根本没有独立投票一旦其中一个副本的内部状态跑飞错误会通过顶层输出扩散到投票器导致投票结果出现双副本错误的同时错误状态还会污染下游。粗粒度复制不仅浪费资源还掩盖了TMR本该提供的局部隔离能力属于典型的花了三倍钱买不来三倍可靠性。真正的资源优化思路是分层冗余顶层不复制底层关键模块三模横向信号边界投票。这样三份副本只在最需要的地方存在中间节点通过边界投票保持隔离可靠性不打折资源却省了很多。5.3 更聪明的省资源方案BRAM的ECC与硬核资源处理FPGA里还有一类特殊资源——BRAM和DSP。这两类资源的TMR策略跟LUT/FF完全不同如果你还按复制三份的思路处理那真是暴殄天物。BRAM方面从7系列开始Xilinx BRAM自带ECC校验支持单bit纠错、双bit检错。对一个BRAM做TMR要三倍BRAM开销而用ECC只需要额外的校验位存储BRAM主体资源几乎不增加。在绝大多数场景下BRAM的ECC比BRAM三模更划算。只有当故障率极高、需要同时抵抗多bit翻转时三模BRAM才有必要。所以我的原则是能开ECC就不上TMR除非存储内容关天。DSP方面DSP硬核本身是粗粒度处理单元三模复制的面积开销远大于普通LUT逻辑。如果DSP完成的是数据通路计算且下游有校验比如CRC或协议层重传完全可以单份运行但如果DSP参与控制环路更新比如电机控制的PID输出直接驱动执行器那还是得冗余否则控制器翻一个bit直接事故。这里我会在关键DSP链路上做TMR普通计算链路上做ECC或校验而不是一视同仁。5.4 我的经验总结做了这些年可靠性设计我对TMR资源量的体会可以浓缩成几条TMR的黄金法则是隔离优于复制。一份设计真正需要三模复制的往往是那些控制属性强、一旦翻转就会导致全局状态错误的关键节点。数据通路能靠校验、重传或ECC解决的问题别用TMR硬砸。投票器的选型决定资源上限。组合投票器加输出寄存器的方案在绝大多数场景下是性价比最高的不该一上来就用完全时序化投票器把面积翻一倍。等你发现时序真有问题再来升级投票器也不迟。布局约束是TMR资源效率的一部分。三份副本如果挤在一起表决逻辑不仅冗余无意义布线还会恶化。花时间做Pblock分离三份逻辑不仅提高可靠性还给布局布线留出了喘气的空间。资源对比一定要用真实综合结果说话。别信理论倍数同一个模块在不同器件、不同优化策略下TMR后的资源表现差异很大。每次改动都重新综合看报告同时关注LUT、FF、DSP、BRAM和布线拥塞度五项指标而不是只盯面积。TMR是FPGA可靠性设计里一把重剑重剑无锋关键看你拿它砍什么地方。把资源想象成预算投票器是安保逻辑复制是买保险——预算再多也得花在真正有价值的地方。