其中验证(第2部分)

功能验证已经由工具要求硬件看起来像二十年前的系统被设计。这些限制将芯片置于风险和新的解决问题的方法是姗姗来迟。半导体工程与弗兰克Schirrmeister坐下,集团董事、产品营销系统开发套件节奏;高级主管Maruthy Vedam系统验证工程英特尔;营销副总裁汤姆·安德森Breker;创始人兼首席执行官Vayavya实验室副总裁和John Goodenough设计技术手臂,谈论其中验证。第一部分提供了对其中验证小组成员观点,以及它如何与约束随机生成和UVM。下面摘录,谈话。

SE:测试一致性和安全必须运行在一个周期精确的模型。

前言:是的,您可以开发他们,我们做开发,早期的虚拟模型,但当你想验证更批判性的功能或性能准确模型你需要一个周期,否则就会有不同的行为。

安德森:这是一个重要的点在裸金属测试。你说,如果你只是检测你的硬件与软件的一个版本,你报道是不好的。下一个版本出来的时候,软件不工作了。所以你有正交性的想法,特定的生产软件的能力去操作的设计正交视图操作系统提供的是非常重要的。

前言:我们必须区分验证硬件,我可能需要不同的裸金属层覆盖,并验证管理程序切换器层的顶部是一个关键的硬件集成。我要做的。

SE:场景怎么定义尤其是当我们考虑使用不同的模型和不同类型的知识产权?

Vedam:这是一个非常重要的一点。你有一个非常不同的问题和开放式生态系统之间一个封闭的生态系统。平板电脑或者一个入门级智能手机是封闭的生态系统和你看不到太多的人试图改变这些操作系统。但是如果你观察进入笔记本电脑或服务器的处理器,这是一个完全开放的生态系统。杠杆我们将能够满足我们的一些计划挑战是非常不同的在这两个边缘。理解生态系统是至关重要的,因为这有助于我们优化。如果我们有相同的验证策略对高端服务器和低端智能手机售价不到10美元,我们真的不优化。面临的挑战是看用例。从开放式的另一个挑战,已经存在了很长时间,是兼容性验证。如果你想出一个新的处理器必须确保现有软件和所有版本的现有软件以同样的方式运作。 For closed systems, it is partnering with your customers so that you understand what their problems are and what problems they are solving and how that translates back into use cases in your system. That drives a lot of the validation. This defines the context in which it is to be used and no other. If we can cover that we get much higher quality in that context and get to market faster.

Schirrmeister:我可以很容易地想象,在飞行中,场景等能看视频的时候有电话,确保整个电话不关闭。这是一个定义的东西只需要工作。

SE:在最近的一次节奏峰会据说苹果类似40000年或50000年的场景定义单一设备的操作。

Schirrmeister:这是相当容易充实你的大脑,场景,你想让。有使用模型场景,用户在产品水平和需求渗透。有另一个方面是,有人会提出一个使用模型没有考虑。你没有能力预测他们自己。这是第二个组件是一个内部组件,这是很多的其中验证出现的原因。你不能写这些测试用例,所以你需要确保当谈到的集成组件,你理解他们的属性和特点和要求,从那些你可以确保你写测试或测试系统中一个特定的块是从未使用过的方式将关闭系统,或者它不能支持。它可能不是可伸缩的写你所有的测试,即使在一个基于时尚,虽然比C代码编写,规模可能是有限的所以你需要里面的技术以及你能说这些是我块的特点,然后自动生成的测试强调模块的方式应该是验证。

安德森:问题出现在一个图形的世界如能开发一个模型和一个图是一个模型的一个例子,有了行为的方式是可以生成所有的场景包括那些你可能无法预测。我认为答案是肯定的,但并不容易。一些测试你可能要回去考虑如果这是一个合理的设备,如果不是把一些约束到模型中。我认为这是有可能预测场景使用发现。

前言:今天,人们把用例写下来和他们写的验证计划和农场创建负载测试用例。这些可能是罐头的软件或一组覆盖点和随机刺激。他们试图满足测试计划通过两者的结合。我知道我能做什么,但是我担心我做不到。我知道我将完成我的验证计划,我仍然可以有一个bug逃跑。我感兴趣的不是我定义我要做但周围发生了什么。因此我们采取一个度量为方法,而不是覆盖状态遍历,略有不同。运行的有效载荷,单位水平和约束随机的,或软件在系统层面上,告诉你发生了什么事你关心的事情。我们然后应用的科学,是:我关心的系统建设,这是部分经验。分析错误,看看他们,他们是从哪里来的。 We have looked at Cyclomatic Complexity analysis where you might be comparing two critical events in a system such as an interrupt and a cache eviction event. I can write lots of tests inUVM,或者使用图论方法或软件和最终的结果可能是,在所有这些测试缓存回收总是前两个周期的中断。如果我从来没想过,第一个错误的发生可能是由于缓存驱逐两个周期后中断。我们不仅需要批判性地看它是什么做的,但是它是如何与硬件有关。在这种情况下,这可能意味着看多深的管道是写让贴在主内存和处理器通过连贯的网络。这也许60周期,那么也许你应该看看你的testbench和尝试,使其达到场景通过整个范围。我们开始使用数据分析,大约三、四年前,指导,其中验证应该做什么。关键是要知道你想做什么。