早自五年前PCI Express(PCIe)的初始阶段,PCIe就已成了实质上跨越所有细分市场并占主导地位的互连协议。今天,所有主要芯片组厂商正将PCIe技术植入到他们的芯片组中。PCIe技术已广泛应用在服务器、工作站、存储系统、路由器、交换机和一系列测量应用中。PCIe的迅速推广导致了许多不同的PCIe规范的实现方式。
尽管理论上来说,每一个实现方式应遵从PCIe规范且应具有与所有其他的实现方式互操作的能力。但实际的情况却是,有一些既不一致又不具备互操作性的设备进入市场。因为那时有人认为尽管非一致的或不具互操作性的器件流片后的维修成本很高,但与其投放市场后所获得的收益来比还是少很多,并认为确保器件流片前的一致性和互操作性验证是任何PCIe开发过程中最为重要的挑战。
意识到这笔巨大成本后,EDA行业发布了许多能够解决这个挑战的方案。这些方案从高级验证、断言语言和方??延伸到功能覆盖工具和特定协议一致性测试的工具包。即便是有许多解决方案可从EDA行业获得,但为确保流片前器件的一致性和互操作性而选择最佳的解决方案,也要求对导致器件不一致或互操作性的问题有一个透彻的理解。
一致性验证的挑战
对大多数的产品开发团队来说,验证过程始于验证计划的创立。协议规范是针对任何验证计划的主要输入之一。通过甚至是最简单的测量,PCIe基础规范是一个足以将最富经验的产品开发团队弄混淆的复杂规范。这种复杂性不仅是由于其庞大的文档数量,而且是因为这样一个事实:为了完全理解规范,开发团队要求理解所有基本规范。执行该过程是相当困难的,况且目前包括PCIe基础规范在内的许多规范仍在不断改进中。保持PCIe基础规范的更新需要花费大量的、在验证过程的关键阶段通常无法获得的宝贵时间。所以,当考虑流片前一致性解决方案时,开发团队要避免停留在对规范的每个细节的更新上。因此,选择一个专注于PCIe规范的开发团队所实现的解决方案尤为关键。该专业团队须确保其解决方案与改进中的规范保持同步更新。
当通读完PCIe基础规范或任何与之相关规范后,你会设想器件将如何工作。尽管诸如PCI-SIG的标准机构在大力删除其规范中的所有模棱两可的内容,但这些规范保留对互操作性的开放,并且假定这些规范是给开发人员阅读的。最好的情况是,这些假设在开发人员之间以及和该规范的作者(规范的作者是PCI-SIG)意图是一致的。然而,实际的情况往往是缺乏这种一致性。更为普遍的是,开发人员之间有着不同的设想。在这种情况下,这些设想的差异只有在广泛的讨论之后才能形成解决方案,这就往往要求规范作者的指导。最坏的情况是所有开发人员的设想一致,但这些设想都与规范的意图不一致。在这种情况下,开发出来的设备自然是不符合规范要求的。因此,任何流片前一致性解决方案都是很关键的,这些解决方案主要是针对已确认的或已解决的所有方案开发过程中产生的设想。通常来说,随着更多的开发人员复查和应用该解决方案,这些设想会确立和解决。这样的结果是,当一个解决方案在行业中获得更广泛的认同后,在解决方案的精确性上将会更有信心。
由于器件的尺寸及其复杂性方面的难度持续增加、例举的任务要比验证少许多,所有可能的情况都变得相当困难,以及无法被验证过程所覆盖的器件特性正呈现上升的趋势。尽管PCIe规范详细描述了成百上千个寄存器、多个复杂状态机和许多可选功能,但这并不是PCIe规范独有的问题。针对这个整个行业所面临的问题,覆盖驱动验证方法已开发出来并得到成功的验证。这些方法通常包含断言语句在器件中的位置及其验证环境。一旦断言被加入,随机激励将应用在该器件上且覆盖统计会被采集,这在覆盖驱动验证方法中是十分有用的。任何流片前一致性解决方案必须包含一套健壮的断言和一个针对覆盖统计采集的工具。
IP验证带来的挑战
随着PCIe的日新月异,PCIe设计核正迅速的成为商用部件。通常,当可以从许多厂家获得多种PCIe设计核时,通过对器件从零开始来构造一个PCIe设计核的附加值是微乎其微的。理想的情况是,所有市面上的PCIe设计核应该是免费纠错的。然而,实际的情况往往并非如此。所以,采用PCIe设计核的开发团队所面临的挑战是确定怎样处理可能验证过的核。大多数的开发团队既没有这样做,也不希望为一个准验证的PCIe设计核分配资源去再验证。于是,一个可提供完全的、自包含验证环境的流片前一致性解决方案可起到填补这个缺口的作用。但前提条件是假定该解决方案可以轻易的与设备集成在一起。此外,只要为这个任务分配一定的资源,任何由该解决方案指定的问题一定可轻易的被调试和解决。
互操作性被定义为一个设备与其他设备通信的能力。在PCIe领域,只有当设备能正确的管理其连接和信息交换时,才意味着两个设备是具备互操作性的。针对一个要成为完全互操作性的设备来说,该设备需能够与市面上所有可能的设备进行连接和信息交换。互操作性在流片前环境中是相当困难的。在理想的流片前互操作性验证环境中,两个PCIe设备的模型是完整的,且使用了适当的激励。开发团队在构造这种类型的互操作性环境过程中所面临的第一个挑战是找到一个合适的和自愿的合作伙伴。一旦确定了合作伙伴且分派了法律义务,该问题将会成为集成两种模式的一种。其中一个模型对开发团队而言是缺乏经验的。随着问题的出现,要求开发团队为两个设备提供一定程度上的支持。解决这些问题是一件相当繁琐的任务,因为调试通常包含来自不同组织的众多开发人员。通常,将这些问题融合在一起从而避免大量的这类测试。