很多人以为FPGA里做除法就是写个“/”完事真做项目的时候才会发现综合器直接给你生成一堆LUT级联逻辑时序一团糟资源消耗还离谱。这时候你就需要用到Xilinx官方提供的除法器IP核对应的产品指南就是PG151Divider Generator。这篇笔记算是我的实战复盘把这颗IP的选型思路、配置细节、仿真调试踩过的坑以及性能优化方案都拉出来聊一遍给正准备用或者已经在用PG151的朋友做个参考。PG151这个IP全称是Xilinx LogicCORE IP Divider Generator本质是一个基于恢复余数算法Radix-2的除法器解决方案。它能解决的核心问题有两个一是把“除法”变成可控延迟的流水线运算让时序更好收敛二是让商和余数可以单独配置位宽适配各种定点数除法场景。适合谁适合在FPGA里做定点算法、协议解析、坐标变换、归一化处理以及任何需要频繁做除法但不想被组合逻辑时序坑到的开发者。1. 整体设计与思路拆解为什么非要用除法器IP1.1 用“/”运算符到底行不行先说一个很多新手都问过的问题Verilog里直接写assign q a / b;不就行了吗答案是可以但仅限于两种情况一种是仿真验证用另一种是除法操作频率极低且不关心时序和资源。真实工程里这个“/”会被综合成什么完全取决于工具的心情可能是一大串级联的减法器也可能是某个DSP原语但大概率是延迟不可控、时序极差的组合逻辑。举个例子我之前做过一个32位无符号整数除法的模块直接用/写在100MHz时钟下时序就已经出现了建立时间违例关键路径长度直接干到了十几纳秒。换成PG151之后只需要配置成流水线模式延迟固定拍数时序完全可控资源占用还更透明。1.2 恢复余数算法的工作原理PG151底层使用的是Radix-2恢复余数算法这个算法的核心思路其实跟我们手算除法很类似每一位商数都要通过“试减”来确定。当前余数左移一位然后减去除数如果结果大于等于0这一位商就是1新的余数就是相减后的结果如果结果小于0这一位商就是0余数要加回去恢复原值。这里有个关键特性恢复余数算法的计算延迟跟“商”的位宽强相关每产生一位商至少需要一个时钟周期。这也是为什么PG151的配置界面里商位宽和余数位宽是分开设置的——因为商位宽直接决定了最小延迟拍数。如果你只需要商的低16位有效把商位宽配成16位延迟就能比32位配置省下一半。1.3 使用IP核相比手写RTL的优势除了时序可控之外PG151最实在的优点在于它已经帮你处理好了各种边界条件。比如除数为0的情况、有符号数和无符号数的符号扩展、商和余数拼接格式、AXI4-Stream握手信号的时序等等。如果这些逻辑全部手写代码量倒是不大但调试起来非常难受尤其是数据流打拍的时候很容易出现valid和data错位的问题。另外一个容易忽略的点是Xilinx的IP核会跟着Vivado版本更新时序模型和实现结果都是经过官方验证的。相比之下自己写的除法器模块虽然能跑但在不同芯片、不同速度等级下的表现差异很大出了问题只能自己扛。用官方IP至少可以少背一个锅。2. 核心细节解析与实操要点PG151的端口与配置项2.1 接口信号一览PG151的接口总览并不复杂主要是AXI4-Stream协议的那套握手信号。具体包括aclk时钟输入所有信号都在这个时钟的上升沿采样。aresetn低电平有效的异步复位可选配置。s_axis_divisor_tvalid除数通道的有效信号。s_axis_divisor_tdata除数数据总线位宽由“除数宽度”决定。s_axis_dividend_tvalid被除数通道的有效信号。s_axis_dividend_tdata被除数数据总线位宽由“被除数宽度”决定。m_axis_dout_tvalid结果有效信号。m_axis_dout_tdata结果数据总线位宽等于“商宽度余数宽度”。这里有个非常容易踩的坑tdata总线的拼接顺序。PG151的输出结果不是分成商和余数两个独立总线而是拼接在m_axis_dout_tdata上具体格式是“商在高位余数在低位”。我之前就见过有人把商和余数搞反了整个模块输出全部错乱排查了半天才发现是总线解析的问题。2.2 关键配置项详解PG151的配置界面里有一堆选项每个选项背后都对资源和性能有影响。我挑几个最容易犯迷糊的配置项重点说一下。第一个是“算法类型”Algorithm Type。PG151提供Radix-2和High Radix两种选择。Radix-2是默认选项资源占用小但延迟较高High Radix比如Radix-4以牺牲更多逻辑资源为代价减少迭代次数适合对延迟敏感的场景。不过High Radix对时序的要求更严苛在低端芯片上反而可能因为路径太长导致频率上不去这个要根据实际芯片型号来权衡。第二个是“商和余数的宽度”。这两个值是分开配置的而且除了位宽本身还会有一组“余数类型”的选项有符号余数还是无符号余数。这个直接决定了输出的格式。咱们做定点运算的时候通常希望余数的符号跟被除数保持一致这个时候一定要选“有符号余数”否则负数除法得到的余数你根本没法用。第三个是“延迟配置”Latency Configuration。PG151允许你手动指定延迟拍数也可以选择“自动”模式。自动模式会按照算法所需的最小拍数来生成而手动模式则可以额外增加延迟。这个额外延迟的作用是帮助时序收敛因为它可以让你把输出级往后推方便模块之间的时序对齐。但要注意延迟拍数改大了之后tvalid的拉高时机也会相应延后下游模块如果按照固定延迟去采样数据就一定要把新的延迟值算进去。2.3 时序和对称性要求还有一个很多人容易忽略的前提条件被除数位宽和除数位宽并不需要相等但是商宽度和除数宽度之间存在约束关系。PG151要求“商的宽度”不能大于“被除数的宽度”而“余数宽度”默认等于“除数宽度”。如果被除数宽度小于除数宽度商只能是0这在某些不需要商的场合也许能用但最好提前确认好位宽关系避免浪费配置空间。握手信号的时序也要注意s_axis_divisor_tvalid和s_axis_dividend_tvalid理论上可以分别拉高但如果除数还没有准备好被除数就已经拉高了内部可能会产生无效的计算。实际使用时推荐的做法是将两个valid信号同步拉高保证被除数和除数成对进入IP核。2.4 除法器IP的资源占用估算从资源占用的角度来看PG151是一件非常透明的事情。Radix-2模式下每一个商位大约需要一个减法器和对应的比较逻辑所以资源会随着商位宽线性增长。实际上我更关心的不是LUT数量本身而是“商位宽”和“余数位宽”的拆分是否合理。举个例子如果被除数是32位除数是16位商最大也就是16位余数最多16位输出总线宽度就是32位。但如果你想后续继续用这个余数做多级除法余数位宽就只有16位精度接下来每一步都会损失精度。这时候往往需要把被除数先扩展成更高位宽比如48位再做第一级除法。这个操作在配置PG151时就要想清楚不要想着IP生成之后再改位宽改一次配置要重新综合一次很费时间。还有一点PG151的输出寄存器是可以“打拍”的但你加的输出级数越多资源占用越高。实际上我自己用得比较多的配置是“自动延迟”因为IP内部已经做了很好的流水线切分再加人工延迟一般只在对齐时序时才需要。3. 实操过程与核心环节实现从添加IP到仿真验证3.1 在Vivado中创建和配置Divider Generator打开Vivado在IP Catalog里搜索“Divider”能看到名为“Divider Generator”的IP对应版本不同Product Guide都是PG151。双击进入配置界面后有几个标签页第一页主要设置位宽和算法类型。我说一下我自己习惯的配置流程。假如我现在要做一个24位无符号整数除以12位无符号整数的模块商和余数都保留我会做如下设置算法类型Radix-2被除数宽度24位除数宽度12位商宽度12位余数宽度12位操作数类型无符号延迟自动输出流水级默认即可。这几个参数配置完之后IP会显示预估的延迟拍数。比如Radix-2算法在这个位宽组合下延迟大概是24拍左右。这里有个经验值延迟拍数基本等于“商宽度”加两拍左右的寄存器开销你就按这个去估算你的数据对齐逻辑大概率不会出错。3.2 AXI4-Stream接口的时序对齐接下来是仿真时最容易出错的地方AXI4-Stream握手信号的时序。虽然PG151最基本的用法是tvalid拉高一个周期即可不需要用tready做反压因为IP核能持续接收但你在把数据送进去的时候一定要保证数据在tvalid拉高期间是稳定有效的。我见过很多人的仿真波形里tvalid拉高的那个沿tdata数据刚变化结果计算出来全错。这是因为AXI4-Stream协议要求数据在tvalid为高且tready为高的那个时钟上升沿被采样如果你是组合逻辑驱动tdata并且和tvalid同时变化很容易踩到亚稳态或者采到旧值。稳妥的做法是在发送端加一段寄存器把tvalid和tdata都打一拍之后送入IP。这样一来仿真波形和实际硬件行为就完全一致了也不会出现对齐问题。3.3 输出数据的解析与对齐输出数据的获取也比较容易踩坑。m_axis_dout_tvalid拉高时m_axis_dout_tdata上就是有效结果但你需要根据“商宽度”和“余数宽度”把数据拆开。我用一个例子来说明。假如商宽度12位余数宽度12位那么m_axis_dout_tdata总宽度是24位其中[23:12]是商[11:0]是余数。在代码里解析的时候一定不要写死成“高16位是商低16位是余数”一定要根据配置的位宽动态定义。我之前就是在一个模块里固定了[31:16]取商后来换了配置项忘记同步改代码结果除法的输出全部对不上。还有一点输出结果是带延迟的。从输入被除数和除数被采样的那个时钟开始算经过配置的延迟拍数之后m_axis_dout_tvalid才会拉高。在系统级联的时候你要保证下游逻辑不是用“输入送出后第N拍取结果”这种硬编码方式而是用m_axis_dout_tvalid来使能数据采集这样才能稳。3.4 仿真中的典型激励写法仿真的时候我习惯用任务task来封装一次除法操作。简单写一下思路task automatic do_div; input [23:0] dividend; input [11:0] divisor; begin (posedge aclk); s_axis_dividend_tvalid 1b1; s_axis_divisor_tvalid 1b1; s_axis_dividend_tdata dividend; s_axis_divisor_tdata divisor; (posedge aclk); s_axis_dividend_tvalid 1b0; s_axis_divisor_tvalid 1b0; end endtask这个写法相当于在第一个时钟沿送数据第二个时钟沿撤销valid。然后你在测试顶层里等待m_axis_dout_tvalid拉高再抓取m_axis_dout_tdata解析商和余数。用这个办法连续做几十组随机数比对基本上功能和时序问题都能暴露出来。3.5 与手写模块的联调经验如果是把PG151嵌在一个大的数据通路里联调时最容易出问题的不是IP本身而是IP前后的数据宽度不匹配。比如上游模块输出的是32位被除数但你的IP配置的是24位直接把32位总线接到tdata上多余的高位会被截掉结果完全不对。正确做法是在IP前面加一个位宽转换模块或者直接在配置时把被除数宽度设为32位然后通过控制有效数据来保证实际运算的数据不超过除数位宽能够承载的商范围。另外要注意的是PG151在某些Vivado版本里会自动插入寄存器来改善布局布线导致实际延迟和你配置的理论延迟存在差异。这时候不要慌拿仿真波形数一数aclk上升沿到m_axis_dout_tvalid拉高之间到底差了几拍以实际仿真为准。4. 常见问题与排查技巧实录4.1 输出商和余数颠倒了这个我上面提到过但真的太容易犯了单独拉出来再说一次。PG151输出总线的拼接顺序是“商在高位余数在低位”而且这个高位低位是相对于“总位宽”来算的。举例说明配置商宽度16位、余数宽度8位总位宽24位那么m_axis_dout_tdata[23:8]是商[7:0]是余数。而不是简单地“高一半是商、低一半是余数”。我见过有人把商和余数宽度配成相同数值然后就不在乎顺序了其实如果后面代码里改了位宽配置顺序逻辑就崩了。最好从开始就按照“商在高位、余数在低位”的方式来解析别偷懒。4.2 除数为0导致结果乱跳除数为0是除法器绕不开的问题。PG151本身不会报错也不会帮你把结果置成一个固定值它的输出就是按照算法跑到头的某个结果。如果你在系统里无法保证除数永远不为0那就一定要在IP前面加一个保护逻辑检测到除数为0时直接把商置为全1或者某个约定值同时把余数额外标记出来。这个保护逻辑务必要在数据进入IP之前完成而不是在输出端做筛选。因为除数为0时IP内部的计算过程已经乱掉了输出结果可能完全不可预测你要是把它跟其他结果混在一起做后续运算问题排查起来非常头疼。4.3 时序违例集中在IP输出路径如果做时序分析时发现关键路径就在PG151的输出级附近通常有两个原因一个是IP的输出直接连到了大片组合逻辑上另一个是IP本身选的算法类型和你的时钟频率不匹配。我自己遇到过一个比较尴尬的场景在Artix-7上跑200MHz用Radix-2做32位除法延迟35拍左右时序刚好能过。后来换了一颗资源更小的芯片同样配置时序就挂了。排查之后发现是输出级后面的组合逻辑路径太长并不是IP本身的问题。解决办法是给IP输出再加一级寄存器把时序路径切断或者把配置里的“输出额外流水级”打开。这里有一个核心原则除法器的输出打一拍不改变功能但对时序收敛帮助巨大。建议所有用到PG151的模块都在输出端加一级寄存器再做分发省得后面到处修时序。4.4 常见问题速查表问题现象可能原因解决方案商和余数结果完全错乱输出总线解析顺序反了检查商/余数位宽按高位商低位余数解析输出结果和手算不一致被除数或除数输入时序错误将valid和data同时打拍后送入IPvalid拉高延迟与预期不符手动配置了额外延迟拍数以仿真波形实测延迟为准不要依赖理论值除数为0时结果不稳定IP不提供除零保护在IP前端加除零检测和结果替代逻辑时序违例出现在IP附近输出组合逻辑路径过长输出端增加寄存器打拍或增加流水级资源占用比预期大很多商位宽或余数位宽配置过大按实际有效位宽重新配置移除多余高位4.5 多路除法复用的小技巧如果系统里有多个除法计算点但数据吞吐率要求不高我不建议在每个点都例化一个PG151。更省资源的做法是做一个除法器资源共享模块把多路被除数、除数通过一个简单的轮询仲裁器送入同一个IP然后根据请求编号把结果分发回对应通道。这种做法在音频处理、低速控制逻辑里非常实用。只要总的数据吞吐率不超过IP极限资源能省不少。但要注意仲裁器的设计会引入额外的握手逻辑和延迟必须把“请求-响应”的时序关系理清楚否则很容易出现结果被别的通道截胡的情况。我自己在做8路数据除法复用时就是给每个通道增加了一个“忙标志”响应的结果里带上通道编号这样即使延迟不同也能准确分发。4.6 不同Vivado版本下的行为差异还有一个容易被忽略的点PG151在不同的Vivado版本里默认配置和延迟拍数可能略有不同。尤其是从Vivado 2019升级到2022之后某些IP核生成的RTL里输出寄存器的数量会变化。我遇到过的情况是原来在Vivado 2019.1里配置的延迟是25拍升级到2022.2之后同样的配置项却生成了28拍延迟。如果工程里其他地方是按照固定25拍来对齐数据的升级之后立刻出错。这个问题的解决办法只有一个就是在升级版本后重新跑一遍仿真确认每一路信号的延迟周期是否变化。5. 性能优化与实际工程中的扩展用法5.1 用延迟换吞吐率的技巧在某些数据流式处理的场景里你并不需要一个除法器反复计算而是需要多个除法器并行处理多路数据。PG151本身支持通过“吞吐率优化”模式来缩短数据输出的间隔让每个时钟周期都能送入一组新的被除数和除数。有一种配置叫“非阻塞”Non-blocking模式它允许你在上一次除法还没出结果时就送入下一组数据。内部靠流水线寄存器把不同组的数据隔开。这个模式特别适合雷达信号处理、图像归一化这类吞吐率要求高的场景。唯一需要注意的还是延迟对齐虽然输入可以每个周期都送但输出结果的排布是严格按顺序来的必须确保下游不是按通道错位采样。5.2 使用多周期除法来降低资源消耗反过来如果资源极其紧张而你对实时性要求不高可以把PG151配置成“低资源”模式也就是每次只处理一组数据内部尽可能复用减法器逻辑。这种模式下延迟可能很高但LUT消耗可以压到极低。我之前在一款很小规模的CPLD应用里试过类似思路虽然最终因为CPLD不支持这个IP而改成了手写移位相减的模块但原理是相通的吞吐率换资源。如果你对FPGA的资源占用极度敏感PG151的“面积优化”选项值得一试。5.3 和DSP48原语结合实现更复杂的计算PG151本身不用DSP48它主要消耗LUT和寄存器。但你可以把除法器的输出直接连接到DSP48的输入上实现“归一化后乘系数”这种复合运算。不过要记住DSP48的输入寄存器通常有时序要求最好在除法器输出和DSP48之间加一级打拍寄存器。这类复合运算在做坐标变换、FFT归一化时非常常见。比如做OFDM解调时需要对每个子载波做信道均衡本质上就是一个复除法复乘法的组合。用PG151实现除法部分用DSP48实现乘法部分分工明确性能也容易做高。5.4 IP的重新生成与时序回归最后提醒一句Vivado里任何IP的参数改动都会导致IP核需要重新生成输出文件。这个重新生成过程不是简单的增量更新它会重新生成整个RTL和仿真模型所以一定要在重生成之后重新跑一遍相关仿真用例而不是只关注你改动的那个参数。我之前吃过一次亏只是把余数宽度从12位改成了16位尝试性地改完就继续综合结果在板级调试时发现输出数据解析错位。原因就是余数宽度变了输出总线和拼接位置都变了而我下游解析代码没有同步更新。这个教训告诉我改IP参数不要只想着生成一定要连带把上下游代码检查一遍。6. 基于个人经验的几条实在建议总结一下我自己在实际项目里用PG151的体会不一定全对但都是踩过坑换来的。第一除非你的除法操作非常少否则永远不要用“/”运算符合成硬件逻辑。不是你写不好而是时序不可控的代价在复杂工程里会被无限放大。第二不管IP配置看起来多简单务必写一个专门针对除法器的随机数测试平台每次改参数后都回归跑一遍。不要觉得麻烦这比你在板级调试时抓破脑袋强一百倍。第三用IP的时候一定要看对应版本的产品指南也就是PG151。不同版本之间接口时序和默认配置都存在差异纸上谈兵不如翻手册。虽然这篇笔记已经把核心要点梳理了一遍但真正动手配置时还是建议以官方手册和实际生成的RTL为准。第四除法器是整个数据通路里最容易被忽略时序的位置而它一旦出问题就表现为“偶尔错一个数”这种极其难查的bug。所以给它单独加一级输出寄存器、把valid信号打拍、再和下游做好握手这些看起来多此一举的操作关键时刻能救你一命。最后再分享一个小技巧如果你在调时序的时候发现除法器IP的输出延迟总是和你手算的差一拍不妨去检查一下IP配置里的“输出寄存器”选项把它关掉看看延迟是不是就符合预期了。这个选项的存在就是为了让你在时序和延迟之间做取舍但它默认开启很容易让人误解延迟计算规则。