有争议的规范

由安Steffora Mutschler
设计复杂性和复杂性使得它越来越难以完全指定一块在一个SoC的预期行为,但这是必要的设计和验证团队。你如何写一个“好”和“完整”规范的功能?

事实证明,讨论定义什么是好的和完整的规范和如何创建它是一个有争议的一个。今天,有三个不同层次的规范。

“第一个,凭直觉,是系统规范,这描述了产品,产品是如何使用的,影响设计,”哈利说福斯特,首席科学家验证导师图形。“第二层次是IP块规范,并且定义了各种IPs和他们将要做什么,它们将如何与软件、硬件和其他街区。你今天看到的第三个层次包括自定义接口和互连规范。通常这些都是基于标准的。例如,它可能是一个AMBA总线协议的IP块之间的内部协议。也可能是一个外部一个pci - express或USB等。”

但谁写道,规范呢?“通常你会发现如果你看看系统规范,一个倾向于书面不幸最终客户的产品,”福斯特说。”我说,“不幸的是”的原因是,尽管它将性能要求,所有这些方面,设计师需要力量和性能,它往往是主要关注产品的最终用户。这就是事情往往会分崩离析,原因是其他消费者的规范设计和验证团队。肯定的设计团队需要规范,并试图找出如何实现它并编写硬件/软件相关的微体系结构规范。和验证团队正试图找出定义的验证目标的一些规范。有这么多的工作,在设计和验证团队,问题是最初的规范不是写给他们作为消费者的规范。换句话说,整个行业可以做得更好,如果架构师写的规范意识到消费者之一是验证团队或设计团队。”

重用问题
另一个复杂的问题的是,在大多数子系统和soc的今天,一个非常小的比例的硬件是新设计。“如果你看一个大移动SoC的平台,例如,从任何主要的供应商我猜,在很多情况下他们只改变也许20%的实际芯片设计从一个到另一个,“节奏的迈克Stellfox说。”这个问题的答案的一部分是您通常不坐下来从头编写整个系统的规范。你有现有的,更多关于指定增量组件或变化较前一代。”

因此,有一个缺乏良好的规格,他说。“我来自一个背景和为了做验证,你需要有一个好的规范。一般从客户到客户不同,但有一个缺乏很好的规格都写得清晰和完整。很多时候只是因为没有足够的时间去写一个完整的规范除了大多数设计并不是真的从零开始。”

然而,这种缺乏规范是关键,Stellfox断言,“因为如果你去写一个规范对于一个给定的块,这不是一个巨大的挑战。只是一种雕刻出来的时候说,“我有这些接口,需要在这些类型的发送和接收数据吞吐量,然后我有这些类型的内部特性的设计、配置和操作模式以及不同类型的处理引擎、加速器或你。”变成了一个更大的挑战是指定系统行为的预测,因为今天系统有多个核心,多个硕士/加速器之上的互连结构,和大挑战是指定的行为和性能特征的组合这些块组成一个子系统或一个SoC。”

直到现在,许多设计和验证团队依靠建筑师组建一个电子表格静态分析诸如延迟和带宽吞吐量,这些往往是最坏情况的估计。因此,大多数时候,项目团队保险设计,因为他们真的不知道,在动态情况下,例如,他们是否有足够的带宽,如果数据被应用在以太网到内存或如果有视频直播来自需要某种类型的相机处理所需的带宽来维持利率SoC的里面。所有的复杂性很难指定。

“设计师正在寻找更好的方法来描述他们的ip,因为如果你看看大多数SoCs-especially基于arm SoCs-most设计是一个不同的ip的组合与一些分化中添加。这些IPs是高度可配置的,尤其是互联,连接所有的ip。你有大量的配置,您可以优化互连不同的性能场景。然后,DDR控制器也是高度可配置的,可以针对特定SoC上下文来满足特定类型的性能需求。真正的挑战是对于一个给定的应用程序的需求空间,你想要的目标,如何描述这些IPs然后分析性能在实际设计情况和这样做在纸上。如果是在纸上或在一个电子表格,它太复杂。有太多的变量和太多的未知数,为了真正完全指定类型的信息,”Stellfox补充道。

理想情况下每个人都想要完整的规范。“在一个理想的世界是可能的,但随着multi-million-instance设计,它可能是不可能全部集成在一起,”玛丽安说白色,Synopsys对此星系实现平台的营销总监。“如果你仔细想想,设计处理的方式,它们被划分为项目团队的大部分时间。从架构的角度你可以写RTL的目标和约束,但有时块可能或不可能满足所有的约束。

语言问题
也有问题,如何规范是在第一时间写的。“传统上,系统的规范已经完成在高层建模语言(如C / c++、“说阿布Ranjan)高级Calypto工程总监。“这是容易指定系统和模拟实际使用场景。然而,真正的挑战是当你有这样一个系统移植到硬件规范(RTL)。手动转换繁琐且易出错。推出一个芯片的压力意味着功能是唯一的目标和性能/权力大多处于次要的地位,如果时间允许。验证硬件的功能规范(RTL)与系统规范(C / c++)极具挑战性,没有好的正式技术存在。幸运的是,高层合成已经走了很长的路,现代HLS工具生成优化的硬件方面做得相当好(RTL)从系统级描述(C / c++)。一些这些工具的紧密集成与正式的等价性检查器,可以验证生成的RTL的正确性方面的系统级描述。这些HLS工具还提供能力权衡性能(吞吐量、延迟等)和力量。”

必须加上一个更深层次的知识设计的。“你不知道什么可以伤害你,人们建造规范中定义糟糕的一些地区,从不完整和你经历的过程中发现的影响你遗漏的,”Mike Gianfagna说,企业营销的副总裁Atrenta。“但有一个不同的方式去做。我们的观点是,在一些方法和新技术,你可以发现规范中的漏洞和不关心细节的潜在的不良后果。”

云山朱博士,新技术的副总裁Atrenta进一步解释说,架构师通常写建筑规范,然后RTL设计师需要规范的实现。“我们经常看,例如,RTL设计师决定缓冲应该在多大的IP。他将估计的速度数据包,数据包处理速度,速度,然后他需要一个缓冲。RTL设计决定。通常保守他这样做,但如果他使它过低,则数据包缓冲区溢出,他将会下降。隐式规范,不出现在的建筑师的水平明确的规范,“FIFO不要溢出”或“FIFO绝不下溢,埋在RTL-but同样,如果不是更重要的是保证芯片的功能正确性。”