接手“SPI通信FPGA实现”这个题目的时候，我其实犹豫了一下。市面上讲SPI协议的文章一抓一大把，但大多数要么停在PPT时序图层面，要么只给一段演示性质的Verilog代码，离真正能在板子上跑起来、跟外部器件稳定通信还有一段距离。这篇博文我想换个写法：不止讲SPI是什么、时序怎么对，更想把从协议理解、代码架构、仿真验证到板级调试这条完整链路串起来，把我实际项目中踩过的坑和总结的经验一起放进去，给正在用FPGA做SPI接口的开发者一份能直接参考的实战笔记。
1. SPI协议里最容易忽略的三个细节
先说协议本身。很多人觉得SPI简单，四条线而已，MISO、MOSI、SCK、CS，主从一接就能通信。但真正动手用FPGA实现时，有三个细节会反复困扰你，而且这些恰恰是网上教程讲得最少的部分。
1.1 四种工作模式不是死记硬背，而是由采样沿和空闲电平共同决定的
SPI的四种模式由CPOL（时钟极性）和CPHA（时钟相位）两个参数组合而来。CPOL决定SCK空闲时的电平，CPHA决定数据是在SCK上升沿还是下降沿被采样。很多人把这四个模式背下来了，但一到写代码就懵，原因在于没有理解一个本质问题：发送端和接收端必须约定好在哪个沿更新数据、哪个沿采样数据。
从FPGA实现的角度，我习惯用一句话来记：采样沿必须落在数据稳定的中间区域。比如模式0（CPOL=0，CPHA=0），SCK空闲为低，第一个沿（上升沿）采样数据。这意味着发送端必须在上升沿到来之前把数据准备好，通常在下降沿更新数据，这样数据有半个时钟周期稳定时间供接收端采样。
在代码层面，CLK分频产生SCK后，发送和接收逻辑需要分别用不同的沿触发。很多初学者把发送和接收都写在同一个always块里，用同一个沿触发，结果总在调试时发现数据对不上。这里有一个我验证过的经验：发送逻辑用SCK的下降沿，接收逻辑用SCK的上升沿（模式0），这样时序裕量最大，也最不容易出问题。
1.2 从设备驱动MISO的时序约束，是丢数据的隐形杀手
主设备向从设备发送数据是MOSI线上的事，大家都会关注。但从设备向主设备返回数据走的是MISO线，这条线上的时序约束常常被忽略。实际项目中，很多从设备芯片对MISO数据的驱动沿有明确要求，例如要求主设备在SCK的某个沿之后才能采样，否则数据还没稳定就被采走了。
用FPGA做主机时，MISO采样点需要留足裕量。我习惯的做法是：如果系统时钟远高于SCK（例如50MHz系统时钟驱动10MHz SCK），可以在SCK采样沿基础上再延时半个系统时钟周期采样MISO。这样虽然牺牲了一点最高SCK频率，但换来的是对不同从设备芯片更好的兼容性。对于ADC、DAC、Flash这类常见外设，这个做法几乎能通吃。
1.3 片选信号的低电平有效与高阻态管理
CS（片选）信号大部分情况下是低电平有效，但这背后牵扯到总线释放的问题。当CS拉高时，从设备的MISO引脚必须释放总线，回到高阻态，否则多个从设备挂在同一条MISO线上就会互相打架。FPGA实现中，主机的MISO输入在CS释放期间应该处于高阻态输入模式，并视需要加上下拉电阻防止浮空。
这个细节在和多个SPI从设备共用一个接口时尤为关键。最开始我做多从设备共享SPI总线时，只把各从设备的CS分开控制，MISO直连，结果发现通信偶发错误，排查了很久。后来用示波器抓MISO线，发现CS释放期间线上有毛刺，是某个从设备没完全释放总线导致的，才意识到高阻态管理的重要性。
2. FPGA实现SPI Master的架构设计与代码编写
协议理解到位之后，真正的挑战在于如何把协议翻译成可综合的硬件逻辑。这一节我以设计一个可配置的SPI Master模块为例，把各部分的设计思路掰开揉碎了讲。
2.1 顶层模块的端口定义与参数化设计思路
我认为一个好的SPI Master模块，应该做到三个可配置：SCK频率可配置、数据位宽可配置、工作模式可配置。对应到Verilog代码中，就是模块参数和寄存器配置的组合。
顶层端口方面，除了标准的时钟和复位，与外部交互的核心端口可以这样定义：
module spi_master #( parameter DATA_WIDTH = 8, parameter DIVIDER_WIDTH = 16 )( input wire clk, input wire rst_n, // CPU/微控制器侧接口 input wire start, input wire [DATA_WIDTH-1:0] tx_data, output reg [DATA_WIDTH-1:0] rx_data, output reg busy, // SPI物理接口 output reg sclk, output reg cs_n, output reg mosi, input wire miso );参数化设计有一个显而易见的好处：同一个模块可以适配不同位宽的从设备。比如驱动8位的SPI Flash用8位模式，驱动24位的ADC配置寄存器用24位模式，模块复用性大大提升。
2.2 系统时钟分频产生SCK，并保证占空比稳定
分频是SPI Master里最简单的部分，却是最影响通信质量的部分。从50MHz系统时钟分频出10MHz SCK，就是除以5，但在实现时要注意占空比。奇数分频如果处理不当会产生不对称的SCK波形，虽然很多从设备也能容忍一定范围的占空比偏差，但不对称会导致数据采样裕量不均匀，一个方向裕量变差。
我的做法是使用计数器同时控制高低电平持续时间，偶数分频自然对称，奇数分频时高电平保持(N+1)/2个周期，低电平保持(N-1)/2个周期。这样能保证SCK高低电平基本对称，实测下来这些许的占空比优化能明显降低高速通信时的误码率。
reg [DIVIDER_WIDTH-1:0] div_cnt; reg sclk_en; wire div_done = (div_cnt >= (CLK_DIV/2 - 1)); always @(posedge clk or negedge rst_n) begin if (!rst_n) begin div_cnt <= 0; sclk_en <= 0; end else if (div_done) begin div_cnt <= 0; sclk_en <= ~sclk_en; // 翻转使能信号 end else begin div_cnt <= div_cnt + 1'b1; end end注意这里我用sclk_en而不是直接驱动sclk输出。原因是SCK需要由系统时钟同步产生，直接用sclk_en门控或分频，可以在系统时钟域内逻辑处理数据沿变化，避免用SCK作为敏感信号触发跨越时钟域的逻辑，这能显著降低跨时钟域亚稳态的风险。
2.3 发送与接收逻辑：移位寄存器的双沿使用技巧
发送和接收的本质都是移位操作。MOSI线上，发送数据按位从高位到低位依次送出；MISO线上，接收数据按位依次移入。两者的同步控制都在SCK的沿上完成。
发送逻辑的关键在于数据准备时机。以模式0为例，SCK空闲为低，第一个上升沿采样数据，所以发送数据必须在上升沿之前准备好。我习惯在SCK下降沿（即上一个数据位的后半段）更新下一个待发送位，数据从移位寄存器最高位移出，然后在SCK上升沿被从设备采样。
接收逻辑则更考验细节。从设备在SCK下降沿更新MISO数据，主设备需要在SCK上升沿采样。但如果把采样动作和接收移位写在同一个沿，数据可能还没稳定。稳妥的写法是：在SCK下降沿记录MISO的电平，在SCK上升沿把它移入接收寄存器。不过这样对从设备输出延时要求比较严格，更通用的做法是前面说过的在采样沿基础上加半个系统时钟周期延时。
2.4 状态机设计：从IDLE到传输完成的状态跳转与busy信号管理
SPI Master的核心控制逻辑是一个状态机，典型的状态划分是IDLE、TRANSFER、DONE三个阶段。
IDLE状态等待start信号。start拉高后，锁存发送数据，拉低CS，进入TRANSFER状态。TRANSFER状态下产生指定数量的SCK时钟，每个SCK周期完成一位数据的发送和接收。位计数器到达设定值时，拉高CS，置位busy信号，在DONE状态保持一个周期供外部读取接收数据。
busy信号的管理有个实际项目中的体会：外部控制器发送start后必须等待busy拉低才能发起下一次传输，否则会覆盖正在传输的数据。很多初学者忽略了这一点，连续发送两次start，第二次开始前数据早已被破坏。我在模块内部加了busy保护，在busy有效时忽略start请求，这能大幅简化外部控制逻辑的时序要求。
核心状态机伪代码如下：
always @(posedge clk or negedge rst_n) begin if (!rst_n) begin state <= IDLE; end else begin case (state) IDLE: begin if (start && !busy) state <= TRANSFER; end TRANSFER: begin if (bit_cnt == DATA_WIDTH && sclk_falling_edge) state <= DONE; end DONE: begin state <= IDLE; end endcase end end3. 从代码到板上稳定运行的三个关键环节：仿真、验证和时序约束
写完代码只完成了三分之一的工作。SPI通信能不能稳定工作，还取决于仿真验证是否充分、板级调试方法是否得法、以及时序约束是否到位。
3.1 如何搭建一个实用的Testbench，验证各种边界情况
写testbench的本质是模拟一个从设备的行为，用来验证主设备逻辑是否正确。很多初学者只用一个简单的memory模型当从设备，测试正常传输后就算完事，结果在真实芯片上碰壁。我的建议是至少覆盖以下场景：
第一，正常读写的一致性验证。发送一组已知数据，模拟从设备返回同组数据，检查rx_data是否与预期一致。第二，从设备MISO延时驱动验证。在从设备模型中给MISO的更新加上不同的延时（0、半个SCK周期、一个SCK周期），观察主设备在不同采样策略下的表现，这能帮你评估自己的采样裕量。第三，连续传输的背靠背压力测试，验证busy信号与CS时序的正确性。
一个实用的MISO延时注入写法是：
// 模拟从设备在SCK下降沿后5ns才驱动MISO always @(negedge sclk) begin #5 miso <= mem[shift_idx]; end加上这个5ns的延时后，如果你的接收逻辑仍然能正确采到数据，那么在主频更高的板子上运行就更有底气。
3.2 用ILA抓信号与逻辑分析仪配合，定位实际通信故障
仿真过了不代表板上能跑。上板调试时，我用得最顺手的组合是Xilinx的ILA（集成逻辑分析仪）加外置逻辑分析仪双通道验证。ILA用来观察FPGA内部的rx_data、bit_cnt、state等信号，外置逻辑分析仪用来抓真实的SCK、MOSI、MISO、CS波形。
这里有一个典型的调试案例。有一次调试SPI Flash读取ID，ILA里看到的rx_data完全不对，但波形显示SCK和MOSI都正常。用外置逻辑分析仪抓MISO才发现，Flash驱动MISO的信号比SCK下降沿晚了近半个时钟周期，而我的采样逻辑在下降沿之后立即采样MISO，刚好采在了数据切换的毛刺上。后来把采样点调整到下降沿之后固定延时，问题立刻解决。这类问题仿真阶段如果不加延时模型很难暴露，所以板级调试经验非常宝贵。
3.3 时序约束的写法与跨时钟域处理
SPI接口的时序约束分两部分：SCK/MOSI/CS这些输出引脚与系统时钟的关系约束，以及MISO输入引脚的约束。如果不对这些引脚做约束，工具在布局布线时可能随意摆放，导致输出引脚间延时不一致，高速通信时信号间偏斜过大。
对于Xilinx 7系列，常用create_generated_clock定义SCK，再用set_output_delay约束MOSI和CS。MISO侧用set_input_delay约束。更简单的做法是使用set_max_delay和set_min_delay对引脚间的相对延时做约束。如果你的系统时钟和SCK同源，且SCK频率不超过系统时钟的四分之一，这些约束不会太紧张。
跨时钟域方面，SPI本身是同步串行协议，只要SCK和系统时钟同源，就属于分频时钟域，不属于异步时钟域。这种情况下重点确保分频逻辑在系统时钟域内同步产生，而不是用SCK去抓取系统时钟域的信号。我的代码中所有状态机和数据寄存器都用系统时钟驱动，只在SCK使能信号有效时更新数据，这样就避免了跨时钟域问题。
4. SPI硬件片选与软件片选之争：从事实上分析，以及和I2C的对比
我在项目群里经常看到有人在问SPI硬件片选和软件片选怎么选，以及SPI和I2C到底哪个好。这两个问题放到实际项目中，其实都有非常明确的答案。
4.1 硬件片选与软件片选的适用场景
硬件片选指CS信号由主控制器的专用硬件引脚直接控制，通常由SPI控制器的配置寄存器自动拉低或拉高。软件片选指CS用普通GPIO控制，由软件在SPI传输前后手动拉低、拉高。
FPGA实现中我建议优先使用软件片选，原因有三：一是时序控制更灵活，可以精确控制CS拉低后延时多久才产生SCK，满足从设备的tCSSU（CS建立时间）要求；二是避免硬件片选在多从设备切换时产生毛刺；三是可以灵活配置CS的有效电平，适配少数高电平有效的从设备。实际项目中，FPGA的SPI Master大多是自己用Verilog写的，所谓硬件片选也完全可以在模块内部实现，所以这个争论在FPGA领域基本不存在——关键在于CS信号要在系统时钟域内同步产生，避免在SCK的边沿附近翻转。
4.2 SPI和I2C的选择策略：速度优先还是引脚优先
SPI和I2C的区别可以用一张表说清楚：
| 特性 | SPI | I2C |
|---|---|---|
| 引脚数 | 4条（MISO/MOSI/SCK/CS） | 2条（SDA/SCL） |
| 最高速率 | 可达数十MHz至百MHz级 | 标准模式100kbps，高速模式3.4Mbps |
| 通信方式 | 全双工 | 半双工 |
| 寻址方式 | 片选信号独立选中 | 器件地址寻址 |
| 多主支持 | 不天然支持 | 支持多主仲裁 |
如果项目对速率敏感（比如驱动高分辨率ADC、SPI Flash、高速DAC），无脑选SPI。如果引脚紧张、速率要求不高、总线需要挂多个从设备且不想为每个设备分配CS引脚，I2C更合适。我个人在两个场景之间的取舍标准是：单从设备且速率要求高选SPI；多从设备但速率要求不高，并且想省引脚时选I2C。在FPGA项目里，SPI仍然是绝对主流，因为硬实时控制和高速数据采集场景太多了。
5. 实战经验：SPI读取ADC和SPI Flash的完整调试过程
想真正掌握SPI的FPGA实现，只看别人的代码是不够的，必须自己动手调一遍。这一节我以两个最常见的实战场景为例，分享完整的调试链路和关键心得。
5.1 驱动SPI接口ADC：采样时钟、数据对齐和连续采样实现
SPI接口的ADC在电机控制、电网监测、数据采集项目中非常常见。以16位ADC为例，通信流程是：主设备拉低CS，发送16个SCK时钟，同时从设备在MISO上按位返回16位转换结果。部分ADC还支持菊花链模式，可以在同一帧内读取多个通道。
实现时最容易出错的是数据对齐问题。有些ADC的转换结果数据在SCK的第一个下降沿就开始输出，有些则从第二个下降沿才开始，还有一些高位在前、低位在后。如果不对照数据手册确认位序，读出的数据即使位宽正确，数值也可能是错位的。
我踩过的坑是某款ADC在电源刚刚稳定时，第一次读取的转换结果固定是0x8000，看起来像是正常数据，实际上是芯片内部未完成初始化的特殊输出。解决办法是上电后丢弃前两次读取结果，或者对数据做合理性检查。这个问题在仿真阶段完全暴露不出来，因为仿真模型不会模拟上电初始化的时序。
连续采样实现方面，需要在一个转换周期内完成“发起转换-等待转换完成-读取结果”的闭环。我的做法是在每个SPI帧结束时直接拉低CS启动下一次转换，通过CS的下降沿触发从设备开始转换，然后延时等待转换完成后再发起读取帧，这样可以在不占用额外GPIO的情况下实现连续采样。
5.2 驱动SPI Flash：读ID、页编程和读数据操作的实际波形分析
SPI Flash是另一个最常见的SPI从设备。读JEDEC ID是调试时最先做的事，这个操作只有一条命令：发送0x9F，然后读取三字节设备ID。不要小看这一小步，它能验证SPI Master的四个关键行为：CS时序是否正确、MOSI数据是否按位发出、MISO数据是否能正确采回、以及时钟模式是否匹配。我每次新写一个SPI Master模块，上板第一件事就是读Flash ID，通过这个简单操作快速验证整条链路。
页编程操作比读操作复杂很多，涉及命令发送、地址发送、数据发送和等待烧录完成四个阶段。Flash的写操作需要CS在整个过程中的低电平保持，中间任何一个意外的CS拉高都会导致写操作被取消。我第一次调页编程时，发现写完读回来全是0xFF，排查了很久才发现问题出在CS信号上：我的状态机在地址发送完成后有一个周期的空闲，把CS拉高了。
Flash的状态寄存器查询也值得一提。页编程和擦除操作都需要等待内部完成，通过读取状态寄存器的BUSY位判断是否结束。读取状态寄存器的命令是0x05，返回数据的bit0表示BUSY，为1时说明还在忙。这里有个典型错误：只发一次读状态命令就判断结果，实际上需要在CS拉低后持续发送SCK才能连续读取状态寄存器的值，或者重复发起“拉低CS-发命令-读数据-拉高CS”的循环直到BUSY位清零。
5.3 调试经验和教训：从波形异常到定位问题根因的全过程
分享一个完整的调试过程，帮读者建立一个排查思路。一次在调试SPI Flash擦除操作时，擦除后读取数据，发现只有前4K字节被擦除，后面的数据还是旧值。这是一块4MB的Flash，理论上擦除命令应该把整片数据都清成0xFF。
先用ILA抓内部信号，发现状态机停在“等待BUSY位清零”状态超时，反复读状态寄存器BUSY位一直为1。用外置逻辑分析仪抓波形，发现读状态寄存器的帧结构完全正常，但Flash始终返回BUSY。进一步分析才发现问题出在擦除命令本身：擦除命令需要发送命令码、24位地址和32字节的填充数据，而我的代码只发送了命令和地址就拉高了CS，Flash根本没有进入擦除流程。后续读状态时Flash内部处于异常状态，BUSY位一直拉高。
这个案例给了一个重要教训：SPI Flash的所有操作都必须严格按数据手册的命令格式来，少一个字节都可能导致器件进入未知状态。调试时要善于把大问题拆成小步骤验证：先验证命令发送，再验证地址发送，再验证数据发送，最后再验证返回值。
6. 从FPGA到其他平台的SPI实现思路迁移与常见疑问
SPI是一项通用总线技术，FPGA只是其中一种实现载体。在实际学习过程中，我发现很多人在掌握FPGA实现后，还想了解它和其他平台的关联。这里把常见的一些延伸问题和疑问一并梳理。
6.1 从STM32的CubeMX配置反推SPI时序理解
很多做FPGA的人也会接触STM32，CubeMX里SPI配置界面有SCK频率、CPOL/CPHA、数据帧格式、片选信号等参数，配置完成后生成的HAL代码会帮助你管理硬件外设。但通过CubeMX配置和理解FPGA实现有一个根本区别：STM32的SPI外设是硬件状态机，配置完参数以后不需要考虑底层时序细节；FPGA实现则要求你理解每个信号每个周期是怎么变化的。
我的建议是先用STM32这类成熟MCU的SPI外设建立感性认识，理解不同配置参数在实际波形上的表现，再回头写FPGA实现，你会突然明白很多之前一知半解的概念。反过来，如果你先在FPGA里实现了SPI Master，再去看CubeMX的配置界面，每个选项的意义就非常清楚了。
6.2 ST7789这类SPI屏幕的刷新率与时钟模式选择
驱动ST7789这类SPI屏幕在单片机项目里非常常见，FPGA也常用来驱动这类屏幕做图像显示。这类屏幕通常支持SPI模式，但有一个特性：数据位宽是以字节为单位传输的，且很多屏幕控制器同时支持SPI和QSPI（四线SPI）模式。
屏幕上最影响体验的指标是刷新率，刷新率和SPI时钟频率直接相关。假设一个240x320分辨率、16位色深的屏幕，一帧数据量为240x320x16=1,228,800比特。如果用10MHz SPI，刷新率只有约8Hz，肉眼可见的卡顿；提高到40MHz SPI，刷新率能达到32Hz左右，基本流畅。
对于图像类应用，我通常会建议优先选择带DMA或FIFO缓冲的SPI外设，这样能把数据搬运和传输重叠起来。FPGA实现中，可以用双FIFO或者乒乓RAM做帧缓冲，在传送当前帧数据的同时写入下一帧数据，这样能在不提高SPI时钟的情况下提升有效帧率。
6.3 为什么FPGA实现SPI比单片机更灵活，也更需要严谨
最后聊一个很多新手会问的问题：做SPI通信，直接用单片机不就行了吗，为什么还要用FPGA？
本质原因是场景差异。单片机的SPI外设适合控制类任务，每次传输的数据量不大，速率要求不高。FPGA的优势体现在三个场景：一是高速数据流处理，比如ADC连续采样、图像传感器数据读取，数据速率达到数百Mbps时单片机外设很难持续处理；二是多通道并行控制，比如同时控制8路SPI从设备，单片机的多个SPI外设数量有限，FPGA可以用逻辑复制轻松扩展；三是协议定制，SPI协议本身没有统一标准，兼容性和数据帧格式往往需要定制，FPGA可以随意修改协议逻辑，而MCU的硬件SPI协议基本固定。
但FPGA的灵活性是有代价的，所有时序细节都需要自己保证，没有现成的硬件外设帮你兜底。正因如此，我在前文反复强调仿真验证、板级调试和时序约束这三个环节，这在单片机开发中即便省略也不会出大问题，在FPGA开发中省略则必然踩坑。
从SPI协议的基本原理开始，到FPGA的代码实现，再到仿真调试和实战验证，整个过程走下来，我对SPI的理解已经不再是“四条线传输数据”那么简单了。SPI在FPGA里的实现是一次典型的硬件思维训练——协议手册上的一句话，要变成精确到每一个时钟周期的逻辑行为；板上一次数据错乱，要追溯到是采样沿的问题还是时序约束的问题。如果你正准备在FPGA上做SPI驱动或正在调试中反复碰壁，建议按这个顺序重新捋一遍：先查阅从设备数据手册，确认通信模式、位序、CS建立保持时间；再确认自己的Master代码在这些细节上是严格遵循还是想当然；最后再靠仿真和逻辑分析仪逐步验证。把这套流程走通一遍，SPI这个协议对你来说就不再是“看起来简单做起来难”了。
