1. 为什么要在ZYNQ-7020上手写AXI主机模块
做FPGA开发的朋友大概都有过这种体验：项目里需要一个AXI主机去读写DDR或者访问片上外设，第一反应就是打开Vivado的IP Catalog，拖一个AXI Master IP或者用Create Interface向导生成一套模板代码，连线、例化、跑仿真，看起来十分钟搞定。但真到了调试阶段，地址对不上、突发长度算错、握手信号卡死、时序收敛不过去，一堆问题全冒出来，而你手里只有一堆自动生成的代码，连从哪儿下手排查都不知道。我在几个基于ZYNQ-7020的项目里反复踩过这个坑，后来索性把AXI主机模块从零手写了一遍，才发现这件事没有想象中那么玄乎，反而因为每一行代码都是自己写的，调试效率提升了不止一个档次。
这篇内容聊的就是这件事：不依赖任何IP核，纯手写Verilog，在ZYNQ-7020的PL侧实现一个可用的AXI4主机模块，能够完成对AXI从设备（比如PS侧的DDR控制器、BRAM控制器或者自定义外设）的读写访问。核心关键词是AXI4协议、Verilog手写RTL、ZYNQ-7020、突发传输、握手时序。适合的人群很明确：有一定Verilog基础、做过FPGA项目、被AXI IP核的黑盒特性折磨过、想真正搞懂AXI总线到底怎么跑的中级开发者。如果你是刚入门的新手，建议先把Verilog的时序逻辑和状态机写熟再来看，不然容易卡在握手协议上。
我先说清楚这个模块能干什么、边界在哪里。它实现的是AXI4 Full模式下的主机侧行为，支持单次读写和增量突发（INCR）读写，数据位宽32位，地址位宽32位，突发长度可配置（1到256），不支持乱序、不支持Outstanding多笔并发、不支持Exclusive访问和Cache维护操作。这个范围覆盖了绝大多数中小规模数据搬运场景，比如PL往DDR里写采集数据、从DDR读配置参数、访问PL侧的BRAM等。之所以砍掉那些高级特性，是因为每增加一个特性，状态机的复杂度就翻一倍，而实际项目里九成场景根本用不上。先把基础读写跑通跑稳，比一上来追求大而全要务实得多。
ZYNQ-7020这个平台值得单独说一句。它是Xilinx Zynq-7000系列里出货量很大的一款，PS侧双核Cortex-A9加PL侧Artix-7架构的可编程逻辑，PS和PL之间通过AXI互联矩阵通信。PL要访问PS侧的DDR，走的就是AXI HP（High Performance）端口；PS要配置PL侧的寄存器，走的是AXI GP端口或者AXI Lite。手写主机模块最典型的用途，就是让PL主动把数据推到DDR里，绕开PS的软件搬运，省CPU、省延迟。理解了这条数据通路，你就明白为什么值得自己写一个主机模块——它是PL侧主动发起内存访问的钥匙。
2. AXI4协议核心机制拆解：五个通道到底怎么配合
2.1 五通道模型与握手的本质
AXI4是全双工、基于VALID/READY握手的点对点总线协议。一次完整的读写事务被拆成五个独立通道：写地址通道（AW）、写数据通道（W）、写响应通道（B）、读地址通道（AR）、读数据通道（R）。每个通道都是单向的，主机发地址和数据，从机回响应和读数据。这种拆分的好处是地址和数据可以流水，写地址发出去的同时数据就能跟上，读地址发出去后数据可以晚几个周期回来，互不阻塞。
握手的规则只有一条，但必须刻在脑子里：VALID由发送方拉高表示数据有效，READY由接收方拉高表示可以接收，两者同时为高的那个时钟上升沿，完成一次传输。关键在于，VALID一旦拉高，在对应的READY到来之前绝对不能撤销，也不能改变数据内容。这条规则是AXI协议的死线，违反了轻则数据错乱，重则总线挂死。我见过不少手写的模块在仿真里跑得好好的，上板就出问题，追根溯源就是某个状态下VALID拉高后又因为条件变化撤了，从机等不到READY就永远卡住。
生活化地类比一下：VALID就像快递员按门铃说"有你的包裹"，READY就像你开门说"放这儿吧"。快递员按了门铃不能因为你没马上开门就走人，必须等着；你开门的时候包裹必须还在手上。两边都到位了，这一单才算完成。五个通道各自独立握手，但一次事务的完成需要相关通道按顺序配合。
2.2 写事务的通道时序关系
写操作涉及AW、W、B三个通道。主机先在AW通道发出写地址和控制信息（突发长度、突发类型、大小），同时在W通道发出写数据。这两个通道是并行进行的，从机可以先把地址收下，数据晚几拍到也没关系。数据全部发完后，从机通过B通道回一个写响应（BRESP），告诉主机这笔写到底成功没有。
这里有个容易忽略的点：W通道的最后一个数据必须带WLAST标志，从机靠这个标志判断一笔突发结束。如果你的突发长度是8，那就要发8拍数据，第8拍的WLAST拉高。WLAST拉早或拉晚，从机要么提前结束接收、要么一直等下去。我在早期版本里就因为WLAST的计数逻辑写错，导致从机收完数据后B通道迟迟不响应，查了大半天才发现是最后一拍的判定条件用了大于等于而不是等于。
AW通道的地址信息里，AWSIZE表示每拍传输的字节数（2的幂次），AWLEN表示突发长度减一，AWBURST表示突发类型。对于32位数据位宽，AWSIZE通常设为2（即4字节）。AWLEN设成7表示8拍突发。这些编码规则必须精确，错一位从机解析出来的突发就完全不对。
2.3 读事务的通道时序关系
读操作简单一些，只有AR和R两个通道。主机在AR通道发出读地址和控制信息，从机在R通道返回读数据和读响应。R通道每拍数据都带RLAST标志，最后一拍拉高表示突发结束。读响应RRESP和每拍数据一起返回，不像写响应是单独一个通道。
读事务的一个特点是主机必须有能力持续接收数据。从机返回数据的节奏由从机决定，主机不能主动"慢下来"，只能通过READY信号做反压。如果你的主机模块在接收数据时还要做其他处理，READY可能会周期性拉低，这时候从机会保持数据不变等你。这就要求主机侧的接收逻辑足够健壮，不能因为READY拉低就丢了状态。
2.4 突发类型与地址计算
AXI4支持三种突发类型：FIXED（地址不变，用于FIFO类访问）、INCR（地址递增）、WRAP（回卷，用于Cache line）。手写主机模块最常用的是INCR，地址按AWSIZE递增。地址计算有个细节：每拍传输后地址增加的是2^AWSIZE字节，而不是固定值。32位位宽、AWSIZE=2时，每拍地址加4。如果突发跨越了4KB边界，协议是不允许的，从机会报错。所以设计时要保证起始地址和突发长度组合不会越界，这一点在访问DDR时尤其要注意，因为DDR的地址空间划分对边界敏感。
WRAP模式在访问Cache line时有用，地址到达边界后回卷到起始对齐地址。但手写模块如果只做数据搬运，INCR足够，WRAP可以先不实现，省掉一块地址回卷逻辑。
3. 主机模块的整体架构设计
3.1 状态机划分思路
手写AXI主机，核心就是一个状态机。我把写和读拆成两个独立的状态机，各自管理自己的通道，互不干扰。这样设计的好处是读写可以并行发起（虽然我这个版本没做并发优化，但结构上留了余地），调试时也能单独验证写通路或读通路。
写状态机的状态划分：IDLE（空闲等待命令）、AW_SEND（发写地址）、W_SEND（发写数据）、B_WAIT（等写响应）、DONE（完成）。读状态机：IDLE、AR_SEND（发读地址）、R_RECV（收读数据）、DONE。每个状态里只做一件事，状态转移条件清晰，出问题容易定位。
为什么不用一个大状态机把读写揉在一起？因为读写通道的握手节奏完全不同，揉在一起状态数会爆炸，而且读写交替时容易互相拖累。分开之后，写通路卡住不影响读通路，读通路慢也不阻塞写通路，模块的鲁棒性更好。
3.2 命令接口与数据缓冲设计
主机模块对外需要一个简洁的命令接口，让上层逻辑告诉它"读哪里、读多少"或者"写哪里、写多少、数据在哪"。我设计的是一个简单的寄存器式接口：命令寄存器（含地址、长度、读写标志）、启动信号、完成信号、以及一个数据FIFO用于写数据的暂存和读数据的输出。
写数据为什么要过FIFO？因为AXI的W通道要求数据连续供给，如果上层数据源产生数据的速度不稳定，直接对接会导致W通道断流，从机等数据、总线效率下降。加一级FIFO做缓冲，主机从FIFO里取数据往W通道送，只要FIFO不空就能连续发，突发传输的效率就上来了。读数据同理，从机返回的数据先入FIFO，上层慢慢取，主机侧的READY可以一直保持高，接收不中断。
FIFO深度怎么定？经验值是至少能装下一笔最大突发的数据量。如果最大突发长度设256拍、32位宽，那就是1KB，FIFO深度256。实际项目里突发长度通常设16到64，FIFO深度64或128就够。深度太小会导致突发中途断流，太大浪费BRAM资源。我一般按最大突发长度配置，留一点余量。
3.3 时钟与复位策略
ZYNQ-7020的PL侧时钟通常来自PS的FCLK或者外部晶振经MMCM分频。AXI主机模块的时钟必须和它所连接的AXI互联时钟同源，否则跨时钟域会引入额外的同步逻辑，复杂度陡增。我的做法是整个主机模块跑在单一的AXI时钟域下，如果上层数据源来自不同时钟域，在FIFO的写侧做跨时钟域处理（用异步FIFO），主机模块本身不碰跨时钟问题。
复位用同步复位、高有效，复位时所有VALID拉低、状态机回IDLE、FIFO清空。注意AXI协议要求复位期间VALID必须为低，这一点在代码里要显式保证，不能依赖寄存器的初始值。
4. 关键RTL代码实现与逐段解析
4.1 写地址通道的实现
写地址通道的逻辑相对直接：状态机进入AW_SEND后，把命令寄存器里的地址、长度、大小、突发类型搬到AW通道上，拉高AWVALID，等AWREADY。握手成功后进入W_SEND。
// 写地址通道 always @(posedge clk) begin if (!rst_n) begin awvalid <= 1'b0; awaddr <= 32'd0; awlen <= 8'd0; awsize <= 3'd2; awburst <= 2'b01; // INCR end else begin case (wr_state) WR_IDLE: begin if (wr_start) begin awaddr <= cmd_addr; awlen <= cmd_len - 1; awsize <= 3'd2; awburst <= 2'b01; awvalid <= 1'b1; end end WR_AW_SEND: begin if (awready) begin awvalid <= 1'b0; end end endcase end end这段代码的关键在于awvalid的撤销时机——只有awready为高、握手完成的那一拍才撤销。awlen存的是长度减一，这是AXI协议的编码约定，容易写错。awsize固定为2（4字节），对应32位数据位宽。awburst设为01表示INCR递增突发。
4.2 写数据通道与WLAST生成
写数据通道是写通路里最容易出问题的地方。数据从FIFO读出，每拍拉高WVALID，等WREADY。同时要维护一个计数器，数到最后一拍时拉高WLAST。
// 写数据通道 always @(posedge clk) begin if (!rst_n) begin wvalid <= 1'b0; wlast <= 1'b0; wdata <= 32'd0; wr_cnt <= 8'd0; end else begin case (wr_state) WR_W_SEND: begin if (!fifo_empty && !wvalid) begin wdata <= fifo_dout; wvalid <= 1'b1; wlast <= (wr_cnt == cmd_len - 1); end if (wvalid && wready) begin wvalid <= 1'b0; wr_cnt <= wr_cnt + 1'b1; if (wr_cnt == cmd_len - 1) begin wr_state <= WR_B_WAIT; end end end endcase end end这里有个设计取舍：wvalid拉高后，数据从FIFO取出锁存到wdata，握手完成后才读下一拍。这种"一拍一取"的方式简单可靠，但效率上每拍之间可能有一拍的空隙（因为要等FIFO读延迟）。如果FIFO是FWFT（First Word Fall Through）模式，fifo_dout直接就是下一个数据，可以做到背靠背连续传输。我在实际项目里用的是FWFT FIFO，W通道能跑满，突发传输效率接近理论值。
wlast的判定用wr_cnt == cmd_len - 1，注意cmd_len是突发长度，计数器从0开始，所以最后一拍的计数值是长度减一。这个边界条件我强调过，写错就是从机等不到结束标志。
4.3 写响应通道与错误处理
写响应通道只有从机发、主机收。主机在B_WAIT状态拉高BREADY，等BVALID。收到响应后检查BRESP，如果是OKAY（2'b00）就正常完成，如果是SLVERR或DECERR就置错误标志。
// 写响应通道 always @(posedge clk) begin if (!rst_n) begin bready <= 1'b0; wr_error <= 1'b0; end else begin case (wr_state) WR_B_WAIT: begin bready <= 1'b1; if (bvalid) begin bready <= 1'b0; wr_error <= (bresp != 2'b00); wr_state <= WR_DONE; end end endcase end end错误处理这块很多手写模块会偷懒，直接忽略BRESP。但实际项目里从机报错是常有的事（地址越界、访问了未映射区域），如果主机不检查，上层根本不知道数据没写进去，问题会以更隐蔽的方式暴露出来。加一个错误标志，上层读一下就知道这笔传输成没成，排查效率高很多。
4.4 读地址与读数据通道
读通路的AR通道和写通路的AW通道结构几乎一样，把aw换成ar、w换成r即可。读数据通道的RLAST生成逻辑和WLAST类似，用计数器数到最后一拍。
// 读数据通道 always @(posedge clk) begin if (!rst_n) begin rready <= 1'b0; rd_cnt <= 8'd0; end else begin case (rd_state) RD_R_RECV: begin rready <= 1'b1; if (rvalid && rready) begin fifo_wr_en <= 1'b1; fifo_wr_data <= rdata; rd_cnt <= rd_cnt + 1'b1; if (rlast) begin rready <= 1'b0; rd_state <= RD_DONE; end end end endcase end end读数据通道的rready在接收期间保持高，数据直接写入FIFO。用rlast判断结束比用计数器更可靠，因为rlast是从机给的，主机不用自己算边界。但计数器还是要保留，用于统计实际收到的拍数，和预期长度做比对，不一致就报错。
4.5 顶层状态机整合
把读写两个状态机在顶层整合，对外暴露命令接口和FIFO接口。顶层还要处理读写命令的仲裁——如果读写同时请求，我采用简单的优先级：写优先。因为写操作通常对时序更敏感（数据采集场景下写不能丢），读可以稍等。这个策略在大多数场景下够用，如果项目对读延迟有硬要求，可以改成轮询仲裁。
// 顶层命令分发 always @(posedge clk) begin if (!rst_n) begin wr_start <= 1'b0; rd_start <= 1'b0; end else begin wr_start <= cmd_valid && cmd_is_write && !wr_busy; rd_start <= cmd_valid && !cmd_is_write && !rd_busy && !wr_busy; end end注意读启动条件里加了!wr_busy，保证写优先。wr_busy和rd_busy由各自状态机输出，非IDLE即为忙。
5. 仿真验证与上板调试实录
5.1 搭建Testbench的要点
手写AXI主机，仿真验证是绕不过去的。我搭了一个简化的AXI从机模型作为Testbench的响应端，模拟从机的握手行为：收到AW和W后延迟几拍回B响应，收到AR后延迟几拍返回R数据。这个从机模型不需要完整实现协议，只要能正确握手、按突发长度返回数据就行。
Testbench里要覆盖几个关键场景：单次写、单次读、长度8的突发写、长度8的突发读、连续多笔读写交替、FIFO空/满边界。每个场景检查数据是否正确、WLAST/RLAST是否在正确位置、BRESP是否OKAY。我习惯在Testbench里加断言，比如"awvalid拉高后到awready之前不能撤销"，用assert property或者简单的if检查，仿真时一旦违反立刻报错。
仿真波形要重点看几个地方：AWVALID和AWREADY的握手时刻、WVALID和WREADY的握手、WLAST的位置、BVALID的到来时机。这几个点对了，写通路基本就通了。读通路看AR握手、RVALID和RREADY、RLAST位置。
5.2 上板调试的典型现象与排查
仿真过了不代表上板就过，这是我踩过最深的坑。上板后第一个要验证的是时钟和复位——用ILA抓一下AXI时钟有没有、复位释放的时机对不对。ZYNQ的PS复位释放和PL时钟建立有先后关系，如果PL逻辑在时钟稳定前就开始跑，状态机会进入未定义状态。
第二个要验证的是地址映射。PL访问DDR走HP端口，地址要落在DDR的物理地址范围内。我遇到过一次地址配错，主机发出去的地址从机根本不响应，AWVALID一直高、AWREADY一直低，总线挂死。用ILA抓AWADDR一看，地址落在了未映射区域。所以上板前一定要确认地址映射表，AXI互联的地址段配置和主机发出的地址必须对得上。
第三个常见问题是突发跨4KB边界。DDR控制器对跨边界的突发会报SLVERR，如果主机不检查BRESP，数据就悄悄丢了。我的做法是在命令下发前做地址检查，起始地址加上突发总字节数不能跨4KB边界，超了就拆分或者报错。
5.3 常见问题速查表
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| AWVALID高但AWREADY一直低 | 地址未映射或从机未就绪 | 检查地址映射表、从机复位状态 |
| WLAST位置不对 | 计数器边界条件写错 | 核对cmd_len与计数器比较逻辑 |
| B通道无响应 | WLAST未正确拉高或数据拍数不符 | 抓W通道波形数拍数 |
| 读数据错位 | RREADY时序或FIFO写入冲突 | 检查rready与fifo_wr_en的时序 |
| 突发中途断流 | FIFO深度不足或读延迟大 | 加大FIFO深度或用FWFT模式 |
| 上板后状态机卡死 | 复位释放时机或时钟未稳定 | 用ILA抓时钟复位信号 |
| 数据偶发错误 | VALID撤销违反协议 | 检查所有VALID的撤销条件 |
这张表是我实际调试中积累的，大部分问题都能在里面找到对应项。特别说一下"数据偶发错误"这一条，偶发问题最难查，往往就是某个VALID在READY到来前被撤销了，仿真时因为时序凑巧没暴露，上板后时序变化就冒出来。所以代码review时要把每个VALID的撤销条件都过一遍，确保只在握手完成时撤销。
6. 性能优化与工程化建议
6.1 提升突发传输效率的几个手段
基础版本跑通之后，效率往往还有提升空间。第一个手段是加大突发长度。AXI的总线开销主要在地址握手和响应握手，突发越长，均摊到每拍数据的开销越小。长度16的突发比长度4的效率高不少，但也不是越长越好，太长会占用总线、增加延迟，而且受4KB边界限制。我一般用16到64之间。
第二个手段是读写通道并行。基础版本写优先、读写串行，如果应用场景读写都频繁，可以改成读写状态机完全独立、各自管理通道，让读写事务在总线上交错进行。AXI协议本身支持读写通道独立握手，只要从机支持，读写可以同时在路上。这个改动需要仔细处理命令队列和完成信号的顺序，复杂度上升明显，按需采用。
第三个手段是数据位宽。32位是基础配置，如果带宽不够，可以扩到64位或128位，每拍搬更多数据。位宽扩展主要改数据通路和FIFO位宽，状态机逻辑基本不变，但要注意AWSIZE要相应调整（64位对应size=3，128位对应size=4），地址递增步长也要改。
6.2 代码可综合性注意事项
手写RTL要保证可综合，几个红线不能碰：不用initial块给寄存器赋初值（综合器可能忽略）、不用延迟语句、不用不可综合的系统函数。FIFO用BRAM实现时注意读写冲突的处理，同一地址同时读写的行为要明确。
另外，状态机的编码方式建议用独热码或者格雷码，综合后的时序更好。状态数不多时独热码资源占用可接受，时序收敛更容易。我早期用二进制编码，状态跳转组合逻辑深，时序紧张，换独热码后明显改善。
6.3 模块复用与参数化设计
把地址位宽、数据位宽、最大突发长度做成parameter，模块就能适配不同项目。参数化时注意位宽相关的计算要用parameter推导，不要写死数字。比如突发长度计数器的位宽用$clog2(MAX_BURST_LEN)，地址递增步长用1 << DATA_WIDTH_BYTES。这样换平台或者改配置时只改参数，不用动逻辑。
模块的接口也建议标准化，命令接口、FIFO接口、状态输出接口分开，方便在不同项目里例化和替换。我现在的做法是把AXI主机做成一个独立的.v文件，接口固定，上层逻辑通过标准接口对接，换项目时直接拷过去改参数就行。
7. 我在实际项目中的几点体会
手写AXI主机这件事，最大的收获不是省了一个IP核，而是把AXI协议从"黑盒"变成了"白盒"。以前用IP核，出问题只能猜；现在每一拍握手、每一个状态转移都在自己掌控里，调试时看波形就能定位到具体哪一行逻辑。这种掌控感在复杂项目里价值极高，尤其是多主机、多从机的互联场景，知道总线上的每一笔事务怎么来的、怎么走的，排查效率完全不是一个量级。
另外一个体会是，协议规范一定要读原文。网上很多教程讲AXI只讲个大概，握手规则、突发编码、边界限制这些细节要么略过要么讲错。我建议把ARM的AXI协议规范里通道握手和突发传输那两章精读一遍，很多坑在规范里其实都写明了，只是没人告诉你去看。比如VALID不能撤销这条，规范里用加粗字体强调，但很多二手资料根本不提。
最后分享一个小技巧：调试AXI总线时，ILA的触发条件设成"VALID高且READY低持续超过N个周期"，这个条件能抓到绝大多数握手卡死的问题。正常握手最多几个周期就完成，持续卡住说明对端没响应或者协议违反了。把这个触发条件配上，上板调试能省很多时间。这个模块后续还可以往Outstanding多笔并发、读写通道完全并行、支持WRAP突发这几个方向扩展，每加一个特性都要重新验证握手时序，急不得。
