中断验证 - 21ic电子网

IP level验证

中断信号生成符合预期
status/mask/clear
中断信息查询

SoC level验证

集成连线
成功进入对应的interrupt handler
接反
异步脉冲中断集成
中断仲裁
CPU自身的中断

中断从角色上分为生成端和接收端，从验证角度上可以理解为IP级验证和SoC级别验证。处理中断的接收端一般都为CPU，而CPU内部也可以生成中断，比如计时器中断，或者软件中断。这个时候CPU即是发起端也是接收端。

IP level验证

1、中断信号生成符合预期

一般CPU会接收到所有的中断信号，从软件角度进入中断处理程序(interrupt handler)来处理这些中断，需要注意表明中断触发的信号形式可以有多种，主要的有两种：高电平触发和脉冲触发。需要保证给出中断线的各个模块按specification要求给出高电平或脉冲。有些公司把这种形式用interrupt mode来描述。

2、status/mask/clear

主流的中断设计都会涵盖3中类型的寄存器:status,mask,clear

mask验证分为mask和unmask，mask掉的即使有中断也发不出来，unmask如实把中断发出去。

clear验证，中断产生后可以被清掉，同时要保证清掉后中断仍然可以再次生成。

status验证，一般存的都是经过mask/unmask处理后的中断，看是否符合预期。一旦中断被清掉，看是否跟着变化。

3、中断信息查询

从软件的角度讲，一旦有中断，就会进入中断处理程序。中断处理程序一般会访问一堆寄存器了解情况，这个时候从验证角度来看，一旦有中断产生，需要验证所有的相关的寄存器是否正确，一般主要是状态寄存器。

SoC level验证

1、集成连线

主要查看是否有漏接或者接错的情况。一般需要有人整理出发起端和接收端对应的信号。然后以独热码的方式force发起端的信号，查看所有的接收端信号，理应只有一个对应的信号拉起。一般中断的对应关系有interrupt id来做映射。可以抽象成一个bus function model去替换CPU，方便每个集成的人员去使用和检查。

2、成功进入对应的interrupt handler

在soc level一旦发起端生成了正确的中断，接收端/CPU需要进入对应的中断处理程序(interrupt handler)。这个需要从软件的角度做end to end的测试。

3、接反

由于发起端和接受端针对中断信号形式不一定一样。比如发起端认为中断产生时信号为低电平，而接收端认为是高电平。这个时候在soc集成的时候需要给发起端的中断信号加上取反的逻辑。一旦取反没有做，整个SoC一上电，CPU刚使能中断控制器，就会不断进入中断处理程序，陷入死循环。

具体验证方法挺简单的，需要有一条软件的程序，使能所有的中断源，看是否会陷入死循环。

4、异步脉冲中断集成

从设计的角度来看，如果接收端的频率比发起端慢，发起端就不应该用脉冲的形式，一旦发起端和接收端的时钟不是同步的，必然会产生接收端采样不到发起端中断的情况。这个需要在收集中断信息的时候就提出来进行修改。

而且即使接收端的频率比发起端快，在项目后期，后端为了收敛时序的时候，很有可能会出现降低接收端频率的操作。异步脉冲存在相当大的风险。

5、中断仲裁

当有多个中断同时触发，为了区分到底优先处理哪个中断。一般会给每个中断源分配一个优先级，然后硬件依次处理所有的中断。更加复杂的IP甚至会有各种工作模式，工作模式有各自的中断，工作模式本身也有优先级的区分。比如armA系列的exception level 0~3，或者risc-v的机器模式和超级用户模式。

所有的仲裁结果需要验证人员来检查是否符合预期。可以在cycle级别的同时force所有中断，如果有工作模式的区别还需要软件先配置好具体的工作模式。这里需要验证人员在软件程序和验证环境之间构造通信机制，软件告诉验证环境什么时候可以force相关信号。

如果force所有中断，其实潜在了还测试了接收端是否有能力pending那么多中断，依次处理。

不过实现中断仲裁的一般是作为发起端的CPU，而CPU一般是第三方给的，所以其实可以默认没有问题。

6、CPU自身的中断

CPU一般作为中断的接收端，但是CPU自身的模块也会产生中断比如计时器中断，软件中断，所以CPU也可以当做中断的发起端。一般SoC的CPU都来自第三方，可以认为不存在bug，所以CPU作为发起端需要验证的情况个人认为分为以下两种：

作为外部中断复杂场景的干扰项
为原型认证/firmware团队尝试配置一下这些中断，保障基本的使用流程