抽象的问题

问芯片工程师关于抽象的价值,你可能得到的答案。帮助看到大局而抽象复杂的设计,性能和权力需要注释的数据从详细信息工程团队可以获得在设计流程。

有价值的信息可以来自正确使用抽象。和有大量的错误信息和浪费精力当他们做错了。此外,工程团队需要了解可以用抽象模型和详细需要做什么更精确地权衡精度/速度/努力权衡。

“系统越大,越抽象是必需的,”乔恩•麦克唐纳技术销售工程师在设计和创建业务导师图形。”与此同时,部分系统,各种类型的分析需要更详细的模型。和挑战这更多的是一门艺术,然而,因为有太多的选择水平模型,系统中所有不同的元素。什么水平你需要驱动模型的分析你想做设计的部分你最关心的。”

尽管如此,没有人愿意放弃抽象设计,因为设计没有他们的前景远比与他们生活的挑战。

“作为人类,我们的生活不能没有抽象,”德鲁Wingard说,首席技术官超音速。“这东西太复杂,我们将是如果我们不能抽象呢?我们真的想回到思考我们的芯片级的矩形,将存在于每一个掩模层的?没有办法。抽象是没死。然而,我们需要更有效的方法喂养的信息通常会学习以后在设计过程中所以我们今天可以做出更好的决定。”

高级产品管理组主管弗兰克Schirrmeister系统和验证小组节奏同意:“简单的答案是否定的,抽象是没死。但当使用抽象,用户真的需要知道什么类型的决定他们可以和不能做每一步。”

他指出,从各个层面在设计过程中,这意味着不同的东西。布局/实施工程师、抽象就是一切,没有盖茨和详细的布局信息,这并不是来自一个lib文件。RTL的工程师,抽象是无论你做什么在SystemC级别更高RTL之前。然后,SystemC工程师,抽象是在功能描述的任何要求。

但抽象的理解取决于使用情况下,这是有时人们特定用例混合起来,因为一个特定类型的信息是必要的。

”一个风格的模型或一个抽象的观念能带给你所需的一切,已经被证明是非常困难的,”汤姆德舒特说,高级产品营销经理在仿真器解决方案Synopsys对此。你不能有模型非常快,但是所有的信息,也给你的性能和能力。这就是为什么我们清楚地分开,在顶层,软件开发任务和更多的建筑探索能力和性能发挥作用的地方。下面这些高层仍有那些不同的用例,在高级别上,真正定义的抽象。如果你看一下软件开发用例,这就是功能模型所定义的标准2.0 TLM LT(松散的)现在已经被证明是非常成功的。IP供应商自己和像手臂被推出模型关注功能准确、提供最大模拟速度,因为软件用例。”

德舒特指出,建筑勘探方面非常不同,因为它需要相关信息是想做和权衡。

当然“抽象模型的注释是怎么做这个东西,”Wingard解释道。“如果我们总是从一张白纸开始当我们在做一个新的设计,酒吧会很高,但是我们从来没有从一张白纸开始。我们总是从实质上是基于我们已经做过的事,所以我们通常比我们需要的更多细节。我们有更多的信息比我们需要的那个老东西如何工作。”

的挑战是把正确的信息集的老东西,帮助我们做出正确的决定,他说。“有时候数据帮助我们关注,我们应该花时间在接下来的设计。特征的权力就在过去的设计可以帮助我们强调这些地方我们可能想要更多的时间来节省电力投资于未来的设计。或者,如果我们担心性能特征和下一个设计,我们希望能够带来下一代DRAM技术或下一个速度等级。我有足够的DRAM带宽来满足这个要求吗?当然我们要看看我们的描述从最近的设计,并说,‘这部分不会改变;这部分改变所以我假设我只是规模改变它。“我不会忽视旧的数据集。也许有一个新的视频处理块的设计做一些新的,但它可能是一个我们之前的导数。所以从记忆系统性能的角度来看,我们需要做的就是估计多少交通需要从内存中。我们知道交通的形状; it’s just the quantity that’s uncertain. We can take the information from the old chip and scale it, and that’s going to be probably good enough to get us to the decisions we need to make early in the process.”

这种抽象的目标是帮助架构师理解专注努力和重要的选择产生影响。

“我有过的最好的系统设计师会议或工作的乐趣与擅长抽象,“Wingard说。“他们不相信平。他们一直认为的层次结构的东西,他们非常善于识别系统的哪个部分地区他们应该花费他们的时间,他们能够通过这些隧道非常深入层次结构相关的信息,相关的决策,评估相关的权衡与他们试图优化。我不认为改变。他们练习英语,没有工具,我们还跟人每周的最喜欢的系统设计工具是Excel电子表格。你分析这一水平的设计?如果它可以归结为这些计算看起来像代数、Excel是一个相当好的运行代数的方法。”

最大的挑战是粒度。做组件的设计出现在不同的抽象观点显然足以模拟,分析或模型?

“如果我要试着把它插到一些工具环境,有一个特定的模式,它计算的力量,那么我就不必想出一个数字,我必须想出一个与该模型方程这个东西,”他说。“问题是,建筑师的投资回报在哪里?他们得到一个积极的通过,投资回报吗?这不是关于这个工具的价格,大约多少努力创建这些模型是否买得起。”

工具坚持至少部分问题有困扰验证的发展方向会完全了解如何有效地使用工具。“你需要迫使人们阅读说明书,“Schirrmeister说。“你需要强迫他们读什么模型可以被用于,它不能。”

这里的例子是虚拟平台的概念模型在更高的层面,他说。“总有讨论,‘我需要快,因为我想让它执行软件。我需要它是准确的。但为什么它需要准确吗?它归结为自保”的心态,因为如果你和CAD的工程师团队,他们会告诉你它需要100%准确实现的下一个级别。但那不再是一个抽象。CAD小组成员将会非常担心产品团队使用一个模型将使用一种意想不到的方式,并将得出的结论是有效的数据给出了而是因为他们没有阅读的说明书如何使用这个模型中,他们会遇到麻烦,因为该模型没有正确的忠诚给权力或性能信息。”

所以当专家认为,抽象是必要的,绝对不是死了,他们同意这并不总是产生最优的结果因为各种各样的原因。此外,abstraction-if right-increases完成的价值与每个新的流程节点。

但是抽象有限制。“你不能说,‘我需要完整细节的一切在我的整个系统中,“”表示导师的麦当劳。“你永远不会得到它,仿真永远不会完成,这是不现实的。但是,说,‘我有这个关键打破模块,我需要非常详细的延迟分析,但我有系统的其他部分,我可能很抽象的模型有很大的运动车辆,用户输入时,系统中的其他ecu之间的相互作用,例如,在一个汽车的平台,我可以有很高级的模型的其他元素,其中一个元素是非常详细,非常有价值。我可以在那里做一些非常有用的分析。我可以模型,在不同的抽象级别。我可以做仿真。它运行很快,如果我只建模感兴趣,和我感兴趣的事情的细节,然后我们有一个可行的解决方案。”