简介：「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 = 1'b0; // 使能无效时输出固定 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{1'b0}}; // 清零和移位在同一时钟沿 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 == 2'd0) y = d0; else if (sel == 2'd1) y = d1; else if (sel == 2'd2) y = d2; else y = d3; end // 并行结构：case 语句，综合为一级多路选择器 always @(*) begin case (sel) 2'd0: y = d0; 2'd1: y = d1; 2'd2: y = d2; default: y = d3; // 必须写 default，防止综合出锁存器 endcase end逻辑说明：两段代码功能完全等价，但综合结果不同。if-else 版本在输入选择信号到来后要逐级判断，路径延迟随分支数增加；case 版本是并行比较，延迟基本恒定。参数上要注意 case 必须写 default，否则当 sel 出现未列举值时综合工具会推断出锁存器来保持原值，这是新手最常遇到的异常之一。我一般会在综合后看时序报告里的逻辑级数，同一功能两种写法差一到两级是常见情况，频率要求高的路径上这个差别不能忽略。
3.2 用数学拆分降低乘法器资源占用
32 位乘 32 位的乘法器直接调用 IP 核会吃掉大量 DSP 资源，材料里给的思路是把大乘法拆成小乘法：X 拆成高 16 位 X1 和低 16 位 X2，Y 同理，于是 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 = {32'b0, p0} + ({p1 + p2, 16'b0}) + ({p3, 32'b0}); 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 <= 2'b00; // 异步拉低立即生效 else sync_ff <= {sync_ff[0], 1'b1}; // 两级同步后释放 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 乒乓操作的组织方式
乒乓操作的本质是用两组缓冲交替工作，让数据搬运和数据处理重叠起来。材料里的场景是烧写 eMMC：A 通道数据发往芯片并等待应答时，上位机往 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 = 1'b0; // 写侧：根据 sel 把数据灌入 A 或 B wire wr_a = wr_en & ~sel & ~wr_full_a; wire wr_b = wr_en & sel & ~wr_full_b; // 读侧：与写侧反相，A 写时读 B，B 写时读 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 ? 8'h00 : 8'h00; // 实际工程按 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 补 default，if 补 else，或者在 always 块开头给输出赋默认值。这条规则没有例外，我一般把它写进代码检查清单，综合前先搜一遍 latch 关键字。
5.2 跨时钟域信号没同步
现象：单板调试时功能时好时坏，复位一次能跑一阵，温度变化或重新上电后又不正常。原因：不同时钟域之间的单比特控制信号直接相连，采样时刻落在跳变沿附近产生亚稳态。解决：单比特信号打两拍同步，多比特数据用异步 FIFO 或者握手加保持，绝不允许多比特信号各自打拍。仿真里这类问题常常看不出来，必须靠代码评审和跨域检查工具兜底。
5.3 时序约束漏写导致 slack 虚高
现象：时序报告全绿，上板跑高频时数据错乱。原因：PLL 输出时钟、生成时钟、输入输出延迟没有在约束文件里声明，工具按默认值分析，报出来的 slack 没有参考意义。解决：每个时钟源都写 create_clock，PLL 输出写 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 快得多，而且能保证回归测试覆盖到之前踩过的边界。从那以后我每次改完代码，都会强制走一遍“仿真、综合检查、时序报告、日志归档”这四步，一步不跳。希望这些拆解能帮到你，把这份经验谈里的每一条都变成自己手上的动作。
本文还有配套的精品资源，点击获取
