有时，我渴望回忆起自己早年做设计工程师的日子，那时的事情比现在简单多了。当我在做我的第一个ASIC时，没有想过使用来自第三方供应商的知识产权功能块(IP)，因为没有来自第三方供应商的IP功能块这样的东西。
类似地，我们没有谈论“连接结构”之类的东西，因为我们所拥有的只是将逻辑门和寄存器连接在一起的电线。
正如我之前提到的，除了铅笔和纸，我们没有任何设计工具。功能验证包括团队的其他成员查看您的原理图并提出尖锐的问题，如“这个比特应该做什么?”以及“你到底为什么要这样做?”类似地，时间验证包括我们根据经验确定关键路径，然后手工将所有门和线延迟相加。
我发现我的大脑很难理解当今片上系统(SoC)设计的复杂性，其中许多涉及数百个IP块，每个IP块可以包含数百万个门。举个例子，我最近接触了一个数十亿美元的晶体管设备，目的是在边缘执行人工智能(AI)和机器学习(ML)任务。
对此，我的下意识反应是“人们究竟如何构思并实现如此复杂的设备?”当然，我知道部分答案是尽可能使用第三方IP，这样你就可以专注于自己内部开发的“秘密武器”IP，这将使你的产品与竞争对手的产品区别开来。另一个难题是充分利用当今令人难以置信的强大和复杂的电子设计自动化(EDA)工具。
说到这个，我刚刚和普拉卡什·纳拉因聊天，他是真正的意图．我很喜欢Real Intent这样的公司。在那个我们称之为90年代的年代，有很多规模较小的EDA公司，每个公司都为派对带来一些特别的东西。随着时间的推移，许多小型公司被Cadence、Mentor (Mentor本身已被西门子收购)和Synopsys等行业巨头收购。
还有像Real Intent这样的公司，他们拥有很棒的技术，但却以某种方式保持了独立性。部分原因在于，Real Intent的工具并不是为了取代其他玩家的工具，而是为了增强其他产品的功能。
Real Intent成立于1998年，最初专注于基于断言的验证形式的正式验证产品。尽管Real Intent的产品仍在使用正式技术，但该公司已经发展到更专注于其静态签收工具套件，这些工具可以加速早期功能验证，并为数字设计提供高级签收。
Real Intent的静态签收产品功能包括多模式时钟域交叉、多场景重置域交叉、多测试模式DFT、多策略RTL检测、设计初始化和正式检测。
这些产品在性能、容量、准确性和完整性方面领先于市场。因此，全球有50多家主要半导体公司使用Real Intent的工具。其中包括一些世界上最大的公司，他们正在为移动、网络、电信、显示图形和无数其他应用开发soc。
在我们继续讨论之前，为了弄清楚接下来会发生什么，我们也许应该提醒自己，今天的许多设计都是非常注重权力的。其中一个方面是，不同的功能块在不使用时可能会进入睡眠状态(或关闭电源)(这些块可能会使用特殊的数据保留寄存器来维护关键数据，而大部分块则会打瞌睡)。其他块可能受制于动态电压和/或频率缩放，用于在应用程序和/或特定任务的基础上调整功率和性能之间的权衡。
这些都不像我说的那么简单(哈哈)。组成设计的IP块可能具有复杂而微妙的与功率相关的相互依赖性，使得这些功耗意识强的项目的设计、验证和调试更加复杂。
设计人员解决这种复杂性的一种方法是使用统一电源格式(UPF)，这是电气和电子工程师协会(IEEE)标准的流行名称，用于在电子设计自动化的电源优化中指定电源意图。该标准最初的IEEE 1801-2009版本是基于Accellera组织的捐赠，在撰写本文时，当前的版本是IEEE 1801-2018。
我们还应该讨论的一点是，我们倾向于将流程可视化，就像SoC设计流程一样，从左向右流动。术语“左移测试”最初是由Larry Smith在2001年提出的，关于软件和系统测试，其中测试在生命周期的早期执行(即，在项目时间轴上向左移动)。这就是“早而经常地测试”这句格言的前半部分。同样，在一般的电子设计，特别是SoC设计的背景下，“左移”被理解为在开发过程中使用工具和方法尽早(比以前可能的更早)发现和解决问题。
所有这些都让我们回到了我与Prakash的谈话中，他告诉我，当今设计中的许多高级问题最终都是连接错误——也就是说，连接结构中的问题将所有东西连接在一起，其中一些结构可能是自动生成的。
我们不是简单地谈论丢失的连接(尽管这种情况发生的频率比您想象的要高)，而是更微妙的问题，例如位翻转，例如源的位1、2和3连接到目标的位3、2和1。另一个潜在的问题是基台问题，其中连接逻辑被错误地插入了两个IP块之间，这两个IP块本来是要相互对接的。
为了解决这些问题，Real Intent最近推出了他们的SafeConnect连接和故障工具。像Real Intent套件的其他成员一样，SafeConnect是一个静态分析工具，这意味着它不需要测试台或模拟器。相反，它在开发周期的早期分析设计的寄存器传输级(RTL)设计，允许设计人员快速识别和解决任何连接问题。
左移，早期RTL和netlist结束(来源:Real Intent)
除了RTL, SafeConnect还可以利用设计的UPF表示以及用户定义的规则库。此外，在逻辑综合之后，SafeConnect可以在设计的门级网列表视图上重新运行。
许多SoC设计团队已经通过Tcl脚本执行基本的连接检查，创建和维护这些脚本可能是一场噩梦。还有一个事实是，在数百万门SoC设计上运行这些类型的Tcl脚本是一个缓慢而痛苦的过程。此外，Tcl脚本所能做的只是告诉您有问题，但在调试该问题时几乎没有用处。
Prakash表示，相比之下，SafeConnect具有高度定制和非常简单的方法，可以根据用户的IP和/或SoC设计流程定制规则。一旦开发完成，这个规则库就很容易使用和维护。由于SafeConnect以原生方式使用这些规则，因此它提供了业内最高的速度和容量，在几分钟内执行块级分析，而Tcl脚本和形式化分析在类似块上执行需要数小时。而且，为了在我们的寓意蛋糕上添加一大块打过的奶油，SafeConnect与Real Intent熟悉的iDebug环境完全集成，从而方便了跟踪每个bug的任务。
像往常一样，我只是试探性地谈到了这个主题，几乎没有暗示SafeConnect提供的功能。如果你想了解更多关于Real Intent的内容，为什么不给他们发邮件或打电话，让他们告诉你更多信息(不要忘记告诉他们“Max说‘Hi!’”)。
我只希望我能回到过去，告诉我在1980年左右的ASIC设计师同行们，未来注定会以SoC设计、验证和调试工具和技术的形式出现。你呢?你怎么看这一切?
