上帝说这世界上的东西都太复杂，于是就有了分层，让专业的“Task”做专业的事情。
针对数字IC验证复杂的输入场景也是一样，也需要分而治之。
上面是2012 年，Mentor针对功能验证的一个研究结果，我们目前功能验证的绝大部分时间都花费在了Debug（DUT的bug/验证环境的bug/测试用例的bug）。
而在UVM验证环境中最复杂的就是不同场景的激励生成，所以对sequence的控制会决定测试用例构造和仿真调试的难易程度。让验证工程师的生活更美好，必须要擅长处理复杂场景的验证环境搭建。
类似于自动挡汽车的驾驶流程，简单的操作即可驱车前进，原因就是在汽车内部这些简单的命令被转换为较小的任务。这里的任务也可以分为**“需要变化的”和“不需要变化”**。
很自然的，在我们日常生活中，需要变化的或者说需要配置的参数仅仅是速度和方向而已。自动驾驶需要解决的就是在大多数使用场景下不需要再手动配置速度和方向参数，同时在特殊场景下提供手动再配置的开关。
再回到“层次化sequences”的话题，如下图所示：
将sequences分为四层，最底层就是各个driver需要处理的最基本的事务。S3、S2和S1就是前文提到的“分而治之”，以产生各种需要的激励，层次越多控制就越精细。其中，根据实际应用场景的输入约束，这些sequence之间可能是顺序的，也可能是并行的。
假设seq A代表速度控制，seq B 代表车灯控制，seq C代表方向控制。那么在一般的使用场景下，只需要继承一个test\_base，然后再使用factory机制override或者config seq A/seq B/seq C即可，所以层次化的sequences也提供良好的代码重用，降低验证用例出错的概率。
以简单的APB slave为例，两个最基本的base sequence 就是 AHB\_BASE\_WRITE和AHB\_BASE\_READ. 基于这两个base sequence，可以建立循环N次的读写sequence, AHB\_LOOP\_WRITE 和 AHB\_LOOP\_READ。基于循环sequence，还可以建立背靠背循环读写sequence(连续写N次，再连续读N次), WRITE\_FOLLOWED\_BY\_READ 。
最后，在不同的测试用例里面可以继承这个WRITE\_FOLLOWED\_BY\_READ sequence,通过配置不同的写次数（N），不同的读次数（X）以及不同的读写之间延时，就可以覆盖所有我们想要实现的读写场景。
作者：XinXin_Hu
原文链接：https://mp.weixin.qq.com/s/6fzOcZrPPYP6FU8Ah7jAVw
授权转自数字芯片实验室公众号，请勿二次转载。
推荐阅读
更多数字IC设计技术干货等请关注数字芯片实验室专栏。
