域交叉的噩梦

半导体工程坐下来讨论问题域和亚历克斯Gnusin过境点,设计验证技术Aldec;主任皮特·荷迪、产品管理节奏;乔•Hupcey产品经理和验证产品技术专家导师,西门子业务;斯文拜尔,产品经理设计验证OneSpin;应用工程,戈德温-梅宾科学家Synopsys对此。以下是摘录的讨论。

SE:最初,设计师必须考虑到时钟域交叉(CDC)。然后重新成为一个问题,现在的设计越来越多的电力领域。每次一个信号跨越域边界存在潜在的问题。为什么这个成为一个大问题吗?

荷迪:动态的管理权力是司机。使用正确的时钟频率是很重要的对于每个块,这是驱动多个时钟的爆炸。当我们谈论动态功率管理不仅仅是限制移动或便携设备。今天,高端服务器关心权力。每个人都关心它。

Hupcey:有两个额外的域,你没有提到测试域,这是进入在CDC的舞台以意想不到的方式,和模拟域,也是感兴趣的。时钟域而言,这是很常见的有200多个时钟域。我们看到了50个不同频率或异步时钟。它正在发生soc,这可能有几百“诱导多能性”在他们身上。并不是所有的这些IPs来自同一供应商,所以他们有不同的行为,并没有完全指定。或文档是不够的,这意味着可能会有惊喜当你组装在一起。第三方知识产权的一个重要因素,当你正在与一个SoC。即使在IPs,他们有自己的内部行为,其中可能包括多个域的力量,重置和时钟。

-梅宾:我先看时钟和复位。有很多被集成到一个SoC的IPs,创造了许多时钟。为了减少权力,你做各种各样的特技飞行操纵这些时钟来减少时间和力量。导致更多的领域。我们谈论的是200年到300年的时钟域。最重要的是你有重置域,这些天有很多重置。我从事设计有15重置域。然后你加域。你可能已经60或70电力领域。当你把所有这些在一起有太多的领域。 How do we begin to concurrently solve the problem when each of them influences each other? That is the challenge.

拜尔:我们生活的一切变得越来越大的趋势。但是当你得到太多的东西,每个人都试图做的优化在力量方面,依赖关系的数量得到不同域之间的令人难以置信。

Gnusin:到目前为止,人们已经讨论了同步设计,但是我们也必须考虑到有异步事件去每个地方。任何时候有异步事件有问题。我们必须把这个问题分成两个部分。一部分是meta-stability,第二个是非确定性。Meta-stability意味着我们可能有过多的功率流,这可能导致过热。但非确定性是一个功能性的问题。

SE:似乎对这个问题有两个方面。其中一个是想要用积极的方法来减少权力。另一种是不必要的,部分是由于行业采用的设计方法,即要求时钟频率的变化。即使在IPs有多个域。如果事情变得这么复杂,是不是时间重新思考我们如何做呢?我们要完成,这让我们在吗?

荷迪:复杂性是一个真正的问题。我们看到最近的方式的转变功率优化以后先和美国疾控中心。它必须被认为是在IP级,不能留给芯片集成级别。这两个一开始通常是芯片集成器的责任,和他或她负责趟车并决定在电力领域,当他们将开关。你不需要担心,直到集成阶段。疾控中心通常是在芯片级网表的阶段。这些方法不再是可行的,你必须考虑所有的IP阶段。应对复杂性、long-talked-about IP重用方法现在到处都是绝对真实的。没有人会为一个芯片设计一个IP块实现。总是记住多个芯片实现设计。所以需要IP设计以更强劲的方式。对于那些检查权力意图和时钟域交叉,重置领域跨越——他们必须处理IP设计和芯片集成才离开。

Hupcey:成功的客户每个IP的特点,如果它能跨越多个领域,在三大特征——重置,权力和时钟。变成自己的知识产权,以及描述传达的装配水平和集成级别,那里是另一个迭代。离开它,做平甚至对于一个中型芯片是不可能的。有更多的责任IP制造商”来形容他们的设计。他们需要捕捉到自己的可重用的描述和导致更准确的和更高的吞吐量卷起整件事的时候,就像分层方法与其他工作。你验证RTLIP的组合成一个更大的块,然后集群和整个芯片——相同的活动发生在这里。

拜尔:它基本上是分而治之的良好范例。可以做的一切在块级应该有一次。然后我们有重用方面,已部分覆盖在这个阶段。

Hupcey:有一个有趣的推拉,你不能完全忽视全局视图的芯片,因为在某种程度上它是无用的低层分析如果你不知道时钟树会是什么样子。IPs需要知道他们的相互关系和整体方案。能做些什么是确保至少有一个时钟树定义的第一遍,重启树定义和UPF值的第一遍,所以IP开发人员有一些上下文。

荷迪:这是重点将检查IP水平。你不能假设您正在与一个单芯片的时钟树实现。引入的思想传播时钟过早的IP将在多个不同的实现中重用。具体地说,疾控中心检查,你假设创建健壮的IP,你在哪里不负责实现的地方,你不是假设一个理想的时钟。和你不是假设不同的时钟是异步的,除非特别指定,他们是相关的。这是疾病预防控制中心健壮的IP。是的,你必须注意时钟树最后网表签收,但你不知道的IP设计阶段。

-梅宾:有两件事我们可以做的。首先,有些东西可以在架构级别上完成的。第二,有些东西可以在工具层面完成。设计师面临着两个问题。一个是多少可以确认/验证仅仅通过他们的结构定义。建筑师知道时钟整个SoC架构。然后是重置建筑师知道架构。然后有一个权力架构师。当我们把所有这一切放在一起,我们多快能解决或由结构识别问题?当它进入功能验证,这就是它变得棘手。 How can we ensure that most of the problems can be detected by structural checking and not depend on functional validation? When you look at CDC, RDC or power domain crossing problems, most of it can be done at the structural level. But there are certain things that can’t. However, by looking at the structure you can pass on information that would be helpful for a functional team. With power domains coming into the picture, it becomes a lot more complex because now all IP comes with 10 or 15 power domains. And when you integrate, there are thousands. But the tools are going to optimize and reduce that. More emphasis needs to be put on this so that we have less silicon respins because of this kind of issue.

Gnusin:我已经提到,可以将疾病预防控制中心问题分为亚稳定性问题和非确定性问题。亚稳度可以解决在一个静态方法。我们可以确保我们有必要的人字拖,等。非确定性更难以充分分析、高可靠性的设计要求,如mil /航空。很难确保疾病预防控制中心的设计工作可靠,,目前我们没有完整的解决方案。我们可以正式和做一些补充,但仍是不够的。我们没有一个完整的解决方案的功能验证中心问题。

荷迪:我不同意,你可以处理亚稳定性问题纯粹的结构,因为疾控中心检查会使结构检查有一个同步器,一个域交叉不应该遭受亚稳定性。但他们并不完美,之间有一个权衡多好你想要同步器和故障的可能性。大多数解决方案有某个越来越复杂,以避免故障。例如,某个浏览器FIFO使用灰色的代码,代码检查灰色生成正确的功能检验,不是结构检查。最重要的是,大量的某个将允许偶尔故障,你必须有一些故障的亚稳定性注入方案是否会造成一个问题。这些检查有很多阶段,和90%的时间也许可以用结构检查。你必须先做这些,但也有重要的功能检查之后。