对c++ / SystemC设计必须设置正确。
不久前,一些EDA供应商绘画芯片设计的一个非常有吸引力的照片后近未来。他们的想法是,架构团队将编写一个完整的描述系统在一些高级语言,通常C / c++ / SystemC, EDA工具的一个新类将自动分区设计到硬件和软件,选择的功能来满足项目的能力/性能/区域(PPA)的目标。这样的工具将生成SystemVerilog RTL的硬件,这将变成一个逻辑晶片(芯片)的合成。工具会生成C代码的软件部分,以项目的形式,可以直接编译,在硬件上运行。系统级描述仍将金色的来源,和硬件工程师和程序员都不需要做任何修改生成的设计和软件。此外,几乎所有的功能验证将在系统级模型。
这是一个美好的愿景,但是这个行业已经能够为它的实现只需要相对较小的步骤。自动分区已被证明是一个非常困难的问题,部分是由于软件和RTL的不同方式。举个例子,硬件一般商店所需最少的数据开始处理。可以处理大量的流媒体数据尽管只有一部分可能在芯片在任何给定的时间点上。微架构的硬件必须反映这一点。软件,另一方面,倾向于保持大内存中的缓冲区。在软件中,数据通常是持续的;在硬件,它的时间。软件也倾向于认为读写内存基本上是免费的,而内存访问硬件可能成本太高。
大多数软件和系统级模型编写没有特定的硬件架构。算法可能读取一系列从内存位置(例如,一个包的头),处理它们,连续写或到另一个组的内存位置。这将是低效的,在硬件并行和流水线。期待EDA工具进行系统级描述和定义整个硬件自动微架构已经超出了当前状态的艺术。可以肯定的是,高级合成(HLS)工具是广泛使用的今天,但他们的输入只是几步比RTL代码更抽象,不是一个C的描述完整的hardware-plus-software系统。在实践中,团队使用C / c++ / SystemC模型体系结构分析在项目早期花很多精力提炼这些模型以便HLS处理和产生结果会议PPA的目标。
缺少一个自动从系统硬件意味着绝大部分验证工作仍然做的RTL设计。即使HLS窄范围内,行业缺乏有效的等价性检查从c++ / SystemC RTL。验证前,搬到更抽象的模型,需要保证下游设计是一致的,不需要re-verified。Logic-versus-schematic (lv)工具给了信心在芯片布局RTL-to-gates等价跳棋确认逻辑合成并没有改变设计功能。不幸的是,HLS用户没有一个类似的解决方案。结果是,许多验证团队关注RTL,尤其是对静态和正式的技术。可能会有一些数量的模拟试验台重用HLS模型和RTL之间,但通常没有连接到建筑的水平。甚至有更少的自动化软件,这通常是书面明确程序将执行架构模型和实际的芯片,并可能在HLS和RTL模型。
尽管宏伟蓝图中的不足,也许这个行业未能达到可以与高级验证。但有改进的机会。许多静态和正式检查定期进行RTL设计也完全适用于高层设计模型。自动检查包括:
添加c++ / SystemC支持静态和正式工具可以更早地发现这些问题在设计过程中,在运行HLS之前。其他RTL正式的应用程序(应用程序)如连通性检查,浮点单元(FPU)验证,RISC-V处理器验证,和协议检查可能适用于高级设计模型。技术存在使用SystemVerilog断言(上海广电)与c++ / SystemC,所以正式的支持有限assertion-based HLS用户验证(酒精)也可用于今天。
尽管验证可以实现高水平,缺乏对等检查意味着自动检查,正式的程序,酒精含量也必须运行在RTL代码。因为大多数错误检测到HLS之前,RTL运行应该很干净。验证工程师可能添加更多的断言或者运行额外的正式应用在这个阶段,所以一些新的bug可能被发现。无论如何,高层验证是一个主要的推动整个芯片项目。它提供了错误的早期检测和校正,更高效的HLS,显著降低努力在RTL阶段,高级设计和验证流几步靠近宏伟蓝图。
更多信息在OneSpin SystemC / c++的解决方案,下载一个摩天观景轮。
|
|
|
|
|
|
|
|
留下一个回复