简介「FPGA设计经验谈」是面向FPGA初学者与进阶开发者的经验总结文档作者有十余年开发经历聚焦实际设计中容易走弯路的环节帮助读者建立硬件思维。文中从「看代码、建模型」讲起说明如何由Verilog代码反推功能电路理解顺序执行与并行执行语言的设计差异再分析组合逻辑中if…else…与case语句对综合后并行度和延时路径的影响并给出用数学思维简化设计的实例如把32bit×32bit乘法拆成四个16bit×16bit乘法与三次32bit加法以节省资源。文档还讨论时钟与触发器的关系、IP核复用和乒乓操作等提速技巧并穿插eMMC控制器烧写项目的实践过程可作为入门后的经验补充与自查清单。压缩包仅含1个doc文件约107KB篇幅紧凑、无冗余附件目前已有1857人学习下载适合利用碎片时间通读。1. 从一份十年的 FPGA 设计经验谈说起为什么先建模型再写代码很多新手拿到 FPGA 开发板后做的第一件事是安装工具、点亮流水灯然后把 Verilog 当成 C 语言来写用 for 循环拼出计数器结果综合报告里充斥着意料之外的锁存器和超长的组合路径。这份《FPGA 设计经验谈》的价值就在于此它没有一上来就讲语法而是从“看代码、建模型”讲起把 Verilog 代码与底层电路结构对应起来再顺着组合逻辑写法、数学化简、时钟与触发器、IP 核与乒乓操作这几个点往下展开。它适合刚接触 FPGA 设计、能读懂基本语法但对“代码如何映射成电路”缺乏概念的从业者也适合做了两三年、想回头补齐组合逻辑延迟和时序控制这类基本功的人。整份材料更像一份实战笔记而不是语法手册下面我按照自己的复现流程把里面的每个经验点拆成可以直接照着做的步骤。2. 看代码建模型把 Verilog 语句还原成电路结构2.1 为什么先建模型顺序思维和并行思维的差别软件工程师转 FPGA 最容易犯的错误就是把 always 块当成函数的执行体来理解。C 语言里语句按顺序一条条执行而 Verilog 里的赋值语句描述的是器件之间的连线和触发器之间的状态传递always 块内部的语句顺序只影响仿真器在同一个时间步内的求值顺序综合工具最终会把它还原成一张电路网表。如果脑子里没有这张电路图写出来的代码能不能综合、综合成什么样、时钟沿到达时信号会怎样变化就完全不清楚了。材料里反复强调“看代码、建模型”本质上就是在训练一种能力读一行 Verilog脑子里立刻浮现出对应的门级或寄存器级结构。这种能力不是天赋是可以靠固定训练路径练出来的。我自己的做法是每读一段代码就手画一次电路画完之后再和综合工具输出的 RTL 原理图对照对不上就说明理解有偏差。2.2 两个基础电路的建模训练材料里给了两个经典例子一个是带使能端的二选一数据选择器一个是带同步清零的串并转换移位寄存器。这两个电路虽然简单但覆盖了组合逻辑和时序逻辑两大类值得反复练习到条件反射。// 带使能端的 2 选 1 数据选择器组合逻辑纯连线 module mux2_en ( input wire a, b, en, output reg y ); always (*) begin if (!en) y 1b0; // 使能无效时输出固定 0 else y a ? b : a; // en 有效时按选择端取值 end endmodule// 带同步清零端的串并转换移位寄存器时序逻辑由时钟驱动 module shift_sync_clear #( parameter WIDTH 8 // 位宽可配改参数即改电路规模 )( input wire clk, input wire rst_n, // 低有效同步清零 input wire din, output wire [WIDTH-1:0] dout ); reg [WIDTH-1:0] shift_reg; always (posedge clk) begin if (!rst_n) shift_reg {WIDTH{1b0}}; // 清零和移位在同一时钟沿 else shift_reg {shift_reg[WIDTH-2:0], din}; end assign dout shift_reg; endmodule这两段代码的逻辑说明要落在“映射成了什么”上而不是“实现了什么功能”。第一段综合出来就是一个 LUT 加上使能控制没有寄存器延迟只有一级组合逻辑第二段综合出来是 WIDTH 个 D 触发器串联每个触发器共享同一个 clk 和 rst_n数据每来一个时钟沿往右挪一位。在参数上WIDTH 直接决定触发器数量和布线资源8 位和 64 位的资源差距是线性的rst_n 写成同步清零意味着复位信号不需要走全局复位网络但在上电初始状态不确定的场景下要多加留意。我一般会把这两段代码分别综合一遍打开 RTL Viewer 截图存档后面读更复杂的代码时拿来做参照。2.3 建模型的固定训练流程光看例子不够要形成习惯。我用的流程是固定的四步第一步拿到一段代码先不看功能注释自己逐行标注哪些是组合逻辑、哪些是时序逻辑第二步在纸上画出模块框图和内部寄存器第三步跑一次综合打开 RTL 或 Technology Map 视图对照第四步把差异记下来尤其是综合工具把 if-else 优化成了什么结构。这套流程跑上二三十段代码之后再看到 always (posedge clk) 就知道后面跟的是一组触发器看到 assign 就知道是一根线或者一个 LUT看到 case 就知道是多路选择器。到这一步Verilog 就不再是需要背诵的语法而是一组可以随手拼搭的电路积木。3. 组合逻辑写法与数学化简case 与 if-else 的取舍及乘法器降资源3.1 case 与 if-else 综合出的电路差异材料里提到多输入组合逻辑应尽量用 case 而不是 if-else理由是并行度大、时延路径短。这句话要落到实际电路上才好理解if-else 链在综合时会被展开成级联的优先选择结构第一个条件的判断结果要喂给第二个第二个再喂给第三个输入越多串联级数越多case 语句在无优先级要求时会被综合成并行的多路选择器所有分支同时比较输出只经过一级选择。// 串行结构if-else 链4 个输入形成 4 级优先判断 always (*) begin if (sel 2d0) y d0; else if (sel 2d1) y d1; else if (sel 2d2) y d2; else y d3; end // 并行结构case 语句综合为一级多路选择器 always (*) begin case (sel) 2d0: y d0; 2d1: y d1; 2d2: y d2; default: y d3; // 必须写 default防止综合出锁存器 endcase end逻辑说明两段代码功能完全等价但综合结果不同。if-else 版本在输入选择信号到来后要逐级判断路径延迟随分支数增加case 版本是并行比较延迟基本恒定。参数上要注意 case 必须写 default否则当 sel 出现未列举值时综合工具会推断出锁存器来保持原值这是新手最常遇到的异常之一。我一般会在综合后看时序报告里的逻辑级数同一功能两种写法差一到两级是常见情况频率要求高的路径上这个差别不能忽略。3.2 用数学拆分降低乘法器资源占用32 位乘 32 位的乘法器直接调用 IP 核会吃掉大量 DSP 资源材料里给的思路是把大乘法拆成小乘法X 拆成高 16 位 X1 和低 16 位 X2Y 同理于是 XY 变成 X1Y1、X1Y2、X2Y1、X2*Y2 四个 16 位乘法和三次移位加法。// 32bit x 32bit 拆分为 4 个 16bit 乘法 3 次加法 module mul32_split ( input wire [31:0] x, input wire [31:0] y, output wire [63:0] p ); wire [15:0] x1 x[31:16], x2 x[15:0]; wire [15:0] y1 y[31:16], y2 y[15:0]; wire [31:0] p0 x2 * y2; // 低 16 位相乘权重 2^0 wire [31:0] p1 x2 * y1; // 交叉项权重 2^16 wire [31:0] p2 x1 * y2; // 交叉项权重 2^16 wire [31:0] p3 x1 * y1; // 高 16 位相乘权重 2^32 // 交叉项先合并再移位减少一次加法器 assign p {32b0, p0} ({p1 p2, 16b0}) ({p3, 32b0}); endmodule逻辑说明这里的关键不是“拆开做乘法”这件事本身而是权重对齐。p0 是最低位直接放低 32 位p1 和 p2 权重都是 2^16可以先相加再整体左移 16 位省掉一个加法器p3 权重是 2^32放到高 32 位。参数上要注意位宽两个 16 位数相乘结果是 32 位不会溢出但三个 32 位部分积相加要留足 64 位否则高位会被截断。这个方法只在乘法器数量紧张、且对延迟不敏感时才划算因为拆分后的路径变长频率会掉。我一般会先用 IP 核跑一版综合看资源占用只有在 DSP 或 LUT 明显不够时才换成拆分写法并且一定重新看时序报告确认没掉出约束。3.3 写法选择的判断依据这两种优化的共同判断依据是“先看资源报告再定写法”。组合逻辑写法影响的是延迟乘法拆分影响的是资源两者都会牵动时序。我的习惯是每改一版就记录三个数字LUT 用量、DSP 用量、最差路径 slack。没有这三个数字支撑的“优化”基本都是凭感觉很容易改完发现频率掉了一截或者资源没省多少。4. 时钟、触发器与 IP 核时序控制和乒乓操作的落地细节4.1 时钟作为控制者触发器行为要盯住的三件事材料里把时钟比作心脏、把触发器比作细胞这个比喻的核心意思是所有状态变化都发生在时钟沿上。落地到代码和约束层面有三件事必须盯住。第一是时钟域数量跨域信号如果没有同步器仿真可能过、上板必挂这是血泪经验里出现频率最高的一类。第二是时钟质量和约束PLL 输出的时钟要在约束文件里正确声明频率和相位否则时序分析给出的 slack 是假的。第三是异步复位与同步复位的选择异步复位释放时刻如果离时钟沿太近触发器可能进入亚稳态常见做法是加复位同步器把释放沿对齐到时钟域内。// 异步复位、同步释放复位信号释放沿对齐到 clk 域 module rst_sync ( input wire clk, input wire rst_async_n, output wire rst_sync_n ); reg [1:0] sync_ff; always (posedge clk or negedge rst_async_n) begin if (!rst_async_n) sync_ff 2b00; // 异步拉低立即生效 else sync_ff {sync_ff[0], 1b1}; // 两级同步后释放 end assign rst_sync_n sync_ff[1]; endmodule逻辑说明复位拉低时触发器立即清零保证上电即进入确定状态复位释放时经过两级触发器打拍把释放沿推到时钟沿之后避免亚稳态。参数上两级是最低要求时钟频率高或者噪声环境差的板子可以加到三级代价是复位释放延迟增加两个时钟周期功能上一般无所谓。我一般的做法是全局复位统一走这个模块模块内部不再各自处理异步复位减少跨域隐患。4.2 能用 IP 核就不要自己造材料里有一段 eMMC 烧写的故事很有代表性作者起初想自己设计一个带 CRC 计算的 RAM 或 FIFO 来暂存整页数据反复调试传输都不稳定最后改用工具自带的 FIFO 核把 CRC 计算和 512 字节缓存拆成两个模块问题就消掉了。这个结论在实际项目里屡试不爽FIFO、RAM、乘法器、CRC、PLL 这些基础单元厂商提供的 IP 核已经做过时序收敛和跨器件验证自己手写省不下多少资源却要承担大量边界情况的调试成本。判断标准我总结成三条功能是标准化的、时序要求明确的、厂商工具里有对应核的一律用核只有核的功能不满足比如需要特殊的读写时序或非标准位宽拼接才考虑自己写而且写完要和 IP 核版本做对比综合确认资源和时序都不吃亏。调用 FIFO 核时参数要盯住位宽、深度、读写时钟是否异步、almost_full 和 almost_empty 阈值这几个参数直接决定后面乒乓操作能不能跑起来。4.3 乒乓操作的组织方式乒乓操作的本质是用两组缓冲交替工作让数据搬运和数据处理重叠起来。材料里的场景是烧写 eMMCA 通道数据发往芯片并等待应答时上位机往 B 通道写数据B 通道发送时再往 A 通道写。// 双 FIFO 乒乓写侧轮流灌入读侧轮流取出 module pingpong_fifo ( input wire wr_clk, rd_clk, input wire wr_en, rd_en, input wire [7:0] din, output wire [7:0] dout, output wire buf_sel // 当前读出缓冲标志供上层判断 ); wire wr_full_a, wr_full_b, rd_empty_a, rd_empty_b; reg sel 1b0; // 写侧根据 sel 把数据灌入 A 或 B wire wr_a wr_en ~sel ~wr_full_a; wire wr_b wr_en sel ~wr_full_b; // 读侧与写侧反相A 写时读 BB 写时读 A wire rd_a rd_en ~sel ~rd_empty_a; wire rd_b rd_en sel ~rd_empty_b; fifo_8x512 u_fifo_a ( .wr_clk(wr_clk), .rd_clk(rd_clk), .din(din), .wr_en(wr_a), .rd_en(rd_a), .dout(), .full(wr_full_a), .empty(rd_empty_a) ); fifo_8x512 u_fifo_b ( .wr_clk(wr_clk), .rd_clk(rd_clk), .din(din), .wr_en(wr_b), .rd_en(rd_b), .dout(), .full(wr_full_b), .empty(rd_empty_b) ); always (posedge wr_clk) begin if (wr_en (wr_full_a || wr_full_b)) sel ~sel; // 一满即切换 end assign buf_sel sel; assign dout sel ? 8h00 : 8h00; // 实际工程按 sel 选择对应 FIFO 输出 endmodule逻辑说明写侧根据 sel 决定写入哪个 FIFO读侧取反保证同一时刻一个在写一个在读sel 在任一 FIFO 写满时翻转形成交替。参数上 FIFO 深度要按一页数据量取整材料里是 512 字节加上 CRC 的 16 字节所以深度选 512 或 1024读写时钟如果是异步的必须用带独立读写时钟的 FIFO 核不能用同步 FIFO 硬套。代码里输出选择部分做了简化实际工程中要根据 buf_sel 用多路选择器把对应 FIFO 的 dout 送出并且读侧要配合 almost_empty 提前切换避免读空。乒乓操作能不能真正提速取决于两侧处理时间是否接近。如果读侧烧写加轮询等待远慢于写侧切换频率就由读侧决定写侧一直在等这时候要回头看 FIFO 深度是否够、切换阈值是否合理。我调试这类结构时习惯在仿真里打印两个 FIFO 的占用计数随时间的变化曲线一眼就能看出哪一侧是瓶颈。5. 避坑与排查五条踩过的坑和对应解法5.1 组合逻辑漏写 default 导致锁存器现象综合报告里出现 latch 警告功能仿真正常上板后输出偶尔保持旧值不变。原因case 或 if 没有覆盖所有输入组合综合工具推断出锁存器来保持原状态。解决case 补 defaultif 补 else或者在 always 块开头给输出赋默认值。这条规则没有例外我一般把它写进代码检查清单综合前先搜一遍 latch 关键字。5.2 跨时钟域信号没同步现象单板调试时功能时好时坏复位一次能跑一阵温度变化或重新上电后又不正常。原因不同时钟域之间的单比特控制信号直接相连采样时刻落在跳变沿附近产生亚稳态。解决单比特信号打两拍同步多比特数据用异步 FIFO 或者握手加保持绝不允许多比特信号各自打拍。仿真里这类问题常常看不出来必须靠代码评审和跨域检查工具兜底。5.3 时序约束漏写导致 slack 虚高现象时序报告全绿上板跑高频时数据错乱。原因PLL 输出时钟、生成时钟、输入输出延迟没有在约束文件里声明工具按默认值分析报出来的 slack 没有参考意义。解决每个时钟源都写 create_clockPLL 输出写 create_generated_clock接口按实际器件手册写 set_input_delay 和 set_output_delay。我的习惯是约束文件写完先跑一次 report_clocks确认时钟树和设计意图一致再往下做。5.4 自己造 IP 核的调试成本被低估现象手写 FIFO 或 CRC 模块在小数据量下正常数据量一上来就丢包或者校验错。原因边界条件满空判断、读写指针回绕、CRC 初值和位序没有覆盖全而这类单元恰恰是边界情况最多的。解决优先调用厂商 IP 核确实要自己写就先用随机激励做长时间仿真并且和 IP 核版本做同输入对比。材料里那个 eMMC 案例就是现成的教训。5.5 乒乓切换阈值拍脑袋定现象乒乓结构搭好了吞吐量却没提升甚至出现读空。原因切换阈值按“感觉”设没有按两侧处理速率算。解决先测出写侧和读侧各自的平均处理时间按较慢一侧反推 FIFO 深度和切换点仿真里画出占用计数曲线验证。这一步偷懒后面就要靠上板反复试时间成本高得多。6. 把经验变成可复用的检查动作仿真验证与日志习惯材料结尾提到多实践、多思考、多问还特意说如果有写项目日志的习惯更好。这句话我起初没当回事后来吃过亏才明白它的分量。现在我把每次设计拆成固定的验证动作代码写完先跑功能仿真重点看复位释放后的前几个时钟和边界输入综合后对照 RTL 图检查有没有意外的锁存器和多余的逻辑级数布局布线后看时序报告的最差路径确认关键路径和自己预判的一致上板后用逻辑分析仪抓关键信号尤其是跨域握手和 FIFO 的空满标志。# 综合后固定检查锁存器、逻辑级数、最差 slack report_design_rules -checks {latch loop} report_timing -max_paths 10 -nworst 1 -delay_type max report_utilization -hierarchical这段脚本是我每版必跑的三条命令分别对应三类问题设计规则检查抓锁存器和组合环时序报告抓最差路径资源报告抓用量突变。参数上 -max_paths 10 是为了看清楚最差的十条路径而不是只看一条-hierarchical 是为了定位到具体模块。跑完把输出存档到项目日志里和上一版对比资源或时序出现跳变就回头查这一版改了什么。日志的写法也有讲究我一般记四栏现象、原因、解决办法、下次怎么提前发现。比如“综合出现 latch 警告”这一条原因栏写“case 未写 default”解决栏写“补 default”下次怎么提前发现那一栏写“综合前搜 latch 关键字加代码评审”。四栏填满的条目才有复用价值只记现象不记原因的日志过两个月自己都看不懂。还有一点是仿真激励的积累。我会把每个模块用过的测试激励单独存成文件按模块名加日期命名下次改同一个模块直接拿来改。这种做法看着笨但比每次从零写 testbench 快得多而且能保证回归测试覆盖到之前踩过的边界。从那以后我每次改完代码都会强制走一遍“仿真、综合检查、时序报告、日志归档”这四步一步不跳。希望这些拆解能帮到你把这份经验谈里的每一条都变成自己手上的动作。本文还有配套的精品资源点击获取
