关于IP验证中原始中断的check

薛定谔的青蛙

IP中有一个32bit的原始中断寄存器。每当对应位达到产生原始中断的条件后我用后门访问的方式检查了中断是否能正确拉高，但是被提出不应该使用后门访问，不符合硬件行为。
如果我用前门访问去read的话又会出现本次中断产生时，总线还被之前的read给占用了，最后导致check出错。
原始中断又是通过rtl内部逻辑产生的，寄存器模型的期望值无法自动更新。
我怎么想都觉得还是用后门合理。

飞翔的马甲

中断验证确实有这个问题，这一直是个老大难的问题。我在项目中一般是将中断上报路径拆开来验证：

飞翔的马甲

中断验证确实有这个问题，这一直是个老大难的问题。我在项目中一般是将中断上报路径拆开来验证：
(1)用直接用例，通过force中断源，验证中断源到中断寄存器的这段路径，包括中断set、mask、读清或者写清等功能，确保中断上报功能正常；
(2)构造对应的功能用例，通过随机来触发中断源的产生，统计中断源产生的次数，在RM里面进行预期，最终比对中断源的次数。在此过程中，不去动态清除中断状态，只在仿真结束时检查一把中断状态寄存器，重点检查中断源次数是否符合；

飞翔的马甲

另外有个corner点，就是要求在读清或者写清中断的同时，假设又有中断发生，是要求要记录下该中断的。这部分逻辑现在我们都已经用脚本自动生成了，一般不会再有问题，设计上只需要连接中断源即可，所以验证上针对这种corner的验证也弱化了，即使不验也不会有啥问题。

薛定谔的青蛙

飞翔的马甲 发表于 2023-3-31 17:30
中断验证确实有这个问题，这一直是个老大难的问题。我在项目中一般是将中断上报路径拆开来验证：
(1)用直接 ...

感谢回复。您的意思就是先用force大致的判断下中断产生的逻辑是正确的？后续就不做时序上的比对了，只关注中断数目是否正确？

simpleplan

弱弱的问一句 中断是读清吗?所以会有read check的问题？

飞翔的马甲

simpleplan 发表于 2023-4-6 10:18
弱弱的问一句 中断是读清吗?所以会有read check的问题？

一般是写清，计数器是读清

simpleplan

飞翔的马甲 发表于 2023-4-6 11:51
一般是写清，计数器是读清

哦哦。如果在TB里直接wait中断信号是不是更简单点

mioyo

一般有两种触发中断的方式：1.可以通过配置寄存器触发（不一定有）2.通过构造场景触发。检测方式可以采用：断言检测、检测某路径下的该中断信号是否拉高，最后再去读取寄存器看该中断是否上报。一般不建议使用wait等待出发，容易导致仿真卡死

Algo-goer

飞翔的马甲 发表于 2023-4-6 11:51
一般是写清，计数器是读清

请教大佬，如果iopmp中断且一直拉高，那么此时是否还可以写入呢