基于Xilinx FPGA的中断处理

杨媛媛 王晓华 李敏 冯思桐

摘要：在嵌入式系统和各类操作系统中，中断是系统确保实时响应各类异步事件的重要机制。中断驱动系统的合理设计能够保证在完整实现系统功能的同时，保证系统设计的正确性和时间约束。本文研究了典型Xilinx FPGA芯片中的中断处理，提出了一种中断队列处理方法，并在一款基于Xilinx FPGA芯片开发的通信子卡上对该方法进行了验证。

关键词：中断处理;FPGA ;SDK

中断是指处理器受到内部或外部事件触发，暂停当前程序的执行，转而执行处理紧急事件的处理程序，并在该事件处理完后能自动恢复执行原先程序的过程。我们称引起紧急事务的事件为中断事件，处理紧急事务的程序为中断服务例程。在嵌入式系统和各类操作系统中，中断是系统确保实时响应各类异步事件的重要机制。中断驱动系统的合理设计能够保证在完整实现系统功能的同时，保证系统设计的正确性和时间约束。

本文首先介绍了Xillinx FPGA芯片中典型利用中断控制器核进行中断处理的原理，其次典型处理方法存在的弊端，针对性地设计了一种队列中断处理方法，并在一款基于Xilinx FPGA芯片开发的通信子卡上对该方法进行了验证。

1 典型中断处理方法

在进行软件开发时，设计人员可以通过XILLINX公司提供的中断控制器核来进行管理中断。中断控制器核可以同时接收并判别多个外部中断，根据优先级的高低顺序向处理器输送中断请求，当处理器响应中断并进入中断处理例程后，该控制器仍负责对外部中断的管理[5]。开发人员为每一种类型的中断分配中断状态寄存器的某一个比特位，当中断到来时，将对应比特位置1，同时调用对应的中断处理例程进行中断处理，软件人员可通过查看中断状态寄存器的值来获知当前的中断情况，处理完中断后，将对应的中断状态位清零，即完成本次中断处理。中断具有优先级，低优先级的中断处理例程能够被较高优先级的中断中止并挂起，较高优先级的中断处理例程能够被更高级别的中断中止并挂起，形成中断多重嵌套。当最高级别的中断处理完成后，依次继续处理较高优先级的中断和最低优先级的中断。

典型的中断处理方法是在中断处理例程中完成所有中断处理操作和中断任务执行，比如消息的发送，接收消息的处理，状态的记录和变更等等，这就使得中断的处理时间无法预计和控制。中断嵌套的形成加剧了系统时间约束的困难，长时间的中断挂起和嵌套会产生如中断处理超时、资源抢占、数据冲突等多种问题[1，2，7]： （a）中断处理时间过长问题：多重中断嵌套会导致低级别中断事件无法及时被响应和处理完成，由于每个中断仅对应一个比特位，当同一个中断连续到来且得不到及时处理时，会容易产生中断丢失和中断合并;（b）通信异常问题：例如在通信过程中，设备A每隔T时间向设备B发送一次信息包，如果在B接收信息的过程中被其他中断挂起，就可能导致B不能及时发送应答信息到设备A，引发本次通信失败，造成数据丢失[7];（c）数据竞争问题：两个不同优先级中断的处理例程在访问相同公共资源（如共享变量、寄存器、内存单元等）时，可能导致读-写或者写-写访问冲突[7];（d）由于中断事件的发生顺序和发生时间是不确定的，这将导致不同的处理顺序，中断系统中包含的某些设计错误只有在特定的处理顺序之下才会显现出来，故障分析和排查难度将大大增加。中断触发的不可预测性使得系统运行时的时序较复杂。

2 中断队列处理方法

造成中断嵌套诸多问题的原因在于中断任务执行的时间不确定性。针对上述问题，本文设计了一种中断队列处理方法。该方法在主程序中设计了一个中断处理循环队列，队列元素即为按触发顺序存放的中断任务及其关键参数，所有的中断任务按先进先处理的原则进行顺序执行，而被中断触发所调用的中断处理例程仅用于将中断任务相关的关键参数入队列后即可立即退出，返回主程序。

两种方法相比，传统中断处理的流程为中断触发-中断接收-中断任务执行-中断清除-中断结束，而中断队列处理的流程为中断触发-中断接收-中断关键参数入队列-中断清除-中断结束-按队列在主程序中执行中断任务，二者最主要的区别在于典型中断处理的中断任务在中断例程中执行，而中断队列处理方法的中断任务在主程序中执行。

中断队列处理方法没有违背中断嵌套模式中高优先级抢占低优先级中断的原则，当两种中断同时触发，中断控制器会优先调用高优先级的中断处理例程，将高优先级中断任务放入处理队列，主程序则會优先处理高优先级中断任务。由于中断处理例程中仅是将关键参数入列，处理器在中断处理例程中消耗的时间很短，当一个中断到来后能够迅速退出，增强了中断的响应速度，减少了中断丢失或中断合并的概率，最大限度地保护了中断资源，压缩了中断处理时间，解决了中断处理时间过长和通信异常的问题;由在中断产生的空闲时间内，主程序按先进先处理的原则处理队列中的中断任务，只有将当前任务处理完毕之后才会接着处理下一个队列任务，这样中断任务不会同时执行，解决了中断任务嵌套导致的数据竞争问题。

3 验证与对比分析

为了验证上述方法的合理性，我们利用一款在Xillinx FPGA上开发的，基于MicroBlaze软核处理器的通信子卡来进行对比验证。由于软核无操作系统，应用程序直接访问板级资源和处理器特定功能的软件模块的最底层，因此选择在SDK的Standalone模式下进行应用程序开发[4]，利用SDK中开发的应用软件与逻辑联编共同实现子卡的通信功能。由于软核中无操作系统，无法利用进程实现任务功能，只能在主循环中进行顺序执行，只有中断能够打断主循环，处理完中断之后，再回到主循环执行任务。这种工作机制意味着如果软核想要实现多种功能，就必须使用中断触发，且有关中断的处理必须在中断处理例程中全部完成。通过制造中断并观察程序的执行顺序和结果，就可以明确两种方法的区别所在。

我们分别采用普通中断处理方法和队列处理中断方法进行了试验。使用一组实例来描述中断队列处理。从0递增，优先级逐次降低，即中断优先级为0的优先级最高，依次类推。外围设备产生优先级为1的中断，优先级3和4的中断同时产生，紧接着发生优先级为4的中断、优先级为5的中断和优先级2的中断。试验结果如下图所示，方框的大小代表处理时长。

对比图1和图2，当优先级3和优先级4同时发生时，2种策略都会首先触发优先级高的中断。图2中，由于需要在中断处理例程中处理任务，导致处理时间过长，紧随其后的优先级4中断无法被及时处理，直到下一个优先级4的中断到来，根据中断控制器的處理原则，中断状态寄存器对应位保持为1，两个优先级4的中断被合并，当处理完第一个后，中断状态寄存器对应位被清0，丢失一个优先级4中断。而图1在将优先级3的中断参数记录进队列后，立即退出中断处理例程，使得中断控制器能够立刻调用优先级4的中断处理例程，中断处理例程记录当前信息并入队列后退出处理例程，当下一个优先级4的中断到来时，继续入队列，所有中断均被保留。而对于通信子卡而言，若优先级4为消息发送中断，则会导致通信子卡少发送一条消息，导致数据丢失。使用队列处理中断方法能够保证所有优先级的中断例程处理时间相当，因此，能够保证中断被及时接收并根据中断顺序进行处理。

对比图1和图2，优先级5的中断先于优先级2的中断到来，图2中，中断控制器首先进入优先级5的中断处理例程，但由于该程序执行时间较长，执行过程被较高的优先级2所打断，优先级5的中断处理例程被迫挂起，等待优先级2的中断处理例程执行完毕后才能再次执行。若优先级5和优先级2需要访问同一块内存或全局变量，则在优先级2处理完毕后，再次执行的优先级5的中断处理例程的环境参数和被中止前相比已发生了变化，此时再接着处理优先级5的处理程序，会存在数据错误的隐患。对于通信子卡而言，若共享的内存是接收到的数据，则优先级2的处理有可能将接收数据被改变从而导致优先级5拿到的数据是错误的，从而导致通信失败。而在图1中，在进入优先级5的中断处理例程时，仅将中断参数记录进中断处理队列后即退出，接着优先级2中断被触发并入队列。在中断间隙，主程序中依据先到先处理的中断处理队列，将优先级5的任务执行完毕后再接着执行优先级2的任务，涉及的全局变量或内存不会被同时使用，保证程序执行结果的正确性和可靠性。使用队列处理中断方法能够保证所有优先级的中断处理顺序与实际到来的一致，保证中断任务的时序正确和结果的可靠性。

4 总结

本文提出了一种中断队列处理方法。该方法优化了中断处理的方法和时机，在保证中断处理的时序的同时，最大限度地保护中断资源，解决了中断嵌套导致的资源竞争、数据冲突和中断超时等问题。

参考文献：

[1] Silberschatz A， Galvin PB， Gagne G. Operating System Concepts. 8th ed.， Boston： Addison-Wesley Longman Publishing Co.， Inc.，2008.

[2] Walker W，Cragon H G.Interrupt processing in concurrent processors[J].Computer，1995，28（6）：36-46.

[3] PG099-AXI Interrupt Controller （INTC） v4.1-LogiCORE IP Product Guide-Vivado Design Suite-April 6， 2016

[4] UG647-Standalone （v.5.3）-November 18， 2015

[5] 杨政，郝顺义.基于CPLD的中断控制器IP设计[J].现代电子技术，2002，25（6）：19-20，23.

[6] 吴志勇，刘继平，郭元兴.基于FPGA的中断控制器设计[J].通信技术，2018，51（11）：2765-2769.

[7] 周筱羽，顾斌，赵建华，等.中断驱动系统模型检验？[J].软件学报，2015，26（9）：2212-2230.

【通联编辑：唐一东】