专家在餐桌上:调试

埃德·斯珀林
半导体工程坐下来和盖伦布莱克,在阿尔特拉高级验证工程师;沃伦Stapleton,高级微设备公司高级研究员;解决方案营销主管斯蒂芬•贝利导师图形;验证营销高级总监迈克尔•Sanie Synopsys对此。以下是摘录的谈话。

SE:IP的数量增加和人们不总是期望的方式进行交互。但它也是黑色盒子。当你看不到里面发生了什么?
布莱克:所以你从FPGA有100万行代码,500000行代码在您的设计,另一个在你testbench 500000行。如果你看看你的错误在哪里,约25%,25%和50%。很多时候你被骗。什么看起来像一个错误实际上是一个问题你没有希望的地方。它并非总是IP块。有时是贵宾,有时你正在使用的工具,给你一个错误的报告。你得通过详细日志找出是错的。也许误解了什么。
Stapleton:分析的一部分,你是否已经配置IP在一个有效的方法。
布莱克:这绝对是一个挑战。
Sanie:你用c++编写代码,没有调试工具。这是一个全新的方式添加到设计问题。
Stapleton如果只有25%的问题是在验证,这将是一个让我们实现目标。没有流程,以确保验证码好。问题的一部分可能是高级模型。没有技术和工具来验证。
布莱克:SystemVerilog代码是硬件和软件一半一半。面向对象的Verilog是软件的一部分。这不是RTL。
贝利它带来了不同的调试模式。你可以看看交易的东西,但它是更高级别的消息传递的事件序列,能够跟那些会变得困难。

SE:可以自动调试的多少钱?
Sanie:有方法来验证软件代码。RTL和正式。有代码覆盖率testbenches,尽管我不知道效果如何。一种新范式,没有自动化,也很难找到这些错误。
贝利我不知道任何自动化调试。我知道的方式呈现更好的观点发生了什么。
布莱克:迈克尔有一个点。我们采取一个放大镜RTL代码覆盖工具。我们有一些RC代码。就好了,如果我们的EDA伙伴会给我们同样的东西我们的客户。这样的分析将有助于我们testbenches所以我们不浪费时间思考我们有一个IP错误当实际上不是一个。
Stapleton:有一些运输工具注入一些你的RTL看看他们是否能赶上一个错误,但是他们不告诉你如果你搞砸了你的验证环境。

SEEDA的客户是说什么?
Sanie:这是非常一致的。这里有新元素参与。一个是模拟/混合信号。另一个原因是低功率,这是一个大问题。这是同样的复杂性与不同口味的。所以想想协议。这些都是非常复杂的。如果您正在使用USB,很复杂,你不能叫你旁边的人说,“我怎么解决这个问题?”
贝利:如果你看看试图找到方法来自动化调试,我们看到的一件事的成功是能够自动追溯。可以追溯值,它不再是那个值。有尝试使用正式的调试,但你遇到缺陷-特别是在SoC水平因为状态空间的爆炸。很快就变得非常有限。

SE:每个人都建立一定程度的形式验证到平台上,对吧?
贝利:是的。我们有很多成功的使用一个正式的引擎与验证的IP。但这并不是我们的主要调试。你必须明白什么是应该做的。我们看过的最佳使用正式的断言缩小至那些错误。我们经常听到虫子出现,人们不能重现模拟可靠,所以我们想出一套窄断言保持聚焦和集中。这样当他们找出问题是,他们可以使用相同的一组断言验证错误是固定的。但这是非常广泛的。大多数人不会去这样的努力。即使你只是这样做预先的IP接口模块,以确保你正确地集成和使用它的方式是为了使用最为人们甚至不这样做。 Third-party IP providers should do that. The other option is raising the abstraction to provide better ways of understanding what’s happening. So if you have a finite state machine, it’s hard to use formal technology or even synthesis-level technology to understand a distributed finite state machine. At least for UPF you can specify the power states in there. But there’s nothing there to more generally describe these things at a system level, which would be very useful. We’re looking at ways to do this so you can understand coherency and coverage metrics at an SoC level. The more we go in that direction, the more the user will have to provide information to help the tool understand the intent, or it will be a broader class of verification IP where you understand the application domain like coherency or the AMBA protocol around it.

SE:听起来好像在调试的问题是直接与复杂性的增加成正比。我们看错了问题吗?一个模块化的方法,如堆积死,简化这个问题?
布莱克:人们太疯狂和幻想。你必须找到方法来处理这个问题所以你不迷惑自己。你可能要关掉一堆特性所以你不用迷惑其他系统的一部分。人们往往过于雄心勃勃,而不是专注于测试的真正目的。
Sanie所以建议少做设计吗?
布莱克:设计而不是更少。但这是一个重要的设计你想要测试的功能。
Sanie:你采取更模块化的方法。
布莱克:关键是不太多的干扰。
贝利:在某种程度上工作。管理复杂性的传统方法是将其分解成可管理的块。但在某种程度上,今天的soc的复杂性,涉及这些交互方式。你仍然需要提供这些场景,因为如果你不你的客户。
布莱克:那不是你要做的唯一的事,肯定的。但这是你应该做的一步。问题是调试,系统级验证。对于调试,你想选择的复杂性。
Stapleton:有关,我见过很多努力进入建筑师,复杂性的方法。这些芯片已经有足够的性能,所以现在是转向更多的定制和高效的设计。正因为如此,一些的复杂性可以被删除。

SE:这不是依赖于应用程序的吗?在数据中心中他们可以得到他们想要尽可能多的性能。
Stapleton:即使是低功率。现在你可以把你的脚从油门,开始担心其他问题。
Sanie:现在你有额外的东西来调试。
贝利:回到分解问题和3 d,这只是添加另一个级别的层次结构。你得到的好处从重用因子降低时间在调试。是重用越多,它就越稳定。如果你可以,你有完全的硅晶片在3 d重用在多个一代又一代的芯片,你节约很多的设计和验证调试。如果你今天需要重用从USB外围块晶片3 d堆栈上,这是一个巨大的储蓄。你仍然要这样做,但是你做一次。
Sanie:IP都是看这个。重用子系统已经发生。

SE:这是指向一个平台策略。我们在哪里呢?
布莱克:我们当然齐心协力子系统。在调试的挑战是当你有这些产品的组合在FPGA方面,和SoC边有一块硬SoC的FPGA。你有软逻辑的IP和SoC本身。当你看这些东西如何交互,复杂性会突飞猛进。如果你看SoC中的严格,我们少做。
Stapleton:随着时间的推移,人们开发子系统和调试,我们发现他们使用的界限并不总是适合新的世界。子系统必须分解和重组成一个不同的子系统。如果你有边界在错误的地方,这是比没有的人。
布莱克:当你看总功率和性能,他们几乎要重做。你想利用技术,没有参与子系统。
Stapleton:在方法论方面,子系统创建领域人们子系统中添加自己的方法论。变得越来越难与不同的子系统集成的一个不同的团队。你仍然可以把各个部分和集成。你没有必要将整个。这通常是一种更好的方法。

第一部分,点击在这里。