验证是系统地比较两个模型，找出差异的过程。它总是需要两个模型。
曾几何时，严格核查的概念被认为是不必要甚至是浪费的。我还记得我职业生涯早期从事飞行控制计算机的工作。我们没有进行功能验证，也没有创建模型。我们制作了原型，并通过它进行了一些工程测试，主要是为了从结构上验证系统。我们没有测试系统的功能——那是由软件提供的。软件团队对他们的代码进行了一些测试，但很快就进行了飞行测试。他们不仅发现了系统的问题，而且这也是飞机的各个子系统第一次集成在一起。我们甚至不得不安装一个非法的重置开关，这样试飞员就可以在尝试着陆前重新启动一些电脑。
具有讽刺意味的是，当时业界更关心通过大量冗余所看到的安全性，而不是功能正确性。
这对我来说毫无意义，这也是我进入EDA行业并开始在仿真、仿真和加速、跟踪分析、硬件/软件协同验证和验证语言等方面进行开拓的原因之一。值得庆幸的是，航空电子工业从那时起已经取得了很大的进步。
随着时间的推移，验证工程师的概念出现了。起初，他们被认为不如设计工程师有价值，只能手动创建测试。他们是破坏事物的人，而不是创造事物的人。随着。的引入，这种情况开始改变约束随机测试模式生成。验证工程师有他们自己复杂的语言，他们开发了方法和指标来跟踪进展，在许多方面，他们比仍然固守日渐过时的语言和方法的设计社区更能推动行业的发展。
我一直是Accellera的支持者便携式刺激尽管我愿意做任何事情来改变它的名字——而且我尝试过。它有可能允许验证向未来迈出另一大步，并将抽象提升到设计语言之上。它从以前语言的许多错误中吸取了教训。
一个非常重要的方面是它支持增量开发和改进。这意味着你不需要有一个完整的模型才有用。开发可以从只包括系统最重要的方面开始，并避免任何可能包含特定实现的内容。在做出架构决策时，可以将额外的细节或功能添加到模型中，这些都不会使使用部分模型所做的任何事情无效。辉煌!
它也可以自上而下或自下而上或两者的混合开发。转型!我们现在有了真正的验证重用，不仅是在项目内部，而且是跨项目的。这将大大提高核查进程的效率和效力。如果它能得到改进，验证所花费的时间又会减少，那么所有人的目光都将回到改进设计流程上——这是它迫切需要的。
令我沮丧的是，在我最近在DVCon主持的一次圆桌会议上，第一部分是在这里发表，几位小组成员建议，这个新模型也许应该是推动实施过程的一个。合成工具应该直接在此基础上操作以生成实现。虽然我不反对这是可能的，但令我震惊的是，该语言的许多属性并不是针对设计的，因此会被浪费。
那么，验证又如何呢?如果该模型成为设计模型，如何验证它?我们似乎回到了最开始的地方，在那里，我们可以推断出规范已经变得如此高水平，以至于我们可以查看它，理解它，并确定其中没有错误。显然是时候试飞了!即使这在今天是正确的，它将使我们能够考虑更高复杂性的系统，我们很快就会回到系统验证过程变得必要的地步。
也许我只是太老了，紧紧抓住过去的方式，但对我来说，验证的方向是正确的，仍然需要更多的工作。我不确定我是否已经准备好接受一切都可以正确的结构和规格从来没有包含错误。
|
|
|
|
|
|
|
|
留下回复