数据驱动的验证开始

半导体工程坐下来讨论数据驱动的验证与渡边耀西,高级软件架构师的节奏;在UltraSoC雅、穆勒、系统架构师;马克·康克林臂主要验证工程师;和陈郝,英特尔资深设计工程师。下面摘录的对话,这是在现场观众面前进行DVCon。

渡边(唐森耀西;莫勒哈难;郝陈;马克康克林。照片由布莱恩·贝利/半导体工程

SE:为什么我们现在看到这么多感兴趣的数据,这将如何影响验证?

渡边:数据驱动的验证已经发生多年来在小范围内,分别。顾客花时间分析验证数据和收集更多的数据,然后思考如何改进,这就是我们看到的上下文中metric-verification UVM和上下文中的签字流程。Metric-driven验证奠定了基础。这些关键因素可供分析。最近,以系统分析的数据,数据科学和机器学习。我们看到了机会,利用这些数据以更系统和自动的方式,允许工程师继续做他们已经做什么,但在一个更透明的方式进行。如果你看这个,它会创建一个闭环验证流。系统地分析数据,收集数据,然后提供一个反馈回路的输入将让你实现你的目标。你可以消除冗余和专注于特定的空白需要填补。这样一个闭环反馈回路会有所帮助。 This is the next phase of verification. In 10 years, young verification engineers will laugh at how senior engineers had to deal with verification closure without having a feedback loop.

莫勒:需要这个数据是巨大的。作为验证工程师,我们收集数据,利用任何我们可以关闭循环。验证从未真正结束。你带了因为你有一定程度的信心,你的设计满足要求。但直到设计部署和运行应用程序,你真的不知道会发生什么。你想收集和挖掘这些数据,然后让别人筛选,找到所有的金块。

陈:是什么促使我们更加注意数据是我们想让我们的设计和验证更加efficient-especially执行部分。一个例子是,我们运行几天正式回归。想象一下,如果我们有项目里程碑和后期设计更改。作为一个验证工程师,会造成相当大的压力是否我可以闭回归前的里程碑。真正促使我们更加注重分析数据。如果有任何可以自动处理的数据驱动的方法,帮助我们提高效率,这将使我们的生活更好。最近的数据挖掘技术的发展,已经发生了很多增强工具。例如,我们可以正式的引擎证明信息从我们的回归和使用这些数据来指导工具来挑选最好的引擎来解决每个正式属性在未来回归。这样的回归可以更快完成。有很长一段时间的数据,并使用这些数据的想法也存在了很长一段时间。 But it’s only recently that we have come up with the techniques to fully automate the process to make it efficient.

康克林:我们只是触及了表面的数据我们可以收集为推动工程效率。我们都做了报道,但如果你真的想从这个角度来看,报道最终被管理的指令而不是工程师能够影响什么。总是有问题,我真的应该关注这些最后的一些事情吗?做验证的数据我们已经在过去的20年不再有趣。你做几件覆盖,你就完成了。但是我们有所有这些大数据,其他人使用。我们这个行业,使他们能够这样做,但是我们刚刚,我们思考它自己。验证的复杂性已经改变了。二十年前你可能设计一个处理器和自己做一个testbench。那是不可能的了。 There’s been expansion into formal and other areas, where there’s an army of verification people for one design, and you never really know when you’re done. That’s one of the problems with verification. But we really have the opportunity to begin collecting and normalizing some data and to gain efficiencies that can impact the final product—and to save the engineers’ time, which is the most important.

SE:这些天你得到的数据好吗?划定好与坏什么数据?

莫勒:如果你发现一个错误,很好数据。但是,即使你没有,你学到一些东西。

康克林:这是一个棘手的问题。获取数据科学家在我们行业是另一个新事物。我们确实有很多好的数据。但即使你会使用这些数据机器学习,后面有很多工作,看看数据是好的。不过,您可以使用这些工具我们现在有一个结果和训练模型,模型可以告诉你是否你的数据是好的,而不是只是猜测。

陈:如果数据被工程师,它必须是用户友好的或以用户为中心好。否则会浪费工程师们的时间。很久以前我曾参与一个芯片级疾病预防控制中心(时钟域交叉)的任务。在那个时候,没有一个聪明的分层疾控中心流。我记得我是多么沮丧当我跑两天疾控中心的工具,回来有超过30000行错误在我的疾病预防控制中心报告。但我仍然需要得到一个数据下拉。我们花了一个多月来收集数据和分析它。有很多芯片级之间的反复讨论和知识产权所有者为了弄清楚的问题是芯片级或IP水平。我们得到了很多的数据,和工程师每天处理大量的数据。但如果数据不是用户友好的或在一个组织良好,很难有效。

SE:它是好还是坏的数据,或者是该应用程序的数据,是好还是坏?今天,有区别吗?

渡边:有一个区别。一个是根据类型的数据。另一个是数据的内容。类型的数据而言,问题是你需要什么类型的数据收集在第一时间。这当然是特定于应用程序的。根据我的经验,甚至需要什么类型的数据,以解决这个问题不是简单的问题。你常常不知道所有的足够的可用类型的数据。如果没有,你有什么类型的数据收集除了你已经拥有什么?这是一个问题。第二个问题是关于内容的数据。 If you now have all the types of data that you think are necessary and then look at the contents of the data and what you’ve collected of a particular type, you see whether that is good enough to do something meaningful. For example, if you try to optimize your verification efficiency and want to run some sort of sensitivity analysis, the parameters of this kind of thing seem to be very sensitive and effective to tune to a particular design condition like buffer maximization. But if you don’t see any variation in the data when you run lots and lots of verification, you cannot figure out anything. So for constrained random type of simulation, that does much the same type of thing all the time. As a result, you don’t see much variance and you cannot learn anything out of that. That’s another dimension of data quality. Even though you know exactly what you have to collect, the contents of the data are not necessarily good enough in order to take any meaningful actions.

莫勒:如果你不知道什么数据收集,你不能怪的数据是错误的。所以你收集了一堆东西,你这堆数据坐在那里,但你不知道怎么看。必须有一些情报指导数据的收集和分析。