这些都是在接口级完成的明显测试，在内部结构进行的类似验证测试和在接口级实现的验证策略是很类似的。显然，要测试整个验证空间，即使只是一个设计模块的接口，也不可能像前述的样本设备一样简单。可能的操作是250行×250列×224色×16大小，或16.7×1016.所有操作的组合数是这个数值的平方，或大于1034.这里真正的挑战是创建那些能够揭露设计问题的组合，并将这些问题标识为需要立刻关注的区方面。

　　使用断言揭露早期问题

　　由于对设计驱动了激励，因此断言可以及早发现问题。要添加的断言包括不能超过249（行地址和列地址的最大可能值）的行地址和列地址，以及不能超过16的大小字段。确定断言并采用HDL覆盖分析后，需要对设计驱动激励。这可以通过约束随机测试实现。约束随机测试产生反馈到测试平台的设备处理事务，表明被识别的测试点已被覆盖。如果设计空间非常大，约束随机测试就不能包含测试点没有覆盖的边界条件。这种测试不用创建使用HDL覆盖工具达到100%覆盖的激励。但是，在设计中遍历所有状态并覆盖所有条件并不能保证设备被完全验证。

　　软件代码作为激励

　　对于一个超过1034个组合的验证空间来说，让实际的设备操作执行所有必需组合是不太可能的。应当把重点放在设备会运行的那些操作上，对那些理论上可能不会使用的操作要减少花费时间。最简单快捷的方法是找到可驱动设备的现有代码。这可能是诊断代码，驱动程序代码或应用程序级算法。每个这样的代码均提供了不同的验证级别，并揭露了不同类型的问题，因此，应当尝试获得和使用所有类型的代码。

　　对于新的设计，代码很可能不存在，但对于下一代产品的设计，一些代码常常可以得到。如果这些代码存在，设计的激励在几乎不耗费精力或成本的情况下就可以得到。如果代码不存在，但合作方愿意在设计周期前期创建代码，那么也可以轻松地创建激励。最后，如果验证团队需要创建代码，通过编写C代码来为设计创建复杂多样的激励比使用任何其它语言都更容易。大电流电感

 3/4   首页 上一页 1 2 3 4 下一页 尾页