变化中的SoC设计流程

　　供应商正越来越多地注意到设计团队的一个需求，那就是早在设计的分区和平面规划阶段，就要拥有初始的布线信息。Mentor Graphics公司布局布线部经理Pravin Madhani认为：“在设计的早期阶段，最大的意外就是堵塞。因此人们会非常早地使用自己的布局布线工具，检查潜在的堵塞问题。”这种趋势转而促使布局布线工具供应商扩展了自己的工具，使之可以用于设计的初期阶段。

　　意外的堵塞问题会产生高昂的后果。Open-Silicon的Madraswala称：“我们一系列块都遭遇了堵塞问题。我们必须返回去，重写RTL来解决这些问题。”这就要对那些块再走一遍验证、设置和综合过程。而Open-Silicon则是从头建立一个通向HiSilicon的RTL设计的快速反馈路径，方法是在中国的HiSilicon公司派驻了一个六人设计团队。

　　第三方IP的堵塞意外可能更糟。例如，IP供应商缺乏资源，不能按你的时间表修改RTL，或者堵塞是出现在一个硬IP块的管脚处。在最差情况下，SoC团队可能不得不更换IP供应商。于是，使设计分区和布局与功率策略保持一致，并且拥有一个顶级布线的早期视图，就成为了任务关键的问题。

　　综合与验证

　　Open-Silicon、Vitesse和Redpine的设计团队并不认为综合是一个大问题。他们更关注如何避免重复地做综合。Madraswala说：“我们把每个RTL块看成像是一个独立的片芯。然后我们在一个足够高的结果品质上，关注每个块在流程中的每个步骤。这样的结果可能是，在时钟插入后，我们只要做一次综合。”Open-Silicon使用自己的综合工具，自动地插入时钟门控。另外，Madraswala称，在架构级的配置用于处理芯片的电源管理。“存在着电源岛，但是，由于电源管理已通过RTL成为显式的，因此我们不需要像CPF一类的东西。”同样，Vitesse的设计使用了大量的时钟门控，但只有一个电源门控的块，而Chadra报告称普通综合流程中没有问题。

　　但是，Redpine采用了一种更积极的电源管理策略，使工具更加复杂。这种方案已影响到了设计流程(图2)。Mattela称，原则上，如果你正确地组织了RTL，并精确地捕捉了自己的电源意图，就应该能将RTL、UPF和电源感知库送入综合步骤，并且获得一个包含全部已就位绝缘体、电平转换器以及控制的网表。但他伤心地说，现实中，“你按了按键，可什么事也没发生。”结构上一切完美无误，但如果用电压感知工具做一次详细的手工验证，就会发现完全不同的情况。

　　图2. Redpine公司的方法包括对电源意图的早期捕获，以及对实现的后期检查。

　　验证似乎采用了不同于综合的新次序。随着复杂性的增加，功能验证开始得更早，在一个更抽象的层级。Vitesse的Chadra称：“我们采用一种基于覆盖的OVM(开放验证方法)方案”。在24端口交换核心与MIPS CPU核心的性能模型中，设计早期启动了该过程，以了解芯片在有流量情况下的动态性能。然后继续对更多细节作验证，直到时钟门控电路和绝缘体就位，测试平台驱动门级模型。Chadra说：“根据我们的需求文档，我们的验证计划中有特定的目标。我们会随着代码覆盖的程度而增加这些目标，指导验证工作。”

　　Redpine的Mattela称，该公司的DVFS设计需要特别小心。部分问题源于逻辑仿真器，因为它并不能说明，信号电平的一个失配是否会对电压岛之间的一根路径造成毁灭性破坏。于是，Redpine的验证工程师求助于手工技术，如强制某节点为三态，看下游会发生什么。Mattela警告说，一部分问题是你永远不知道正在使用的模型的来源。他表示：“不要信任处于多电压状况下的那些模型。你不知道它们的编写者是电子工程师还是软件人员，后者认为一就是一，零就是零。”