验证方法在发展，但发展缓慢

半导体工程公司(Semiconductor Engineering)坐下来讨论了数字双胞胎，以及在汽车和航空航天等各种行业开发和验证新芯片所需的条件治之软件；Mike Thompson, OpenHW验证任务组的工程总监;保罗·格雷科夫斯基，技术营销经理Arteris IP；Shantanu Ganguly，产品营销副总裁节奏；和Mark Olen，产品管理总监西门子EDA．以下是那次谈话的节选。本讨论的第1部分是在这里．第二部分是在这里．

SE:系统公司已经向硅设计公司介绍了数字双胞胎的好处。这将成为我们核查方法的一部分吗?

Ganguly当前，国防工业已经拥抱了数字双胞胎。我确实看到商业公司越来越多地谈论数字双胞胎。我和正在做数字双胞胎的客户谈过，这是一个非常强大的概念。但如果我是在商业领域，我如何在三年内开发出一个数字双胞胎?我不能。产品将更快地被替换。

Lapides:传统上，汽车行业的设计周期要长得多。但现在他们正在转向更复杂的soc，并试图大幅压缩他们的日程安排。这真的会成为汽车soc的问题吗?

克拉我们过去做垂直细分市场的分析。系统专家，半导体专家，硅专家。现在汽车和系统行业的人就像半导体行业的人一样。当我们进入3d集成电路，有了堆叠和封装，你将会有硅人试图像系统人一样行事。这些行业都有各自的优势。硅具有高度的复杂性，但它们也存在上市时间问题。现在所有的人都聚集在一起，很多人都在处理问题。即使是老练的人也在处理他们过去没有经历过或面对过的问题。

Ganguly问题是，如果你看一辆现代汽车或一架喷气式战斗机，从概念上讲，它们是系统的系统。如果我正在建造一架喷气式战斗机，我可以在8年或10年的计划中完成它。设计周期大概是十年。它经历了之前模型的漫长阶段，等等。对于这些较新的汽车，他们在大约一年内推出了一个新的变种。好吧，他们有一个底线，但在一年内推出一辆全新的汽车是一个很棒的声明。形势正在演变，这是一个紧迫的问题。就像20世纪20年代发展起来的汽油汽车一样，有很多参与者，然后出现了整合。但要建立一个系统的系统，即使是一年内的重大调整，也存在挑战。将会有部署后的问题，而且所有的问题都不会是软件。

Graykowski:在ADAS市场，那些不习惯为汽车制造芯片的公司现在也开始参与进来。突然，他们面临着ISO 26262。这不仅仅是参加培训。这是你如何把它应用到SoC上。是的，我们已经把它应用到汽车层面的安全气囊和类似的东西。但是你怎么进入SoC呢?那么这个AI块呢?你需要整个SoC的可追溯性，从开始到结束。这是一个很大的变化。工程师们还没有准备好，他们只会认为必须做更多的文书工作，负担更重。

Ganguly:进入汽车行业的传统消费硅公司对此并不了解。他们真的不想接受这个级别的认证，或者说他们很难接受。在我可以宣布我的产品完成之前，你需要通过所有这些漏洞。然后有一些公司进来，看看必须做的事情的规模，他们不喜欢它，但它必须做。

LapidesISO 26262可能类似于30或35年前，当时晶圆厂必须达到ISO 9000。经过认证的过程，这是一个巨大的混乱，必要的培训，它造成了严重的延误。但我们必须完成它。这可能是我们将要经历的一个有趣的不连续点。

Ganguly但这是一次性的交易，每个人都会随大流，然后就完事了。你是这么想的?

Lapides:也许吧，但你谈到了一年的时间表，然后是硅的民主化。有些人是新来的，也许他们很天真，因为他们认为自己可以把事情做好。他们可以，但他们没有意识到需要在人员、工具和培训这些人方面进行投资。不仅仅是雇人。这里涉及到培训，以使他们的专业知识达到成功所需的水平。

SE:软件的概念出现过几次。随着世界向特定领域计算发展，我们是否应该讨论硬件/软件协同设计?我们已经多次提到在硬件上运行真正的软件的必要性，但是是否存在一种用于硬件/软件协同验证的方法呢?谁来为此负责呢?

Ganguly:我们将越来越多地看到这一点。例如，Arm有一组测试，以确保您的产品能够引导Linux，并基本上达到规定的验证级别。有了这个，你可以很早就清理你的设计。这是一个很好的例子。类似地，有人可以获得我们的系统vip并运行这些内容，以确保当所有的IP功能聚集在一起时，能够启动Linux所需的一切都在那里。从根本上说，这是一个非常好的过程。它基本上是一种确保您的RTL已为软件做好准备的方法。我们能否提取出能够运行软件所需要的东西，将其提取到您更早运行的微操作和端口序列，甚至是作为验证套件的一部分的裸金属?你会看到越来越多这样的例子。越来越多的人会理解这一点，更多的产品会进化出来。

汤普森行业需要一个标准的流程来做到这一点。像Arm这样的组织在这方面经验丰富，他们将能够自己构建这种方法并取得成功。较小的组织，新进入者，将需要一些帮助。我就以UVM为例。UVM标准就在那里，它有很好的文档，得到很好的支持。你可以从街上雇佣了解它的人，并部署它。这是正确的，因为有一组规则来做这件事。这就是构建块或测试工作台的方法。这就是你如何把它提升到系统层面，等等。对于硬件/软件的共同验证、共同验证、代码开发，无论你想怎么称呼它，我们都可以使用类似的方法来为世界上的其他团队提供一个成功的框架。

Ganguly问题在于，从概念上讲，这将取决于你所关注的功能，在更一般的情况下，你不能这样做。

汤普森:在UVM出现之前，他们也是这么说的，而UVM反驳了这一点。如果你概念化这个，抽象这个，你就可以提出一个抽象的框架，几乎适用于每个块。UVM实际上可以处理你扔给它的任何块，因为它是抽象的。我们需要将这种抽象应用于硬件和软件。

Ganguly冒着轻率的风险，这有点像说，“这里有一袋水泥，你可以盖房子，你可以盖摩天大楼，你可以建一座桥。”

汤普森我们如何使用这些水泥袋?我需要一个框架来使用它。标准尺寸的铲子，一个标准尺寸的搅拌机，一些关于水，水泥和砾石用量的指南。我们需要这样的东西。它只是一袋工具。这就是我们今天所处的位置。“这儿有一袋工具。它们是干什么用的?铲子的哪一端承载着碎石?我们需要能够提供这样的指导。 And UVM does that for block-level verification.

Lapides在国防工业中，这些大项目总是有一个系统工程师来领导技术方面的工作，他更像是一个多面手。也许他们在某个领域有专长。在批评了大盒子模拟器之前，我承认它们有自己的位置。有一个定义良好的系统方法和验证方法，从最开始的虚拟原型开始，到模拟器上的硬件/软件协同验证。还有更多的RTL，还有FPGA原型，还有数字双胞胎。但是真正在足够广泛和深入的层面上理解这些问题，并有一个全面的验证计划的人——这样的人很少。我们真的没有做任何事情来培养这样的工程师。

Graykowski:我想回到你对UVM的评论。我还记得VMM和UVM刚问世的日子。有少数人知道怎么做，而且做得很好。薇拉和斯派曼也是如此。那些人发了财。他们很受欢迎。也许我们需要的是找到这样的人，然后其他人会跟着说，‘嘿，我真的可以用这个做点什么。但研究方法必须改进。然后我们就会有知道自己在做什么的专家。

汤普森:最近有人向我提出了一个问题，想找一个负责DevOps验证的人。“你认识什么人吗?”‘搞验证的DevOps是什么鬼?但你仔细想想，基本上就是有人坐在那里写那些Python脚本从覆盖数据库中抓取东西。这是我大学毕业时还不存在的工作职能。

Lapides:在90年代早期，人们把“设计编译器”写在简历上。是金子做的。还有斯佩曼的人。是否存在一种新的工作定义，既有利于工具方面的业务，也有利于工程师，因为它可以成为解决方案的另一个方面?

汤普森:我曾经为一家系统公司工作，该公司是模拟器的大用户，他们有一个使用模拟器的流程。这和他们贴出芯片的过程完全一样，只是里程碑的意义有所不同。基本上，在一天结束的时候，我们会有一个模拟器用完整的芯片或者分数芯片，或者别的什么。这是要在上面运行的软件。这是检查表，然后我们就说我们完成了。“它看起来很像清单上写的，但没有生产出任何GDS。

Ganguly这一步代价很高，不应该掉以轻心。

汤普森:我是一个真正的超级信徒。我相信这是顾客的推手，而不是供应商的推手。但只有需要它的客户才会这样做，因为它很贵。