IP开发时如何考虑复用覆盖率

如何在开发IP的同时去巩固集成和复用覆盖率？IP的某些功能和性能是可以配置的，需要考虑的是IP被各种合理配置后的工作是否都能够正常，将功能覆盖率先整理为层次化的抽象功能覆盖率模型，称之为cover model。

这是一篇关于IP开发时如何考虑复用覆盖率的论文。就硬件设计IP而言，我们无非是在实现IP，或者集成IP。就目前情形来看，IP的实现越来越多被集中在大型公司。一方面是由于他们有更多的经验来保证可配置化的IP可以满足各种用户需求，另外一方面是由于他们的客户基础深厚，同时高质量的IP研发成本和大量的silicon-proven可以形成良好的业务发展。目前多数公司在重要IP上面都会采用商业IP，这来自于多方面的考虑。作为Verifier可能会有更多的机会去一家SoC公司，从事于定制模块、核心知识模块或者IP模块的验证。SoC中至少有三分之一以上的工作都属于IP模块的集成验证，SoC verifier看待IP更多的角度是从集成验证出发的。

这次摘录的这篇论文的视角则是从IP开发的角度出发的。正好借这个机会，小编可以有空梳理一下IP在设计和验证两方面开发的流程。由于文章中以PCIe为例，我接下来关于IP开发流程和集成验证流程的叙述也以PCIe为例吧。

对于一个成熟的PCIe IP而言，一家商业IP公司可能出售它的硬件设计IP，也可能出售它的验证IP，或者两者都出售。例如Synopsys就同时出售它的设计IP和验证IP，也就是说这家大型的IP百货公司在出售给你设计方案的同时，还会建议你购买他家的验证方案。无论是设计还是验证，你都首先需要一个PCIe功能模式的配置。这个配置是结合SoC的架构来制定的，从前期架构研究中会选择合适的功能、性能以及功耗等参数。Designer和verifier将都使用这个配置文件来生成定制化的设计IP或者验证IP。那么可以将配对的设计IP和验证IP进行测试环境搭建，继而进行IP级或者SoC级的验证工作。但是在验证的过程中，我们如何完成在IP级和SoC级的验证量化呢？这肯定离不开覆盖率，尤其是功能覆盖率。但是往往功能覆盖率不会伴随着设计IP或者验证IP一并生成，这是为什么？其实还是跟高度可配置化的IP本身有关。在这篇论文中就PCIe设计IP为例，讲述了针对可配置化IP定义功能覆盖率的困难之处。

由于IP的某些功能和性能是可以配置的，比如有一些功能可能在配置之后就会被禁止（静态的），也有一些功能可能通过仿真时的寄存器配置被禁止（动态的），那么这些不同的配置就对定义一种通用的功能覆盖率模型提出了挑战。从文章来看，PCIe IP的开发者在验证时已经很苦恼，因为他们面临的挑战要远大于SoC verifier，前者需要考虑所有的配置可能，而后者只需要选择有限的配置进行集成验证。或者这样说，前者需要考虑的是IP被各种合理配置后的工作是否都能够正常，而后者需要考虑的是IP在被SoC集成后是否能够良好地融入系统。

IP集成的一个问题是，IP提供者不知道IP在被各种客户集成时，集成方式是否正确；而IP使用者也几乎对于生成的IP其自身的可靠性、在IP系统级和SoC级的测试覆盖情况抱有模糊的认识。挡在双方中间的障碍来自于他们缺少一个清晰的数据来表明对方的测试完成状况。从这篇文章来看，如果IP提供商可以在生成定制IP的同时也能够生成定制的功能覆盖率，那么这样的一份覆盖率无论对于IP开发者在验证IP自身，或者是IP集成者在验证IP的集成时，都将产生指导性的帮助。

那么是否存在这样一份伴随着IP配置文件而可以定制生成的功能覆盖率呢？这篇文章给出了一种解决方案。从这篇文章最后的结论部分来看，可配置化的功能覆盖率将伴对应着每一种配置化的IP，而在测试这么多的IP配置时，开发者可以利用这些功能覆盖率来衡量IP的验证完备情况。如果这样一份功能覆盖率也能够伴随着IP一同交给SoC集成方，在IP集成时就可以综合IP级和SoC级的验证情况来收集反馈在这份功能覆盖率模型上。这样如果IP提供方和集成方都基于同一个功能覆盖率模型进行交流，那么也将更容易一起回顾IP的功能测试和集成情况。

接下来小编概括这篇论文是如何实现高度可配置化IP的功能覆盖率定制情况的。

将功能覆盖率先整理为层次化的抽象功能覆盖率模型，称之为cover model。

抽象覆盖率模型由多个block model构成，这些block model所代表的某一项重要的功能最终合并起来，就可以构成整体的功能情况，即cover model。

对于block model各自的树状结构，其每一个树状末端构成了一个覆盖变量，cover variable。但是这些覆盖变量并不指向具体的信号，而仍然从抽象上来描述它所要测试的功能、关系的值域。

利用cover variable，可以将它们放置，或者交叉生成新的覆盖率，称之为cover group。

这些树状的覆盖率模型包含的底层cover variable和cover group被收入到Excel表格中。伴随它们的，还有配置化变量。配置化变量之所以重要是因为不同的设定可能决定了某些cover variable的值域范围，或者是否存在某些cover variable。

层次化放置的Excel表格被Perl脚本读取，并且产生了层次化的SystemVerilog covergroup。这些covergroup也伴随着block model，与各个功能一一对应，构成了层次关系，最终作为一个定制化产生的cover model。

这篇论文同我现在做的一些在SoC级定义功能覆盖率的方式不谋而合。首先功能覆盖率在沉淀之前，需要有抽象的功能定义，那么不同的功能将可以作为独立的block model。复杂的功能可以进一步拆解为child block model，最终拆解到不能拆分为之，那么不能拆分的点就是cover variable。也许有的公司习惯于将功能测试点以平铺的方式（plain text）展开，这对应的也将是平铺的SV cover group定义；如果你定义的功能点是抽丝剥茧，从Excel表格开始就得到了脚本处理的保障，那么你可以一开始将设计拆分为几大功能，接下来利用层次化方法定义子一级的block model。

树状的覆盖率模型与平铺的覆盖率模型相比有什么优势呢？它容易做测试回顾（review）和覆盖率分析，而对于这篇论文中的IP验证，树状结构也有利于一些变量的层次化传递和脚本的针对性处理。从复用角度来看，如果实现了Excel到SV cover group的脚本化流程，那么树状结构的功能点拆分也有利于日后的维护，例如从树状结构中删除某一个节点及其以下的所有子节点（即删除某一项功能），又例如将IP级的覆盖率树状结构嫁接到SoC系统的覆盖率树状结构中，使其成为其中的某一个节点，都是可行的方法。

结语

Excel到SV cover group的自动化是一个合适的方向，但在实现过程中，还需要理清，如何将抽象的功能点测试具象到各个cover group。比如功能点测试之间可能具有包含的关系，比如某些功能点测试可能仍然过于抽象需要进一步细分，这篇论文利用脚本结合Excel中的IP配置变量来生成了层次化的功能覆盖率模型，是一个不错的尝试。这个覆盖率如果可以从IP级贯穿到SoC级，那么将能够更好地衡量IP集成测试的情况。