中文 英语

争议规范

定义良好和完整的规范是什么以及如何创建它是一个有争议的主题。

人气

由Ann Steffora Mutschler
设计复杂性和复杂性使得在SOC中完全指定块的预期行为越来越困难,但这是设计和验证团队所必需的。如何编写“好”和“完整”功能规范?

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

“第一个,直观地,是系统规范,并且真正描述了该产品,如何使用该产品并影响设计,”导师图形验证的首席科学家哈里福斯特表示。“第二级是IP块规范,它定义了各种IP和他们要做的事情,它们将如何与软件,硬件和其他块进行交互。您倾向于看到的第三级包括自定义界面和互连规范。通常这些是基于标准的。例如,它可能是AMBA总线协议之一 - 这是IP块之间的内部协议。或者它可能是像PCI-Express或USB的外部一个。“

但谁写了那种规格?“通常,您发现的是,如果您查看系统规范,那么倾向于由产品的最终客户倾向于被产品的最终客户编写,”福斯特指出。“我说'遗憾的是'的原因是,虽然它将具有性能要求和设计者需要权力和性能的所有这些方面,但它往往主要集中在产品的最终用户。这就是事情往往崩溃的地方,原因是该规范的其他消费者是设计和验证团队。当然,设计团队采用该规范并试图弄清楚如何实现它并写下与硬件/软件相关的微架构规范。验证团队正在尝试弄清楚将定义一些规范的验证目标。设计和验证团队都有这么多的工作,问题是原始规范不是作为该规范的消费者编写的。换句话说,如果撰写规范的建筑师意识到其中一个消费者是验证团队或设计团队,那么整个行业都可以更好地做得好。“

重复使用问题
另一个复杂的问题是,使事实上的事实是,在今天大多数子系统和SOC中,一个非常小的硬件的实际上是新的设计。“If you look at a big mobile SoC platform, for example, from any of the leading vendors out there I would guess that in a lot of cases they’re only changing maybe 20% of the actual design from one chip to another,” said Cadence Fellow Mike Stellfox. “Part of the answer to the question is you don’t normally sit down from scratch and write a spec for the entire system. You have something existing, and it’s more about specifying the incremental components or changes from the previous generation.”

因此,他说,缺乏好规格。“我来自验证背景,为了做好验证,你需要有一个好的规格。一般而言,它因客户而异,但在那里缺乏非常好的规格,写得很好。很多时候它只是因为除了大多数设计都没有从头开始完成的事实,还没有足够的时间来编写完整的规范。“

然而,这种缺乏规格是关键,Stellfox被声明,“因为如果你去写一个给定块的规格,那就不是一个巨大的挑战。It’s just a matter of carving out the time to say, ‘I’ve got these interfaces that need to send and receive data at these types of throughputs, and then I have these types of features inside of the design, configuration and modes of operation along with different types of processing engines or accelerators or what have you.’ What becomes a bigger challenge is specifying the system behavior in a way that’s predictable, because systems today have multiple cores, multiple masters/accelerators sitting on top of an interconnect fabric, and the big challenge there is to specify the behavior and the performance characteristics of a combination of many of these blocks that make up a subsystem or an SoC.”

到目前为止,许多设计和验证团队依赖于架构师统计分析潜伏和带宽吞吐量等电子表格,而那些往往是最糟糕的估计。As a result, most of the time the project teams overdesign because they don’t really know, in a dynamic situation, for example, whether they will have enough bandwidth if data is being pumped in from the Ethernet to the memory or if there is live video coming in from the camera that needs a certain type of bandwidth to sustain the rates required for processing it inside of an SoC. All of that complexity makes it difficult to specify up front.

“设计人员正在寻找更好的方法来表征其IPS,因为如果您看看大多数SOC - 特别是基于ARM的SOC,则大多数设计是一堆不同的IPS,其中包含一些不同的位。并且这些IPS是高度可配置的,尤其是连接所有IP的互连。您有大量配置,您可以在其中调整互连以获取不同的性能方案。然后,DDR控制器也是高度可配置的,可以针对特定的SOC上下文调整,以满足特定类型的性能要求。真正的挑战是您对您试图瞄准的给定应用空间的要求,您如何表征这些IP,然后在实际设计情况下分析性能而在纸上进行。如果它在纸上或电子表格上,那就太复杂了。有太多的变量和太多未知数,以便真实地,完全指定这种类型的信息,“Stellfox添加。

理想情况下,每个人都希望前面拥有完整的规格。“在一个理想的世界中,它是可能的,但是对于多百万例 - 实例设计,它可能无法将所有集成在一起,”Synopsys的Galaxy实现平台营销总监Mary Ann White表示。“如果您考虑过,则设计方向的方式,大部分时间都将其分解为项目团队。您可以从架构角度呈现RTL,与目标可以是什么,但是应该是约束,但是有时块可能也可能不符合所有这些约束。

语言问题
还有关于规范如何写入的问题。“传统上,系统的规范已经以C / C ++等高级建模语言进行,”Calypto高级工程师高级总监Abhishek Ranjan说。“指定系统更容易,并模拟真正的使用情况。但是,真正的挑战是当您必须将这样的系统移植到硬件规范(RTL)。手动转换令人疑惑和易于出错。带出芯片的压力意味着功能是唯一的目标和性能/功率主要是允许的二次关注点。验证硬件规范(RTL)VIS-A-VIS系统规范(C / C ++)的功能非常具有挑战性,并且不存在良好的正式技术。幸运的是,高级综合已经走了很长的路要走,现代HLS工具从系统级描述(C / C ++)中生成优化的硬件(RTL)进行了相当良好的工作。其中一些工具与正式等效检查有紧密的集成,可以验证生成的RTL的正确性与系统级别描述。这些HLS工具还为权衡性能(吞吐量/延迟等)和权力提供能力。“

然而,这必须与更深刻的设计知识相结合。“What you don’t know can hurt you in the sense that people build specs that are poorly defined in some areas and never complete and you go through the process of finding out the implications of your omissions the hard way,” said Mike Gianfagna, vice president of corporate marketing at Atrenta. “But there is a different way to do it. Our view is that with some methodology and some new technology, you can discover the holes in your spec and the potentially bad consequences of not caring about the details.”

云山朱博士副总裁伊斯坦纳新技术副总裁进一步解释说,架构师通常会写占架构规范,然后RTL Designer拍摄该规范并执行该规范。例如,我们经常看到,例如,RTL Designer决定缓冲区在该IP内部的大。他要估计数据包的速度,可以处理数据包的速度,速度外出,然后他需要一个缓冲区。RTL Designer决定。通常他会保守地做到这一点,但如果他将其设置得太低,则缓冲区将溢出,他将是丢弃的数据包。So an implicit spec that does not show up at the architect’s level of explicit spec is, ‘the FIFO should never overflow’ or ‘the FIFO should never underflow,’ and that’s buried in the RTL—but equally, if not more important to guarantee the functional correctness of the chip.”



发表评论


(注意:此名称将被公开显示)