2026年了，FPGA大赛用安路FPGA做RISC-V软核，AXI总线上挂DDR3控制器，读写时序老是违规，有没有排查套路？

先别急着怀疑AXI仲裁，你这个现象更像是DDR3控制器PHY层的训练没收敛。安路这块的MIG类IP，启动时跑write leveling和read training，如果板子走线长度差得离谱或者时钟没对齐，训练结果会“假通过”，但实际跑起来一上负载就崩。排查套路：第一步用ILA抓控制器给AXI的写响应通道，看awready和wready是不是偶发拉不高；第二步读PHY的training status寄存器，一般有bit表示dqs gate窗口余量，余量小于某个阈值就说明物理层问题。如果status显示正常，再回头查你的AXI数据位宽和DDR3突发长度的匹配，常见坑是32位AXI配了8位DDR颗粒，burst长度没换算对。你们现在用的是安路哪个型号？不同系列的PHY配置寄存器地址差挺多的。

说个实在的排查顺序吧，我去年在类似项目上踩过同一坑，最后发现不是时序约束的事，是复位释放逻辑的问题。你描述“Linux启动到一半死机”，这个阶段其实DDR3已经在高频读写，所以先别纠结建立时间，示波器看到的不一定准，探头地线没夹好都能看出假违规。我的建议是分三层查：第一层，用ILA抓AXI总线上IP核的awid/arid，看是不是有多个master在抢同一bank时出现id乱序。RISC-V软核加上DMA、外设，如果id不够宽，AXI协议允许乱序返回，但你的DDR3控制器如果不支持乱序，就会卡死。第二层，查DDR3控制器的app_rdy和app_wdf_rdy信号，这两个是握手信号，如果app_rdy偶尔拉低超过几百个周期，说明控制器内部FIFO满了，追下去看是写数据FIFO还是读数据FIFO，常见是写数据FIFO因为AXI数据位宽和DDR3内部数据位宽的跨时钟域转换没配好。第三层，才是你提到的PHY参数，重点看ODT（片上终端）阻值，安路这个IP默认ODT是40欧，但如果你板子上的DDR3颗粒是x16的，建议改成60欧，这个在MIG的parameter里能调。至于约束，别只加create_clock，还要给DQS和DDR时钟之间设set_clock_groups -asynchronous，否则工具会把假路径当真路径去优化，反而引入额外延迟。最后说仲裁优先级，一般RISC-V核的优先级应该最高，但如果你DDR3控制器本身接了多个AXI slave口，建议把写通道的优先级调低一点，读通道优先，因为Linux启动时页表加载对读延迟更敏感。你们用的软核是rocket还是picorv32？总线位宽和outstanding能力差别很大，这个会直接影响DDR3控制器的调度效率。

换个思路，别只盯着时序和寄存器，先确认是不是DDR3控制器IP本身的时钟域约束没写对。安路官方给的例程里，DDR3控制器的用户侧时钟（比如ui_clk）和AXI时钟往往是同频的，但如果你在顶层例化时把这两个时钟当成异步去处理，工具就会自动插入同步器，延迟直接翻倍，时序肯定绷不住。快速验证方法：在约束文件里查一下create_clock有没有同时约束ui_clk和axi_aclk，再查有没有set_clock_groups -group {ui_clk} -group {axi_aclk} -asynchronous，如果有这行，删掉重新跑综合，大概率时序就收敛了。另外你说的用示波器看建立时间，我建议别太当真，DDR3信号频率一般都在400MHz以上，普通示波器探头带宽不够，看到的多半是反射叠加的伪波形。真正要抓的是ILA里的dqs_gate信号和rddata_valid，如果rddata_valid偶尔丢一拍，说明读训练时dqs gate的窗口位置不对，这个可以在控制器寄存器里手动微调，一般有个偏移量寄存器，以1/64周期为单位步进。还有个偏门但有效的做法：把Linux启动时的DDR频率降一半，比如从400降到200，如果死机点消失，那基本锁定是PHY层训练问题，如果还在死机，那问题就在AXI逻辑层。你们是用的安路官方FPGA板还是自己画的板子？自己画的话，DDR3走线等长有没有做到±50mil以内，这个对训练结果影响极大，我见过最离谱的是VTT端接电阻焊错位置导致训练永远差一格。先按我说的删掉异步时钟约束试一版，再不行就把PHY的pre-emphasis打开，那个寄存器一般叫tx_pi_coeff，默认是0，调到2或3能明显改善上升沿质量。

先查一件事：RISC-V软核的ICM（指令缓存）和DCM（数据缓存）是不是都挂在同一个AXI slave端口上？很多软核默认两个缓存端口独立，但安路IP的AXI互连有时会把它们合并成同一个ID通道。如果ID宽度不够，DDR3控制器会误判为同一master的乱序请求，直接卡死。你Linux启动到一半挂掉，很可能就是ICM和DCM在抢同一bank时互相踩踏。用ILA抓一下arid和awid，看是不是两个不同的id在交替出现，如果是，去软核配置里把两个端口分开映射到不同的AXI slave接口。

说个我们去年比赛踩过的坑，可能和你的现象完全对得上。当时我们用安路EG4S20跑RISC-V，也是Linux启动到一半死机，示波器看DDR3数据线全是毛刺，以为是时序违规，折腾了三天约束，最后发现是复位顺序的问题。安路DDR3控制器的PHY复位和AXI互连的复位必须是同一个时钟域释放，而且PHY的复位要晚于PLL锁定至少200us。我们当时图省事，把整个SoC共用一个复位信号，结果PHY训练时PLL还没稳，训练结果假通过，跑一会儿就挂。你查一下顶层复位逻辑，确认PHY的复位是不是独立于AXI域，并且延迟足够。另外，用ILA抓DDR3控制器的pll_lock信号，如果它在你Linux启动过程中出现拉低又拉高的抖动，基本就是复位问题。别信示波器看到的建立时间，那多半是探头地线没接好。你们用的是哪个安路型号？不同系列的PHY复位时序要求差挺多的，我可以再帮你看具体寄存器。