项目场景：

（1）fpga与国产龙芯3A3000 cpu主板通过pcie总线进行通信；
（2）主板采用rework国产实时嵌入式操作系统，fpga部分为xlinx a7系列及 xilinx 7x pcie ip核；
（3）fpga板卡负责接收主板控制指令完成数据采集、dma数据传输等功能。

问题描述

项目中遇到的问题：

在调试pcie中断时，出现龙芯未识别到pcie设备发来的中断请求，因此对中断问题进行排查。
这里吐槽下龙芯适配的reworks操作系统，不支持msi中断，只能支持传统中断inta，不过pcie对传统中断和msi中断都是支持的，用法都差不多。

原因分析：

原因主要有两种：
（1）fpga部分发出了中断请求，主板中断控制器未识别到；
（2）fpga部分根本未发出中断请求。
从上面两个原因去分析问题，问题定位过程：
（1）根据主板pcie接口电路设计，与fpga板卡对接的pcie为cpu的f0 pcie通道，根据龙芯3a3000 cpu手册，主机分配的中断line为32 - 35之间；
（2）主板根据硬件设计，定位pcie设备中断line是哪个值，根据软件人员排查，32-35没有一个中断产生。。。。
（3）那么问题可能出在fpga板卡部分，那么就查阅pg054 ip核手册，分析xilinx 7x pcie ip中断应用时序图，此时序图如下：
传统中断时序图
关于时序图的说明看下图：
在这里插入图片描述
（4）其中关键信号：cfg_interrupt、cfg_interrupt_assert、cfg_interrupt_rdy；结合时序图，cfg_interrupt为用户中断请求信号，给ip核，ip会产生cfg_interrupt_rdy给用户，告知已经接收到中断请求；但是要注意cfg_interrupt_assert信号的说明及时序图。
在这里插入图片描述
我们在发出cfg_interrupt请求时，cfg_interrupt_assert信号需要拉高保持，这段时间为assert时段；根据这个说明再去排查代码，确实是cfg_interrupt_assert未拉高原因导致中断未发出；此刻主机能够收到中断请求了，但是一直进中断。。。。。继续看手册说明。
（5）手册中有一段话：
After the user application has determined that the interrupt has been serviced, it asserts cfg_interrupt while deasserting cfg_interrupt_assert to deassert the interrupt。
意识是：用户发出cfg_interrupt请求时，ip会产生cfg_interrupt_rdy给用户，告知已经接收到中断请求，用户会一直保持cfg_interrupt_assert为高电平，不知道啥时候结束，这个时候需要用户自己决定什么时候去deassert中断请求，因此，在用户发出中断请求后需要一直保持，但是需要在合适的时候再deassert，否则主机一直进中断。