系统与设计
的意见

系统设计的下一个抽象层次

我们真的需要一个可执行的规范?也许不是。

受欢迎程度

最近有很多的再次讨论的下一个级别为芯片设计设计抽象。我们在那了吗?我们会到达那里吗?SystemC吗?UML / SysML也许吗?我采取的方法简单地宣称胜利:在过去20年里我们已经超出RTL支离破碎的方式在不同的地区。然而,人类的限制我们的信息处理能力可能阻碍我们去一个完全统一的单一设计入口,可能成为“普遍可执行规范”,一切都是自动派生。但话又说回来,帮助可能从验证的路上,我们在快节奏工作找到一个新的方式来表达系统的场景,这很可能成为一个设计入门级。

让我们稍微回滚。这实际上是一个非常个人的故事,我不得不承认很多错误的假设我20年前提出的。那时,约1995,我让几个芯片设计,抽象的耗尽。原来我已经开始具有完全自定义布局和门电路级设计和逻辑综合的出现曾承诺将我们寄存器传输级(RTL)。Synopsys对此行为编译器已经在1994年推出,我相信阿尔特·德·Geus以前乐观地预测大量tape-outs我们今年将达到2000。加里·史密斯在1996年创造了这个术语ESL,同年,虚拟插座联盟成立。1997年节奏宣布Felix倡议,承诺让function-architecture合作设计一个现实和诱惑我搬到加州去运行它的产品管理。我们将简单地向上移动在抽象,闪电快。

所以今天,20年后,我们搬在抽象吗?是的!我们上升的方式时,我们以为我们会预测未来1995年?地狱不!

的根本缺陷的假设是,至少在Felix倡议,认为会有一个可执行的规范,一切可以派生和自动化。发生相反的是,几乎所有的发展方面在抽象向上移动,但分散的方式,而不是领导一定要可以派生的一个描述。除了硬件和软件的分离,随着IP重用,能单独在这一点上创建新功能及其组装。

对于每一个功能,设计团队有8个基本方法集成到他们的发展:

1。重用一个硬件块如果现成硬件IP。
2。手动在硬件实现的函数作为一个新的块。这是美好的。
3所示。使用高级合成创建硬件作为一个新的块。
4所示。使用一个可扩展的和可配置的处理器核心创建一个硬件/软件实现。
5。使用工具来创建一个特定于应用程序的指令处理器(ASIP)及其相关软件。
6。使用软件自动化创建软件从系统模型(如UML或SysML)和一个标准的处理器上运行它。
7所示。手动实现软件和一个标准的处理器上运行它。
8。重用的软件模块如果现成软件知识产权。

例3到6所有使用更高级别的描述作为入口点,但每一个都是不同的。高级合成是由事务级描述SystemC或C;asip核磁测井等IP或工具生成的使用特定的描述,丽莎卸载或领带XTensa描述语言。软件可以自动生成从UML描述。最接近的更高层次的统一描述实际SysML或UML,等专有产品Mathworks仿真软件,从硬件模块和软件模块可以自动生成。

(图形安Steffora Mutschler故事说明了不同的选项,黄色框显示更高级别的描述。)

现在,当涉及到将所有的硬件块联系在一起,不管他们是否重复使用或由上述六个选项之一,用户有四个不同的选项(也显示在图的底部在安妮的故事)。

1。手动连接块(好运)。
2。自动组装块使用由臂连接自动生成的安巴设计师,超音速或Arteris。
3所示。综合协议从更高层次互连协议描述。
4所示。使用一个完全可编程的NoC,决定在运行时连接完全。

除了第一(手动)和最后一个在运行时()方法创建片上互连,其他项目提高抽象层次。例如,手臂苏格拉底和安巴设计师环境信息在节奏互连等工具工作台设置场景的性能分析是必要的,和有特定工具自动创建配置不同的互连拓扑从更高层次的描述。

所以在很多方面我们已经在抽象。胜利!

好,但我们在UML通用可执行规范,SysML或一些专有的描述,可以派生的所有吗?不。第一眼看到,目前尚不清楚如何到达那里。据我所知,没有一个我见过的人类到目前为止能理解所有方面的硬件/软件组合来表达一个统一的描述。复杂性已经太多,可能会继续这样做对高端设计。这真的可能是一个人类贪婪的限制日益增长的复杂性,迄今为止,有效阻止我们进入一个更高层次的可执行的描述。然而,在第二视力,我们可能会从不同的角度,一个正在发展的Accellera便携式刺激组,定义验证场景。

我们看到更多的专业化发生时验证,目前证人在Accellera PSWG。当定义场景,三个项目是重要的。

•首先,用户正在寻找垂直重用IP系统的验证环境。
•第二,他们使用的横向重用通过仿真模拟,FPGA和甚至完整的芯片。
•第三项是场景重用跨学科——将缓存一致性测试,本身明确定义,仍然工作在设计时关闭,回来了?之间的交换是两个不同的专家,每个人对其他不知道太多,但现在类似于uml描述能够合并他们的场景。这是如下图所示,两个用户使用不同的缓存一致性方面的专业知识和权力关闭使用类似于uml描述定义了他们的场景。第三个用户可以直观地理解它们,并将它们合并成一个用例场景相结合。瞧!

Merged-Use-Cases-Perspec

烙在回来这几天验证设计,这将是很难表达这一切在一个可执行的规范。然而,一组放在一起的场景定义系统规范应该是什么,由不同的expertise-stakeholders,与Perspec_System匹配器等技术成为可能,我们的商业工具Accellera PSWG空间。

我们已经在抽象正如上文所述块及其组装,我们仍相当远离找到一个,统一描述的一切在一个复杂的设计可以派生。但如前所述,使用的场景定义可能最终带给我们更高层次设计的入口点。然后直到分离的IP创建和IP重用IP组装工作很好,实际上,所以移动上面的时间还不清楚。



1评论

库尔特·舒勒 说:

弗兰克,我很高兴你写这篇文章。一个伟大的系统级设计和描述方法的总结!关于UML,我记得我和杰里米•班尼特(Tenison CTO)有多个在2005年讨论这些问题当我们一起工作在Tenison设计自动化,并得出这样的结论,即一个UML条目或“黄金模式”将是最好的方式来描述和定义一个系统,并提供可追溯性从需求通过HW / SW /用例的实现。不幸的是,杰里米的解决方案之前,他们的时间。但也许不再!

留下一个回复


(注意:这个名字会显示公开)

Baidu