新闻中心

EEPW首页 > EDA/PCB > 设计应用 > 面向有挑战性功能块的时序收敛技术

面向有挑战性功能块的时序收敛技术

作者:时间:2010-05-07来源:网络收藏

摘要:
始终是高性能处理器的一个大问题。如测试尺寸、有用偏斜等平常技术可能不足以解决某些案例中违规行为。本文将探讨以前深亚微米项目中所用的一些技术,这些技术以众所周知的功能为基础,但却不局限于这些功能,包括:预测块级边界时序问题、增量布局迭代、时钟门控克隆战略选择、采用线路延时最大程度降低不同时序角点下延时差异。.

关键词索引:、边界时序、布局迭代、时钟门控克隆、线路延时

第I章:介绍

中,一直是个问题,解决这个问题的方法多式多样。本文将探讨几种可帮助尽早检测到可能要在非常晚期设计阶段才会出现的问题以及降低正常PR阶段TNS(负余量总和)的方法。这些方法以Magma Talus现有功能为基础,但功能的使用有经过进一步扩展或是重新考量。

第II章:绕障I/O密度地图

随着芯片规模的日益壮大,层次化设计正逐渐成为许多芯片设计的一种常用方法。在层次化设计中,最高层设计师(top level designer)会将整个芯片划分为多个小块。每个小块作为一个独立功能块,将贯穿整个流程,最后再由最高层设计师将这些小块集成为完整芯片。这样一来,集成的时候块边界难免会有时序和布线问题。通常,这些问题的修复技术是要落实到功能块上,将由块设计师(block designers)应用以进行修复工作。

在一些案例中,功能块设计师将发现很难在布线后晚期阶段修复这些边界问题,这会导致项目进度大大延迟。

图1是一例这种问题。在功能块左上角有个大型宏,它占用了许多布线层,在其周围区域造成了非常高的拥塞情况。图中加亮线是贯穿这个区域的一条路径,中间插入了几个缓冲区。有几点应多加注意:

1.这条路径是往下走的,因为在大型宏的北面没有足够空间用于缓冲区、没有足够导轨用于布线。
2.线路中间部分由于高度拥塞布线而呈割阶状态。
3.很难这个宏旁边找个位置插入新的缓冲区以修复转换和建立违规。

上述第1点和第2 点是导致最高层时序差的罪魁祸首,第3点则是导致这个问题难以修复的原因所在。布线后功能块层中内部状态对于时序和布线来说还是很不错的;但当最高层设计师开始修复这个时序问题后,插入了许多单元,布线也发生了很大变化,这些均使得内部时序和布线变得更为糟糕且难以融合。

原因相当简单:没有足够资源可留给最高层设计师来修复这个时序问题。但如何才能让块设计师知道他需要在哪里保留资源和保留多少资源呢?功能块设计后内部时序和布局很不错,这时要假设将会有问题时真得特别困难。

通过分析具有类似问题的一些功能块后,我们发现了几个能反映最高层设计潜在困难的指标,比如:边界网路绕障严重程度。绕障(Detour)虽可在一定区域实现好的DRC(设计规则检查)数目,但这好DRC背后却隐藏着问题。对于拥塞严重的区域,时序水平一直在降低,新插入的单元先是会让好的布线变差,然后还会变得不可布线。

为了评估边界网路绕障严重程度,设计师首先要计算这些网路的密度,接着再以颜色直观显示其严重级别。这个过程分为5个步骤:

1.显示功能块的I/O引脚密度。
2.调整初始平面布局和引脚分布以避免明显的拥塞问题。
3.找出所有连接I/O引脚的绕障网路
4.显示所有连接绕障网路的I/O引脚的密度。
5.根据步骤调整平面布局和引脚分布。

关键是第4步,它意味着最高层修复工作哪里将存在潜在困难。每个步骤的详细内容如下所述:

步骤1
首先,你可将每个边界分为多个小段;可基于个人喜好,设50um或100um作为一段长度。其次,计算出每小段中所有非PG(non-PG)引脚数量,基于每段中引脚数以不同颜色来加亮这些片段;为每小段选择适当颜色阈值很重要,因为它直接影响到你对一个区域是否具有高引脚密度的印象。设计师可基于之前项目经验来设置颜色。你需要将所有信号引脚层、类似模拟的特殊引脚层都计算在内,但电源引脚除外。可视部分可以通过命令“ui layout sketch line …”绘制,而所有其它部分则可通过自带Tcl来完成。

步骤2
步骤2中显示了在一些区域里I/O引脚密度高,那么我们需将存储器从高密度区域(白色区域最高,红色区域其次)移出。

步骤3
完成布线后,接下来是要找出所有连接I/O引脚的绕障网路。判断一个网路是否是绕障网路,可通过对比网路线长与其所连接引脚的曼哈顿距离(Manhattan distance)来完成。设计师可依据个人需求来设置20%或30%作为阈值;当然若能设置最短长度就更好了,这样就可忽略不计比它更短的网路;若没有这个设置,设计师将会看到许多短的“绕障”网路,而实际上这些都是错误警报。

在测试功能块中,1对1连接占了绝大部分。基于这点,作者假设忽略多连接网路不会对最终结果有任何影响,因此此次demo只计算了一个输入一个输出的网路,大大简化了计算脚本编写。当然,这种假设还需要经过其它设计的验证。

这次计算将产生一张所有绕障I/O网路名单。不过,如果直接就加亮所有这些网路(如图3),设计师几乎说不出哪里布线真的很差,哪里还不错可以继续当前布线。

图3中上区域看起来最为拥挤,但事实上,它既不是根源所在,也不是最关键区域。我们需要以另一种可直接反映问题所在的方式来提供信息。


上一页 1 2 3 4 5 下一页

评论


技术专区

关闭