EEPW论坛

在设计流程后期，大量版图已严格定义，这时要纠正错误将是一项艰巨而令人沮丧的任务，而且经常会导致流片延迟。最佳实践是，在整个设计实施流程期间多次运行片上系统(SoC) 的全芯片验证，使设计团队能够在设计流程的早期阶段识别出模块实例之间的芯片级违规（此时纠正违规的影响较小），并帮助他们获得更高质量的结果。

但是，对于在任何给定时间都包含多个进展中的元素的设计流程而言，将每个模块的最新物理版图数据收集到一起并合并到单个  OASIS  或  GDSII  数据库以用于全芯片验证，这是必要之举，但同时也可能是一个非常困难而且耗时的过程。芯片级设计人员需要一种快速、可靠的方法，以固定的频率执行这些设计规则检查 (DRC)，尽快确定布局规划或模块中存在的任何问题。实施数据合并流程时如果能够考虑到连续构建并行设计实施流程的需求，则可以最大限度减少甚至消除耗时的活动，同时确保快速、准确地解决任何设计问题。

数据库格式转换

全芯片数据库始终使用 GDS 或 OASIS 格式。在以芯片级 OASIS 或 GDS 文件的形式从布局和布线 (P&R) 工具导出版图时，可以引用已经采用 OASIS/GDS 格式的外部模块或知识产权 (IP) 以用于合并。但是，如果某些外部模块数据无法以  OASIS/GDS  格式提供给芯片级团队，则会妨碍芯片级导出和全芯片验证操作，直到所有外部源全部转换为止。

采用的内部数据合并流程如果使用了类似 OpenAccess 这样的中间数据库，可能会造成意外的瓶颈。这类设计流程需要将所有的模块和芯片级设计转换为 Open Access 格式并以该格式存储。然后，将此最终的 OpenAccess 芯片级数据库设计导出为 GDS/OASIS 格式，如图 1 所示。随着模块和芯片级设计被导出到 OASIS/GDS 芯片级数据库，芯片级模块抽象将被物理设计模块所取代。以 OASIS/GDS 格式导出合并后的芯片级设计，将会创建一个完整的层次化数据库。这一多重转换流程的运行时间要求限制了它的使用，一些客户报告，一个全芯片的数据合并需要多达 20 个小时才能完成。

图 1：“芯片级”中间数据库要求设计团队执行多次数据转换，这会导致大量的时间损失。

除非无可避免地要求使用中间数据库格式，否则在物理验证迭代期间不鼓励使用中间数据库格式，以确保设计团队能够加快周转速度。通过最大限度减少或消除中间转换的使用，团队将获得更多的时间来分析结果和修复版图，同时仍能满足其交付排程。

数据库更新

如果使用过期引用导出芯片级数据，则  DRC  运行的输出违规将会失效。芯片级团队将不得不重新运行数据导出和合并，从而给设计排程造成延迟。

但是，模块开发通常与芯片级实施并行进行，这意味着将在内部和外部团队之间分配工作量。对于任何  SoC，一次可能会有数十个设计处于不同的开发阶段。此外，并行工作的模块开发团队可能位于不同的内部地点，甚至位于不同的时区（图 2）。即使他们位于同一地点，其工作排程也可能不同。一些模块可能被分配给没有内部网络访问权限的外部团队或承包商，而这可能会造成数据传输延迟。在计划数据合并流程时，必须充分考虑所有这些问题，确保在每次运行中期芯片级 DRC 时所有数据都是最新的。

图  2：在运行全芯片  DRC  之前，必须用最新的物理版图数据替换正在并行开发的芯片模块布局。与远程或外部设计团队协作时，这项任务会更加困难。

制定和沟通用于全芯片数据合并和物理验证的排程提供了一种有助于缓解以上问题的手段。如果所有供应商都很清楚全芯片验证运行的排程，他们就能确保其模块数据是最新的并以所需的格式提供这些数据。

……………………

更多相关信息请点>>