确保实现和验证匹配客户的需求。
验证结果的常见设计视图开始全面验证计划,覆盖每一个需求定义在规范和用例中,建筑的定义,和其他相关文件。测试是开发覆盖每一个功能的验证计划。这些运行测试和调试,发现设计中的问题解决。这个过程迭代直到同意的覆盖水平。功能覆盖这个过程的指标衡量,它适用的范围内。主要的电子设计自动化(EDA)工具厂商运行模拟,积累覆盖率统计数据,以及这些指标有助于进一步推进。但这并不是故事的全部结果。覆盖措施合规验证计划,这是几个步骤从客户的需求。设计师怎么知道一路上关键信息没有删除或添加?
一切都在内部开发的功能规范/要求事项。不可能完全关闭客户的需求和实现之间的循环/验证,除非这些都包括在分析中。现在价值链被压缩,systems-on-chip (soc)变得更特定于应用程序的。客户期望设计调整他们的确切需求,所以他们定义为需求必须匹配实现/验证。它将不会收到如果客户发现他们将补丁不匹配。
这里的挑战是,可能是一个好坏参半的输入定义:词,PDF,基于dita文档、电子表格、仿真软件、SysML或虚拟模型原型,和软件加载,应该在最后的硬件上运行(可能与一些变化的免税额)。可能还有记录要求门,Jama连接,或类似的格式。如何验证团队,设计团队,或架构师审核,实现和验证符合要求吗?他们将做他们的绝对最好的,当然,但是具体在哪里和可审计的过程,以确保每一个需求映射到一个实现实现和实现充分的验证?
为了更具体的,假设有一个功能,一个重要的客户想要的,但是没有人需要。也许通过监督或误解,这个功能并不使它成为功能规范/要求。它时常发生。甚至100%的覆盖率的理想不会抓住这个问题的报道只是一样好验证计划。有一个大问题,如果验证计划不准确反映需求。
或者假设在设计的过程中,团队决定它不能实现什么规范要求,但另一种方法是使用相信它会实现的一样好,甚至更好。团队不知道这种变化将影响性能在某些罕见但重要的用例。也许这将是在模拟?也许是,但它是非常困难的在系统级综合测试。这是一个真正的风险问题变化将生存到硅。
运行Word文档之间的等价性检查,虚拟模型,和过户水平(RTL)在我们的有生之年不可能是可能的,但它不需要。系统工程师和软件开发团队已经积极使用需求跟踪是一个非常健壮的方法来跟踪高层之间的通信和实现级要求,实现,验证和测试。这种支持可跟踪性需求跟踪使用需求交换格式(ReqIF)与门和Jama等平台连接的工具。
尽管这些工具设计,便于采用在软件世界中,他们不懂硬件语义。他们支持“异物”连杆连接设计和验证数据,但这些联系正确的负担落在设计和验证工程师。这可能不是那么糟糕,如果只有几百跟踪对象。但想到内存映射,中断地图,地图输入输出多路复用技术;这些可以运行成千上万的对象或更多。手动更新这些对象通过设计更改和重新分区变得极其困难,如果不是不可能的。
更好的方法是通过可追溯性管理,在客户端可以连接到工具如ReqIF和直接构件设计和验证团队跟踪。理解设计语义允许可能推断出需求之间的联系,实现和保持这些正确跟踪项目发展。这种方法可以确保可审计的联系从客户规范,通过设计要求,最终实现SoC。
这是可追溯性,可以完成验证的结果较低的客观影响SoC设计团队。可追溯性支持你会发现Arteris和谐跟踪。
|
|
|
|
|
|
|
|
留下一个回复