2026年了，FPGA工程师做RISC-V软核，AXI总线仲裁和中断控制器怎么设计才能不卡顿？

先别急着换中断控制器，把AXI仲裁改成两级优先级再说。你现在的卡顿大概率不是仲裁器不够快，而是所有外设都在抢同一个DDR端口。常见做法是给DMA和中断源分配固定高优先级通道，剩下的外设走轮询，这样突发流量被隔离，延迟抖动自然就下来了。中断那边，PLIC比VIC更适合你这个场景，因为VIC的优先级是静态的，RISC-V软核跑多任务时不够灵活。SiFive的Freedom E310里就有现成的PLIC和仲裁器代码，直接拿过来改端口就行。你现在的总线位宽是多少？如果还是32位，先扩到64位再谈优化。

100MHz下延迟抖动大，先分清是仲裁器本身的问题还是DDR控制器带宽不够。我之前在Artix-7上跑过类似架构，最后发现瓶颈在AXI的outstanding能力，CPU和DMA都发长突发时，DDR控制器排队太长。建议把仲裁改成优先级+轮询混合：固定优先级给中断源和DMA，普通外设走加权轮询，权重按实际带宽需求调。PLIC确实比VIC好，但要注意PLIC的claim/complete流程本身有延迟，如果中断频率很高，可以在PLIC和CPU之间加一个小FIFO缓冲。参考设计除了Freedom E310，也可以看看PULP平台的zero-riscy，它那个中断控制器更精简。你现在外设数量大概几个？如果超过八个，PLIC的优先级配置逻辑会占不少LUT，要提前估算资源。

其实这个问题的核心不是仲裁器算法，而是你整个系统的实时性预算没有拆清楚。100MHz的RISC-V软核，指令执行延迟本身就不可控，所以你要先定义清楚哪些外设的延迟抖动是绝对不能超过某个值的，哪些只是平均带宽够就行。比如DMA搬运数据，它对单次延迟不敏感，但对吞吐率敏感，适合走轮询；而中断源里的定时器或外部紧急信号，它要求的是最坏情况延迟有上界，就必须固定优先级。混合策略的要点在于，固定优先级通道的数量要少，最好只有两三个，否则低优先级外设会被饿死。轮询部分建议用带权重的，比如视频输出给4个权重，UART给1个，这样既公平又能保证关键带宽。中断控制器我强烈建议PLIC，因为VIC在RISC-V上其实是个不太标准的扩展，工具链支持参差不齐。PLIC的好处是支持多级优先级和向量中断，你可以在驱动里动态调整中断优先级，比如某个任务进入临界区时临时提高定时器优先级，退出后再恢复。SiFive的Freedom E310确实是好参考，但它的PLIC是为单核设计的，如果你未来想扩展成双核，就要提前考虑仲裁器的多主端口问题。还有个容易忽略的点：AXI的ID信号。外设发起事务时不要都用同一个ID，否则DDR控制器会强行串行化处理，延迟抖动自然大。给每个外设分配独立的AXI ID，配合outstanding机制，吞吐能明显提升。你在Zynq上做，其实还可以考虑把部分高频外设直接接到PS端的AXI_HP口，绕过PL侧的仲裁器，这样最省事，但中断路径还是要走PLIC。建议先花半天时间用逻辑分析仪抓一下DDR控制器的命令队列，看看是仲裁器在等还是DDR在忙，然后再决定改哪里。你现在跑的是什么操作系统？如果是裸机，PLIC的驱动很直接；要是上了RTOS，优先级映射就要多写一层适配了。方案可以先定下来，但调试顺序很重要：先把所有外设都设成轮询，确认基线延迟，再逐个加固定优先级，这样能定位到是哪个外设造成了抖动。

先把固定优先级通道压到两个以内，DMA和外部紧急中断各占一个，其余全走带权重轮询，这是最不容易翻车的组合。PLIC比VIC强在优先级可动态调，但claim/complete那两步延迟别忽略，中断频率高就在PLIC和CPU之间塞个小FIFO。Freedom E310的仲裁器可以直接抄，但记得把总线位宽先扩到64位再谈别的。你现在外设超过八个了吗？超过的话PLIC的LUT开销要提前算。

个人感觉你现在的卡顿，八成不是仲裁器算法的问题，而是DDR控制器的outstanding能力被吃满了。100MHz软核本身指令延迟就不可控，但AXI总线上真正要命的是长突发排队——CPU和DMA都发128bit突发时，DDR端口的排队深度直接决定抖动上限。所以别急着换中断控制器，先查AXI的outstanding配置，至少给DMA单独开一条高优先级通道，普通外设走加权轮询，权重按实际带宽需求调，比如视频给4、UART给1。中断那边PLIC确实比VIC合适，但注意PLIC的优先级是软件可配的，你可以在驱动里根据当前任务动态调整，这样比静态VIC灵活得多。参考设计除了Freedom E310，也可以看PULP的zero-riscy，它的中断控制器更精简，适合软核场景。另外提醒一句，如果中断频率超过10kHz，PLIC的claim/complete流程本身会有几个周期的抖动，可以考虑在中断服务程序里直接读外设状态寄存器，绕过PLIC的claim步骤。

说个可能被忽略的点：你问的是仲裁和中断，但2026年做软核，真正决定流畅度的是你把这套东西跑在哪个操作系统上。如果只是裸机轮询，那固定优先级加PLIC足够；但一旦上RTOS或者Linux，中断延迟的抖动会从仲裁器转移到任务调度上，PLIC的多级优先级反而可能成为瓶颈——因为高优先级中断频繁触发时，低优先级任务会被饿得很难看。所以建议你先定清楚实时性预算：哪些外设要求最坏情况延迟有上界，哪些只要求平均带宽。前者给固定优先级，后者走轮询，这个边界比选VIC还是PLIC更重要。举个例子，我之前在Artix-7上跑过类似架构，UART和SPI走轮询完全没问题，但以太网的DMA必须固定最高优先级，否则丢包率直接翻倍。另外，如果外设数量超过六个，PLIC的优先级配置逻辑会占不少LUT，Zynq的资源虽然够，但布局布线时序可能会变紧，建议早期就加个时序约束跑一遍。最后说个替代方案：如果实时性实在压不住，可以考虑把仲裁器做成两级——第一级固定优先级选主，第二级轮询选次，这样最坏情况延迟可控，实现也不复杂。你现在的DDR端口位宽是多少？如果是32位，先扩到64位再谈优化，这个改动通常比改仲裁器更有效。