异步电路设计：丢掉时钟，用握手协议重构数字逻辑

大家学数字电路的时候几乎所有的知识体系都在围绕一个东西打转——时钟。时钟沿一到寄存器采样数据向前流动一切以时钟为节拍。但有一类电路偏偏不要这个节拍器让每个电路模块靠相互握手来决定“什么时候开工、什么时候交活”。这就是异步电路设计Asynchronous Circuit Design。我第一次接触这个概念的时候第一反应是“这也能行”后来真正动手做了一版异步数据通路才明白不要时钟不是把同步电路里的钟拆了就行而是在底层思维上整个换一套。这篇内容适合三种人被时序收敛折磨到想换个活法的人、做低功耗项目发现时钟树功耗占比太高的人以及单纯想搞明白“不用时钟的电路凭什么能正常工作”的好奇派。我会把工作原理、核心难点、主流风格和实战流程整合成一版项目复盘式的踩坑总结。里面所有的参数和步骤都来自我做一块异步DSP模块的经历有些坑公式里看不出来。1. 为什么有人会想扔掉时钟异步电路到底在解决什么问题1.1 时钟这玩意儿的隐藏成本比你以为的高得多同步电路设计里时钟树综合是一道大坎。时钟要送到每一个寄存器为了确保所有时钟沿同时到达需要插入大量的缓冲器在大型芯片上时钟网络的功耗可以占到芯片总功耗的30%到40%。这还只是电费。更麻烦的是时钟偏移skew芯片面积越大时钟线跨的物理距离越远skew就越难收敛。为了满足建立时间和保持时间你得在时序分析工具里反复迭代在关键路径上插buffer跑一堆timing sign-off一套流程下来光等工具跑完就够喝好几杯咖啡了。异步电路把这块成本整个砍掉了。模块之间不再需要全局时钟对齐而是通过“我准备好了”“我做完了”这种握手信号来协调。没有全局时钟就没有全局时钟树自然不需要布那么长的时钟线也不需要在上面反复插buffer。功耗低是异步电路最著名的卖点但说实话我第一次被它吸引纯粹是因为烦透了时钟树综合和时序收敛。1.2 “事件驱动”替代“时间驱动”一个节拍器都没有的世界同步电路的底层逻辑是“时间驱动”时钟沿是全局的节拍每个周期固定所有模块必须在这个节奏里完成自己的事哪怕绝大多数周期里任务早就做完了也照样空转耗电。异步电路的底层逻辑是“事件驱动”数据到了我就开始工作干完了我用握手信号通知下游没活干我就完全闲下来。这个差异在平均延迟上有很大的好处。同步电路的速度由最差路径决定因为最差路径在每个周期都得在时钟沿前跑完。异步电路是数据到哪就干到哪平均延迟就是平均路径的延迟而不是最差路径的延迟。对一些计算量大但输入模式有明显分布的算法来说异步电路的平均性能优势非常可观。我做的那块DSP整数运算单元在典型输入分布下平均完成时间比同步版本快12%左右虽然峰值性能未必比得上精心优化的同步设计但平均性能确实赢了。1.3 摆脱“全局同步假设”后的模块化红利还有一个容易被忽略的点是模块化。同步电路设计里要把一个新模块和一个老模块拼在一起必须保证两边的时序能对上这往往意味着重新做时钟树综合。异步电路里如果两个模块的握手协议一致它们之间的时序是“松耦合”的接口只有一组数据线和一组握手线两边频域可以完全不同。这个特性让异步电路在异构集成里格外有价值。我见过有人把跑着几GHz的小核和几百MHz的老IP用异步桥接方式接在一起握手协议统一后两边互不干扰改动量比重新对齐时钟小了一个量级。1.4 但别高兴太早困难是从哪个方向来的异步电路有这么多潜在优势为什么几十年了市场份额还是很低因为代价也很明确没有时钟帮你“同步”所有状态之后所有原本被时钟掩盖的问题都得设计者自己扛。竞争、死锁、数据完整性任何一点处理不好芯片就在你意想不到的时刻抽风。后面几章我逐一展开谈这些都是我实际踩过的坑。2. 先看明白最简单的握手约定四相位协议与数据捆绑2.1 用Req和Ack两个人对话来理解握手异步电路最基本的通信机制是握手协议。两个模块之间至少有两根控制线发送方拉高Request请求表示“我有数据要发给你”接收方看到Req后做自己的处理干完后拉高Acknowledge应答表示“我收到了并可以继续”。这两个信号的一来一回就构成了数据搬运的基本节奏。最常见的是四相位握手协议也叫返回归零协议Return-to-Zero。它包含四个事件Req拉高、Ack拉高、Req拉低、Ack拉低。这样一对完整的请求-应答循环才完成一次数据传输。为什么非要把信号拉回低电位很简单为了识别下一次传输的起点。如果不归零两个高电平之间的边界很难界定接收方不知道你是新发了一笔数据还是上一笔还没结束。归零后每个上升沿都代表新请求逻辑判断干净利落。2.2 数据捆绑Bundled Data是最朴素的异步实现在四相位握手的基础上数据怎么传呢最直接的做法是让数据线和Req信号“绑在一起”——发送方先保证数据稳定然后拉高Req通过一个延迟匹配链delay matching确保接收方在看到Req时数据一定已经稳定。这种风格叫bundled-data数据通路基本沿用同步设计里的运算单元控制部分换成握手逻辑实现代价最低。配套的延迟匹配链在数位电路上就是一串buffer或者专门的延迟单元。它的延迟必须覆盖发送方数据通路的“最坏传播延迟”否则接收方读到的可能是中间态垃圾数据。当年我刚上手时first版就把这里设计错了数据通路延迟是2.1ns延迟链只给了1.8ns结果跑到仿真2万周期左右开始偶发读到错误数据查了一整天才定位出来是延迟链卡了脖子。2.3 C-Element异步控制逻辑的基石门实现异步控制逻辑光靠与门或门远远不够因为我们需要一个“等所有人都到齐了才翻状态”的门。C-ElementC门就是干这个的当所有输入都为0时输出0所有输入都为1时输出1但只要输入不一致输出保持不变。你可以把它理解成一个“全员一致才行动”的守卫。我用一个实际场景说明一个缓冲区有多个写口必须要等所有写口都完成写入才能把数据一起送到下一个模块。如果用与门写口1完成了拉高写入完成信号写口2还没完成时与门输出已经为高下游就可能提前误判。C门只有在所有写口都拉高时才输出高天然实现这套等待逻辑。异步控制电路里C门出现频率极高很多握手控制器核心就是一个C门套几个基本逻辑门。3. 无时钟带来的三座大山竞争、死锁与数据残留3.1 没有仲裁者的竞态同一个信号被同时驱动时谁来定输赢同步电路里寄存器采样有明确的时钟沿作为统一时刻信号变化的时间点相对来说不那么致命。异步电路没有这个统一时刻两个模块如果同时向同一条线写值結果完全取决于谁能“最后”赢过对方而“最后”这个判定在物理上是race condition没有确定答案。我实际遇到的一个场景两条握手路径汇聚到一个仲裁模块两个上游同时发起请求仲裁模块必须决定先服务谁。这个模块的verilog行为级描述写起来毫无问题但综合成门级之后如果不加小心两个请求信号会同时在一个锁存器的输入节点上竞争最后输出状态乱掉。解决方式是在仲裁器里用穆勒C门设计专门的互斥单元让两个请求先在互斥逻辑里分出胜负再往下游传递。互斥单元的标准做法是加入一个反馈回路让先到的请求自动“锁死”另一个请求的通道这样即使物理上两个信号到达时间相差只有几皮秒逻辑上也能保证只有一个赢家。3.2 死锁的真身两边都握着资源等对方先松手死锁是异步系统里最经典的故障模式跟编程里的死锁本质一样模块A必须等模块B的Ack才能拉低自己的Req准备下一次发送但模块B必须等模块C释放一个共享资源才能发Ack模块C又在等模块A完成另一笔数据。三个进程谁能先动谁都不能整个系统卡死。这种死锁在仿真里很容易暴露但有讲究的芯片上往往表现为“跑着跑着所有信号冻结在某一个状态内部没有任何翻转”。排查死锁的常规办法是画握手依赖图把每个Req/Ack的等待关系标成有向边找闭环。我遇到过最隐蔽的一次死锁是某个模块在初始化状态里漏拉了一根Ack信号导致上游一直误以为它没空死活不走下一步。这种初始化条件漏配的问题仿真里行为级模型很难预见到门级仿真跑了几百万周期才复现。3.3 数据残留旧数据的幽灵在没被覆盖前让下游做了错误决定数据线本身没有“有效”标志位有效谁是捆绑在Req/Ack上的。如果上游发送方已经把Req拉起来了但还没有把新的数据稳定地送到数据线上数据线上还残留着上一次传输的旧值接收方看到的仍然是旧数据。如果接收方对数据线的判断完全信任Req信号就像bundled-data风格里假设数据先于Req稳定那没问题。但假设一被破坏——比如延迟匹配链不够长——接收方就可能把残留的旧数据当成新数据采进去。另一种数据残留出现在复位阶段。异步电路的复位设计没有同步复位那种全局时钟辅助必须在无时钟情况下保证所有存储单元进入已知状态。很多初学者的做法是给每个C门加一个异步复位端但这个复位信号在电路里的传播顺序也可能引发竞态。我后来采用的方式是把复位当成一个近似“全局握手事件”来对待先复位控制通路等控制通路state稳定后再让数据通路开始工作。3.4 放大镜下的核心差异时钟掩盖了多少脏活累活说到底同步电路把一堆脏活——状态对齐、广泛握手、统一恢复——全部浓缩在时钟沿里设计者只需要保证时序满足约束。异步电路把这些脏活全部还原成了设计逻辑本身等于把所有关于“什么时候该干什么”的决定权交给了电路模块自己去协商。这带来的好处是灵活和低功耗坏处是设计者必须自己管理并行、竞态、等待关系心智负担大了一个量级。4. 风格流派之争延时不敏感、准延时不敏感和微流水线到底选谁4.1 最激进的延时不敏感DI设计逻辑正确与否只取决于信号的布尔关系延时不敏感Delay-Insensitive简称DI风格理论上不管每个逻辑门和连线延迟是多少只要电路拓扑不变功能就一定正确。这个性质极其诱人意味着物理设计阶段随便改走线、随便优化门级延迟都不会破坏功能正确性。代价是什么代价是DI实现里完全不使用数据捆绑而是用双轨编码——每根数据线用两根物理线表示分别标记“数据为0”和“数据为1”接收方必须同时看到0轨或1轨的变化才确认数据到了这种编码方式直接让数据通路的面积和功耗翻倍任何一位翻转都需要两根线同时完成。真正全DI的设计到目前为止都是学术圈为主工业界用的非常少。大面积电路里真要做到所有交互都延时不敏感很多死锁和仲裁问题会变得非常棘手尤其是两个模块同时向一个槽里发数据时仲裁过程本身就不是延时不敏感能优雅解决的。4.2 准延时不敏感QDI工业界最接近实用的折中方案QDIQuasi-Delay-Insensitive在思路上很务实承认某些关键路径的延迟会被一些弱化的“等长约束”束缚但整个设计不依赖具体门延迟值而是要求在特定拓扑假设下正确。QDI最典型的实现方式是双轨编码加完成检测completion detection即每条数据线准备好后产生一个“完成”信号所有完成信号合并后再告诉下游“这批数据真的到了”。相比DIQDI对延迟的假设稍强一点但因为完成检测电路可以把各个位的速度差拉齐实际鲁棒性比bundled-data好很多。我做数据通路时用过QDI风格的加法器。双轨编码确实烧面积但它的优势非常直观不需要针对每个运算单元手工设计延迟匹配链路。比如一个异步加法器它的关键路径延迟跟输入数据有关进位传播链长度不同同步设计必须按最坏情况流延迟QDI设计用完成检测感知到“进位已经消停”再宣布完成平均延迟更短。这个特性在数学运算单元上非常诱人。表不同异步风格在关键属性上的对比设计风格数据编码对延迟的假设典型开销工业应用成熟度Bundled-Data单轨延迟链需匹配所有数据路径延迟面积增加约1.3~1.5倍中等双轨QDI/DI方向一根位线拆成两根轨线假设弱延迟/等长约束面积增加约2倍功耗上升低到中等微流水线数据是单轨控制用事件流只需节拍传递不需要全局对齐面积增加约1.2倍中高4.3 微流水线让现有的同步数据通路“试水”异步控制微流水线Micropipeline是上世纪80年代末提出的一个经典思路它不改变数据通路的形态每个数据运算单元还是普通的组合逻辑和寄存器只是用一个事件流控制信号来代替全局时钟让数据沿着一条链逐级通过各个运算阶段。每一级的“时钟”在本地产生当一个阶段完成运算就向前一级发出允许流逝信号向后一级发出数据已准备好信号。微流水线最大的好处是从同步设计迁移过来的痛苦最小。你的运算单元、寄存器、FPGA里的组合逻辑基本都能沿用只是把原先的全局时钟网络替换成一串本地时钟生成逻辑。我做异步DSP模块时第一版原型就是用微流水线方式搭建的先把全局时钟摘掉改成四相位握手控制的本地时钟门控然后再逐步把关键运算单元改成QDI版本。这样的步步迁移法比一上来全盘重写要稳得多。4.4 选型判断你的需求决定你选哪条路我给一个简单判断逻辑如果你只是一个RTL设计者手里有现成的同步数据通路想要试水异步控制微流水线最合适如果你的目标是低功耗和平均性能愿意为面积付租金考虑QDI双轨风格如果纯粹是学术研究想把理论边界推到底那就挑战DI。工业界大部分工程化项目其实落在微流水线和QDI之间这两个流派不至于让你的芯片因为某个门延迟浮动就罢工。5. 实际做一版异步电路的开荒流程从行为描述到晶体管级映射5.1 用CHP/CSP做行为级描述先别急着画电路设计异步电路的第一步跟同步设计很不一样你得先写“协议”而不是先画架构图。我用的是CSP通信顺序进程Communicating Sequential Processes风格的CHP语言来描述每个模块的行为。CHP里的每条语句都是事件级别的动作比如“发数据给下游”和“等上游应答”都是显式的通信语句而不是像Verilog那样在一个时钟边沿里隐式完成。这个阶段产出的不是可综合的RTL而是一份“行为契约”。比如我描述一个异步乘法器CHP里会写清楚输入数据得先从上游握手接入然后进行乘法运算运算完成后通过完成检测信号触发输出握手。所有交互都通过通信事件显式表达而不是靠全局时钟隐含排序。这一步做扎实了后面转换成电路结构是水到渠成的。5.2 语法转换与细化把通信事件拆成握手逻辑和运算单元有了CHP行为描述下一步是把通信事件细化成实际的握手控制逻辑。一个大粒度的通信事件会被拆成一组更细的握手信号用C门和互斥单元搭起控制图。这个过程叫细化refinement是整个异步设计里技术含量最高、也最容易出错的一步。细化过程里最常见的错误是“不匹配的环境假设”。举个例子我在细化一个上游模块的发送过程时默认下游收到数据后会立即拉高Ack但下游那边实际上是先做一段内部运算才拉Ack。两边对“Ack的语义”理解不一致细化出来的控制逻辑自然对不上。解决方式是先把每个模块的握手行为定义精确到每个环节再开始细化而不是边细化边调整。5.3 合成与验证没有时钟让你不能只跑一排波形异步电路验证的难点在于仿真工具默认会有一个time-step驱动逻辑更新而异步电路的事件驱动模型在仿真器里往往需要用特定方式建模否则C门的事件更新会被漏掉或者误触发。我用的流程是先把控制图转成petri网风格的事件模型进行死锁和活锁检查然后再映射到具体门级网表做仿真。这一步我建议大家一定要用“事件驱动的仿真器视角”来审视所有输入变更。比如同步仿真里你可以同时翻转10个输入信号让它们在同一个time step完成更新但在异步仿真里这10个输入必须严格模拟“先后到达”的物理事件顺序否则会掩盖竞态。我吃过一次亏在行为级仿真里把两个握手信号放在一个time step里同时翻转完美规避了竞态但门级仿真一跑就暴露了互斥单元的竞争被迫打回重新设计。从此之后我在行为级仿真里也强制把两个输入错开更新不再图省事。5.4 物理实现的“最后一公里”完成检测树、延迟匹配链和时钟域隔离物理设计阶段异步电路有几项特殊工作要做第一是完成检测树。在QDI风格里每个数据位都要产生一个完成信号把多个完成信号合并成一个总的完成信号需要一棵以C门为核心的合并树。这棵树的拓扑对称性必须严格保持否则可能出现某一位“完成”信号先到先让下游工作而另一位还在慢慢走的情况。我在布线时专门给这棵树的线网设置了匹配约束。第二是延迟匹配链的物理验证。在bundled-data风格里延迟匹配链的实际硅片延迟会被工艺角漂移影响通常需要留出20%到30%的余量再用后仿验证最坏工艺角下匹配链依然比数据路径长。这一步比同步设计的时序分析更敏感因为如果匹配链短了不是“性能下降”那么简单而是功能直接错乱。第三是与世界交互的边界隔离。当异步电路嵌在同步SoC里时接口处需要一个异步-同步转换桥gearbox。这个桥用两套完全独立的时钟域逻辑分别采样并在中间用异步FIFO缓冲数据。我做过的有效做法是门控时钟的同步输出再在握手信号上做同步器打两拍确保同步部分永远不看到亚稳态。这里没有什么黑魔法就是老老实实按“异步进同步出”的规范来。6. 什么时候才真正值得上异步功耗账、性能账和团队账6.1 功耗账没有时钟树数据通路的功耗还剩下什么对很多场景来说异步电路最直观的吸引力是省掉了时钟树功耗。同步SoC的时钟网络功耗占全芯片30%到40%异步电路把这部分砍掉后理论上理想省功耗幅度就在这里但实际数据要看数据通路的翻转率。数据翻转越频繁异步握手的优势越小因为握手信号本身也要翻转而且双轨编码还会多翻一倍。我做异步DSP模块时测过的数据是在低负载率场景平均每10个周期只有1次有效运算同步版本功耗高出异步版本28%但在持续满载的场景异步版本反而因为握手信号开销和完成检测树的每周期翻转功耗高出同步版本6%左右。异步不是“所有情况下都省电”而是“空闲时更省电”。如果你想让芯片在绝大多数时候处于低活跃状态异步的省电收益会非常可观。6.2 性能账平均性能不是你最快的那个周期而是你整个分布的期望同步设计以最差路径为性能天花板异步设计以平均路径为性能基线。这带来一个很有意思的权衡在输入分布比较“偏科”的算法里异步平均性能可能远高于同步因为“极端慢”的输入很少出现但如果输入分布比较均匀最差路径出现的概率不低异步平均性能优势就会被吃掉。我当时做的那块整数运算单元是典型的多项式计算数据分布的尾部概率低异步版本平均完成时间比同步快12%。但如果是图形处理那种每个输入都长得很像的均匀分布异步大概率打不过优化良好的同步流水线因为同步流水线的吞吐是稳定的不会因为某几个输入慢就拖慢整体。选型之前一定要拿真实业务数据去统计输入分布而不是凭空拍脑袋说“异步性能高”。6.3 团队账EDA工具链弱人力和时间成本要算清楚最后说一个很多技术文章不爱讲的点异步设计的EDA生态远不如同步成熟。虽然现在有一些商业工具支持异步流程包括综合、形式验证和时序分析但和同步设计那套调用即得、文档丰富、社区庞大的工具链相比异步设计的大量工作要靠自带脚本和内部验证框架自己搭。这意味着团队里得有少数人能写协议分析工具、能造握手验证环境还得能处理“标准工具不支持只能用脚本强行检查”的场景。如果是小团队、小项目、芯片流片窗口紧张我会非常谨慎地劝你别轻易全盘异步化。合适的异步化路径是在SoC的关键功耗域里挑一个单独模块比如数据通路加速器、接口缓冲或异步FIFO桥接先做域内异步再通过异步-同步转换桥与外部打交道。这样做既能吃到异步的低功耗和平均性能红利又不至于把整个芯片的验证复杂度拉爆。6.4 回看那个“要不要去掉节拍器”的决策从我个人的体验出发异步设计不是要替代同步设计而是在特定场景里提供另一条更合适的路径。如果功耗空闲态优势明显、平均性能有红利、模块间交互需要松耦合异步思路值得认真考虑。如果只是把同步电路里的时钟拆掉却不改数据通路那多半会赔上面积和验证时间换来不确定的收益。我在实际项目中最大的体会是异步设计最难的从来不是那些门级电路和握手逻辑本身而是设计者必须从“时间驱动一切”的惯性里挣脱出来。一旦你习惯了用事件的眼光看待数字电路回头看同步设计你会比过去更懂它为什么能如此高效地掩盖复杂性也比过去更清楚它在哪些场合其实是在硬撑。