FPGA开发者大概都有过这种体验：项目里需要一个AXI主机去读写DDR或者访问外设寄存器，第一反应是打开Vivado的IP Catalog，拖一个AXI Master IP出来，连线、生成、例化，一气呵成。方便是真方便，但时间一长你会发现两个问题——一是这个IP的行为像个黑盒，时序为什么这么走、握手为什么卡住，出了问题时你只能对着波形干瞪眼；二是某些定制场景下，标准IP的接口形态和你的逻辑对不上，改起来比从头写还费劲。我在几个ZYNQ-7020的项目里反复被这两件事折磨之后，索性花时间把AXI主机模块用纯Verilog撸了一遍，从状态机到握手信号全部自己掌控。这篇就把整个实现过程拆开讲清楚，包括协议里那些容易踩的坑、状态机怎么设计、代码怎么组织，以及上板验证时我遇到过的几个真实问题。

1. 为什么值得自己写一个AXI主机

1.1 IP核的便利与代价

先说清楚，我不是反对用IP。标准AXI Master IP在功能完整性和协议合规性上是经过充分验证的，尤其是涉及outstanding传输、乱序响应、QoS这些高级特性时，自己写反而容易出协议违规。但问题在于，大部分中小规模项目根本用不到这些高级特性，你需要的往往就是"发一个读请求、收一个读数据"或者"发一个写请求、等一个写响应"这种最朴素的事务级操作。为了这点需求引入一个几百KB的IP，还要理解它那一堆配置参数，性价比其实不高。

更关键的是可调试性。自己写的RTL，每一根信号的来龙去脉都在你脑子里，波形上任何一个异常你都能顺着状态机追下去。而IP核内部是加密的，你只能看接口波形，一旦握手卡死，排查路径会非常长。我在一个图像采集项目里就遇到过AXI IP的写通道偶尔挂起的问题，最后定位到是IP内部对WLAST的处理和我外部的burst长度计算有偏差，但因为看不到内部逻辑，整整耗了两天才绕明白。

1.2 ZYNQ-7020上的典型使用场景

ZYNQ-7020这个平台比较特殊，PS端和PL端通过AXI互联，PL端要访问DDR或者PS的外设寄存器，就必须有一个AXI主机挂在互联总线上。常见的场景包括：PL端做数据采集后通过AXI写DDR做缓存、PL端读取PS配置好的参数表、PL端主动触发PS端的中断配合数据搬运等。这些场景的共同点是事务模式相对固定，不需要复杂的乱序和outstanding，正好是自己写主机的甜区。

我这次实现的目标很明确：一个支持单次读写和增量burst读写、支持可配置burst长度、能正确处理所有握手信号、带超时保护的AXI4主机模块。不追求覆盖协议全集，但求在常用场景下稳定可靠、代码可读、方便二次修改。

1.3 自研模块的边界在哪里

动手之前得先划清边界，否则容易陷入"什么都想支持"的泥潭。我给自己定的范围是：只做AXI4 Full模式的主机侧、只支持INCR类型burst、不支持WRAP和FIXED、outstanding深度为1（即一次事务完成后再发下一次）、数据位宽固定32位、地址位宽32位。这个配置覆盖了ZYNQ-7020上绝大多数PL访问PS的场景，同时把状态机的复杂度控制在可维护的范围内。

超出这个边界的需求，比如需要多 outstanding 提升带宽、需要64位或128位数据宽度、需要WRAP burst做FIFO回绕，那就老老实实用IP或者在我的代码基础上扩展。把边界说在前面，是为了让读代码的人心里有数，不至于拿它去跑一个它根本不适配的场景然后回来骂街。

2. AXI4协议里必须先搞明白的几件事

2.1 五通道握手的本质

AXI4是五通道独立握手的协议：写地址（AW）、写数据（W）、写响应（B）、读地址（AR）、读数据（R）。每个通道都用VALID/READY这一对信号做握手，规则只有一条但极其重要——VALID由发起方拉高后必须保持到READY拉高为止，中途不能撤销；READY由接收方拉高表示可以接收，它可以在VALID之前或之后拉高，但一旦拉高且VALID还没来，也不能撤销。

这条规则听起来简单，但它决定了你状态机的基本形态。很多新手写的AXI主机出问题，根源就是状态机在VALID拉高后因为某个条件不满足又把VALID拉低了，导致协议违规、互联总线挂死。我的做法是把"拉高VALID"和"等待READY"设计成状态机里两个不可分割的连续状态，进入发VALID的状态后，唯一的出口就是等到READY，中间不插入任何可能撤销VALID的分支。

2.2 VALID与READY的依赖关系禁忌

协议里有一条容易被忽略的约束：VALID不能依赖READY。也就是说，发起方不能写成"等READY拉高了再拉VALID"这种逻辑，否则会形成死锁——双方都在等对方先动。正确做法是发起方根据自己的内部条件独立地拉高VALID，接收方根据自己的缓冲情况独立地拉高READY，两者在总线上"碰头"完成握手。

我在代码里严格遵守这一点：AWVALID、WVALID、ARVALID的拉高条件只取决于状态机当前状态和内部数据是否准备好，绝不把对应的READY信号作为拉高条件。这一点在仿真时看不出问题，但上板后如果互联总线的调度策略有变化，违反这条约束的设计就会随机挂死，非常难查。

2.3 burst长度与地址对齐的坑

AXI4的burst长度用AxLEN表示，实际传输拍数是AxLEN+1，范围1到256拍。地址对齐方面，INCR burst的起始地址必须与数据位宽对齐，32位数据宽度意味着地址的低2位必须是0。更隐蔽的坑在于4KB边界：AXI协议规定一个burst不能跨越4KB地址边界，否则行为未定义。这意味着如果你的burst长度是256拍、每拍4字节，那正好是1KB，起始地址必须保证整个burst落在同一个4KB页内。

我在代码里加了一个简单的地址检查逻辑：在发起burst之前，计算起始地址加上burst字节数是否跨越4KB边界，如果跨越就报一个错误标志出来，让上层逻辑去拆分burst。这个检查在仿真时帮我抓到过一次配置错误——上层给的起始地址是0xFFC，burst长度8拍，算下来正好跨过0x1000边界，如果没有这个检查，上板后数据会写到莫名其妙的地方。

2.4 写响应通道为什么不能省

写操作有B通道（写响应），读操作没有对应的"读响应"，读数据通道的最后一拍就是完成标志。B通道容易被省略的原因是：很多人觉得写数据发完了就完事了，BVALID来不来无所谓。但协议要求主机必须接收B响应，否则从机的写响应会堆积，进而阻塞后续的写事务。我在状态机里专门留了一个等待BVALID的状态，收到BRESP后再判断是否成功，失败的话置错误标志。

这里有个细节：BRESP的编码里，OKAY是2'b00，SLVERR是2'b10，DECERR是2'b11。我在代码里对非OKAY的响应都做了错误标志输出，方便上层逻辑做重试或者告警。实际项目中这个错误标志救过我一次——某个外设地址映射错了，写操作一直返回DECERR，如果没有这个标志，数据悄悄丢失根本发现不了。

3. 主机模块的状态机设计

3.1 整体状态划分

状态机是整个模块的骨架，我把它设计成一个大状态机覆盖读写两种事务，通过一个事务类型寄存器来区分当前走哪条路径。状态定义如下：

这个划分的意图是让每个状态只做一件事，状态之间的转移条件清晰可查。比如WRITE_AW状态里只关心AW通道的握手，不掺杂数据发送逻辑，这样波形上任何一个状态的停留时间过长，你都能立刻定位到是哪个通道的握手没完成。

3.2 写事务的状态流转细节

写事务的流转是IDLE → WRITE_AW → WRITE_W → WRITE_B → DONE。这里有个设计选择值得说明：AW和W两个通道在协议上是独立的，理论上可以并行发起，即AWVALID和WVALID同时拉高。但我在实现里选择了串行——先完成AW握手，再发W数据。原因是串行实现的状态机更简单，且对于outstanding深度为1的主机来说，串行带来的性能损失可以忽略（AW握手通常一两个周期就完成）。如果你的场景对写带宽极其敏感，可以改成并行发起，但状态机复杂度会上升，需要同时管理两个通道的握手状态。

WRITE_W状态里需要维护一个写数据计数器，每完成一拍握手计数加一，当计数达到burst长度减一时，把WLAST拉高。这里要注意WLAST必须和最后一拍WVALID同时有效，且只在这一拍有效。我见过有人把WLAST一直拉高或者提前拉高，结果从机收到的burst边界错乱，数据写到了错误的位置。

3.3 读事务的状态流转细节

读事务是IDLE → READ_AR → READ_R → DONE。READ_AR状态发起读地址握手，握手完成后进入READ_R等待读数据。READ_R状态里维护读数据计数器，每拍RVALID与RREADY握手计数加一，同时把RDATA写入内部的数据缓冲或者直接透传到输出端口。当RLAST有效且握手完成时，事务结束。

读通道有个细节：RREADY的拉高时机。我的实现是在进入READ_R状态后就拉高RREADY，表示主机随时可以接收数据。这样做的前提是下游的数据接收逻辑足够快，不会因为缓冲满而丢数据。如果你的下游处理有延迟，应该把RREADY和下游的ready信号联动，避免数据溢出。我在一个项目里就因为RREADY常拉高、下游FIFO满导致数据丢失，后来改成RREADY由FIFO的almost_full反向控制才解决。

3.4 超时保护与错误恢复

状态机里每个等待握手的状都有超时计数。我的做法是给每个状态配一个计数器，进入状态时清零，每个时钟周期加一，当计数超过预设阈值（比如1024个周期）时，强制跳转到ERROR状态并输出超时错误标志。这个机制在实际调试中价值极高——互联总线出问题时，如果没有超时保护，状态机会永远卡在某个等待状态，整个系统看起来像死机，你连从哪查起都不知道。

ERROR状态的处理策略是：输出错误标志一个周期，然后回IDLE等待下一次事务请求。这里不做自动重试，因为超时的原因可能是地址错误、从机未响应、总线挂死等多种情况，盲目重试可能让问题恶化。把错误标志交给上层逻辑，由上层决定是重试、告警还是复位，这样职责划分更清晰。

4. RTL代码的组织与关键实现

4.1 模块端口定义

端口定义直接决定了模块怎么用，我把端口分成四组：时钟复位、事务控制、AXI主机接口、状态输出。事务控制组包括start（发起事务）、trans_type（读写选择）、addr（起始地址）、burst_len（burst拍数减一，符合AXI的AxLEN定义）、wdata（写数据输入）、rdata（读数据输出）、done（完成脉冲）、error（错误标志及错误码）。

AXI接口组就是标准的五通道信号，全部按AXI4规范命名。这里有个经验：端口命名严格遵循AXI规范里的信号名（如AWADDR、AWVALID、AWREADY），不要自己发明缩写，否则后续和别人的模块对接时会产生大量映射工作。状态输出组输出当前状态机的状态编码，方便在ILA里观察。

module axi_master #( parameter ADDR_WIDTH = 32, parameter DATA_WIDTH = 32, parameter TIMEOUT_CNT = 1024 )( input wire clk, input wire rst_n, // 事务控制 input wire start, input wire trans_type, // 0:写 1:读 input wire [ADDR_WIDTH-1:0] addr, input wire [7:0] burst_len, // AxLEN, 实际拍数=burst_len+1 input wire [DATA_WIDTH-1:0] wdata, output reg [DATA_WIDTH-1:0] rdata, output reg done, output reg [3:0] error_code, // AXI写地址通道 output reg [ADDR_WIDTH-1:0] m_axi_awaddr, output reg [7:0] m_axi_awlen, output reg m_axi_awvalid, input wire m_axi_awready, // AXI写数据通道 output reg [DATA_WIDTH-1:0] m_axi_wdata, output reg m_axi_wlast, output reg m_axi_wvalid, input wire m_axi_wready, // AXI写响应通道 input wire [1:0] m_axi_bresp, input wire m_axi_bvalid, output reg m_axi_bready, // AXI读地址通道 output reg [ADDR_WIDTH-1:0] m_axi_araddr, output reg [7:0] m_axi_arlen, output reg m_axi_arvalid, input wire m_axi_arready, // AXI读数据通道 input wire [DATA_WIDTH-1:0] m_axi_rdata, input wire m_axi_rlast, input wire m_axi_rvalid, output reg m_axi_rready );

端口定义里burst_len用8位，是因为AxLEN最大255（对应256拍），8位刚好。error_code用4位编码不同错误类型：1是超时、2是4KB越界、3是写响应错误、4是参数非法。这样上层逻辑可以根据错误码做不同处理。

4.2 状态机主体代码

状态机用三段式写法：第一段时序逻辑更新当前状态，第二段组合逻辑计算下一状态，第三段时序逻辑输出各通道信号。三段式的优点是状态转移和输出逻辑分离，波形上状态跳变清晰，改起来也不容易出错。

localparam S_IDLE = 4'd0; localparam S_WRITE_AW = 4'd1; localparam S_WRITE_W = 4'd2; localparam S_WRITE_B = 4'd3; localparam S_READ_AR = 4'd4; localparam S_READ_R = 4'd5; localparam S_DONE = 4'd6; localparam S_ERROR = 4'd7; reg [3:0] cur_state, nxt_state; reg [7:0] beat_cnt; reg [15:0] timeout_cnt; reg [ADDR_WIDTH-1:0] addr_latch; reg [7:0] len_latch; reg trans_type_latch; // 状态转移 always @(posedge clk or negedge rst_n) begin if (!rst_n) cur_state <= S_IDLE; else cur_state <= nxt_state; end always @(*) begin nxt_state = cur_state; case (cur_state) S_IDLE: begin if (start && !addr_cross_4k) nxt_state = trans_type ? S_READ_AR : S_WRITE_AW; else if (start && addr_cross_4k) nxt_state = S_ERROR; end S_WRITE_AW: if (m_axi_awvalid && m_axi_awready) nxt_state = S_WRITE_W; S_WRITE_W: if (m_axi_wvalid && m_axi_wready && m_axi_wlast) nxt_state = S_WRITE_B; S_WRITE_B: if (m_axi_bvalid) nxt_state = S_DONE; S_READ_AR: if (m_axi_arvalid && m_axi_arready) nxt_state = S_READ_R; S_READ_R: if (m_axi_rvalid && m_axi_rready && m_axi_rlast) nxt_state = S_DONE; S_DONE: nxt_state = S_IDLE; S_ERROR: nxt_state = S_IDLE; default: nxt_state = S_IDLE; endcase end

这段代码里有个关键点：S_IDLE状态下判断start时同时检查了4KB越界，越界直接跳ERROR。addr_cross_4k的计算是组合逻辑，用addr的低12位加上burst字节数判断是否超过0x1000。这个检查放在状态转移里而不是输出逻辑里，是为了保证越界的事务根本不会发起握手，避免对总线产生任何影响。

4.3 各通道输出信号的生成

输出逻辑按通道分组写，每个通道的信号只在该通道相关的状态里有效，其他状态一律拉低。这种写法虽然代码量稍多，但波形上非常干净，任何一个通道的VALID在错误的状态拉高都能一眼看出来。

// AW通道 always @(posedge clk or negedge rst_n) begin if (!rst_n) begin m_axi_awvalid <= 1'b0; m_axi_awaddr <= 0; m_axi_awlen <= 0; end else begin case (nxt_state) S_WRITE_AW: begin m_axi_awvalid <= 1'b1; m_axi_awaddr <= addr_latch; m_axi_awlen <= len_latch; end default: begin m_axi_awvalid <= 1'b0; end endcase end end // W通道 always @(posedge clk or negedge rst_n) begin if (!rst_n) begin m_axi_wvalid <= 1'b0; m_axi_wlast <= 1'b0; m_axi_wdata <= 0; end else begin case (nxt_state) S_WRITE_W: begin m_axi_wvalid <= 1'b1; m_axi_wdata <= wdata; m_axi_wlast <= (beat_cnt == len_latch); end default: begin m_axi_wvalid <= 1'b0; m_axi_wlast <= 1'b0; end endcase end end

注意W通道的wlast判断用的是beat_cnt == len_latch，因为len_latch存的是AxLEN（拍数减一），beat_cnt从0开始计数，当计数等于len_latch时正好是最后一拍。这个对应关系如果搞错，WLAST会提前或延后一拍，从机就会把burst边界算错。

4.4 数据缓冲与计数器管理

beat_cnt在WRITE_W和READ_R状态里都要用，但两个场景的计数逻辑略有不同。写场景下，beat_cnt在每拍W握手完成时加一；读场景下，beat_cnt在每拍R握手完成时加一。我在代码里用同一个计数器，进入WRITE_W或READ_R状态时清零，握手完成时加一，事务结束时保持到下次事务开始再清零。

rdata的输出有个细节：读数据是逐拍到达的，如果burst长度大于1，rdata端口每拍都会更新。上层逻辑需要在RVALID有效时采样rdata，而不是等done脉冲来了再采。我在端口注释里专门写了这一点，因为见过有人等done来了才去读rdata，结果只拿到最后一拍的数据。如果上层需要完整的burst数据，应该在模块内部加一个数据缓冲RAM，把每拍数据存下来，done有效时再整体输出。

5. 仿真验证与上板调试

5.1 搭建一个够用的仿真环境

仿真环境不需要多复杂，但必须能覆盖正常读写、burst传输、错误响应、超时这几种情况。我用一个简单的AXI从机模型来配合，从机模型的行为是：收到AW和W后延迟几个周期返回B响应，收到AR后延迟几个周期逐拍返回R数据。延迟周期做成可配置参数，方便测试不同时序下的握手行为。

测试用例我写了四个：单拍写、单拍读、8拍burst写、8拍burst读。每个用例检查done脉冲是否按时出现、rdata是否正确、error_code是否为0。另外专门写了两个异常用例：一个是故意给一个跨4KB的地址，检查是否报error_code=2；另一个是把从机的响应延迟设得超过超时阈值，检查是否报error_code=1。

仿真时有个技巧：把AXI接口的所有信号都加到波形里，按通道分组显示。观察时先看VALID/READY的握手对，再看数据。如果某个通道的VALID拉高后READY迟迟不来，就顺着从机模型的状态查为什么没准备好。这种按通道排查的方法比盯着整个波形乱看效率高得多。

5.2 ILA抓波形时的观察重点

上板调试离不开ILA，我把ILA的触发条件设成start信号的上升沿，采样深度设成足够覆盖一次完整事务（比如4096点）。抓到的波形重点看三处：一是AWVALID到AWREADY的间隔，正常应该在一两个周期内完成，如果间隔很长说明互联总线繁忙或者从机没准备好；二是WLAST的位置，确认它和最后一拍WVALID对齐；三是BVALID到来的时机，确认写响应没有丢失。

我在一次调试中发现AWVALID拉高后AWREADY过了几十个周期才来，一开始怀疑是自己代码有问题，后来查下来是PS端的DDR控制器在那个时刻正在处理高优先级的访问，属于正常的总线竞争。这个现象提醒我：超时阈值不能设得太小，否则正常的 bus 竞争也会触发超时误报。后来我把阈值从256改成了1024，误报就消失了。

5.3 常见挂死问题的排查链路

AXI主机挂死是最让人头疼的问题，我总结了一个排查顺序：第一步看状态机停在哪个状态，如果是等待握手的状，看对应的VALID和READY哪个没来；第二步如果VALID没来，查状态转移条件为什么不满足，通常是上游的start信号或者地址检查没过；第三步如果READY没来，问题在从机侧或者互联总线，需要抓互联总线另一侧的波形；第四步如果握手完成了但状态没跳，查状态转移的组合逻辑是不是漏了某个条件。

有一次我遇到写事务卡在WRITE_B状态，BVALID一直不来。按上面的链路查下来，发现是WLAST的时序有问题——WLAST比最后一拍WVALID晚了一个周期，从机认为burst还没结束，一直在等更多数据，自然不会返回B响应。根因是beat_cnt的加一逻辑用了非阻塞赋值，导致wlast的判断晚了一拍。改成组合逻辑判断wlast后问题解决。这个坑很典型，WLAST和最后一拍WVALID必须严格同拍。

6. 几个值得单独说的实战经验

6.1 地址位宽和数据位宽的取舍

ZYNQ-7020的PL端访问PS DDR，地址位宽通常是32位，数据位宽32位或64位。我这次固定32位数据宽度，是因为大部分控制类访问和中等带宽的数据搬运32位够用，且状态机和计数器逻辑最简单。如果你的场景需要更高带宽，比如视频流写入DDR，那64位甚至128位数据宽度是必要的，但要注意数据宽度变化后，地址对齐要求、4KB边界的计算、beat_cnt的位宽都要跟着改，不能只改端口位宽了事。

地址位宽方面，32位覆盖4GB空间，对ZYNQ-7020来说足够。如果你的系统地址映射超过4GB（比如接了更大的DDR），需要扩展到64位，这时候AWADDR和ARADDR要改成64位，4KB边界检查的逻辑也要相应调整——不过4KB边界检查和地址位宽无关，始终看低12位。

6.2 burst长度不是越大越好

直觉上burst越长，地址开销摊得越薄，带宽越高。但实际测试下来，burst长度8到16拍是个比较平衡的点。原因有两个：一是burst太长会长时间占用总线，影响其他主机的访问延迟，在有多主机的系统里可能引发调度问题；二是burst跨越4KB边界的概率随长度增加而上升，拆分逻辑会更频繁地触发。我在一个项目里试过burst长度64拍，带宽确实比16拍高了一点，但PS端其他访问的延迟明显变差，最后折中用了16拍。

另外要注意，burst长度和从机的FIFO深度要匹配。如果从机的写FIFO只有16深，你发64拍的burst，从机会在中间反压WREADY，虽然协议允许，但会增加传输时间。理想情况是burst长度不超过从机缓冲深度，这样握手能连续进行。

6.3 复位策略与跨时钟域

AXI主机的复位必须和AXI时钟同步，异步复位要经过同步器再释放。我见过有人直接把外部复位信号接到状态机的异步复位端，结果复位释放时正好赶上时钟边沿，状态机进入了非法状态。正确做法是用一个复位同步模块，把异步复位同步到AXI时钟域后再送给状态机。

跨时钟域方面，如果主机的事务发起逻辑和AXI时钟不同频，start信号和done信号需要做跨时钟域处理。简单的做法是用脉冲同步器，复杂一点用异步FIFO传递事务参数。我这次实现假设事务发起逻辑和AXI时钟同频，所以没做跨时钟域，但端口注释里明确写了这个前提，避免使用者误用。

6.4 代码可综合性的一些细节

写RTL时要注意几个影响综合结果的地方：一是避免在状态机里用除法或取模，4KB边界检查用位运算实现（addr[11:0] + burst_bytes > 12'hFFF），不要用除法；二是计数器位宽要够，timeout_cnt用16位支持最大65535周期超时，如果场景需要更长超时，要加宽位宽；三是输出信号尽量用寄存器输出，避免组合逻辑直接驱动AXI端口，这样时序更容易收敛。

还有一点：case语句要写default分支，即使你觉得所有状态都覆盖了。综合工具对没有default的case可能推断出锁存器，尤其是在组合逻辑的always块里。我在nxt_state的计算里写了default: nxt_state = S_IDLE，就是为了避免这个问题。

7. 模块的复用与扩展思路

这套代码我在三个项目里复用下来，基本没改过主体逻辑，只在端口和参数上做了适配。复用的关键是接口稳定——事务控制组的信号定义一旦定下来，上层逻辑就不用关心AXI协议的细节，只管发start、给地址、收done。这种分层让上层逻辑的开发和调试独立于总线协议，效率提升很明显。

扩展方向有几个：一是加outstanding支持，把单事务状态机改成带事务队列的形式，可以显著提升连续访问的带宽，但状态机复杂度会上升不少，需要仔细处理响应乱序的问题；二是加数据位宽参数化，用generate语句生成不同位宽下的对齐和拼接逻辑；三是加一个简单的DMA引擎，把burst读写和地址自增结合起来，做成一个能自动搬运数据块的模块。这几个扩展我都在不同项目里做过，核心思路都是在现有状态机外面包一层控制逻辑，而不是改动状态机本身。

最后分享一个调试习惯：每次上板前，先在仿真里把ILA要抓的信号跑一遍，确认波形符合预期再上板。上板后如果ILA抓到的波形和仿真不一致，那问题一定出在时序约束、复位释放或者跨时钟域上，而不是逻辑功能本身。这个习惯帮我省了大量上板调试的时间，因为仿真里能发现的问题绝不留到板子上。