Physical awre的概念的提出，其实时间也很早了，印象中应该有七八年的时间了。

当时笔者曾试图通过脚本语言来实现这个概念，取得了一些不错的进展。后来synopsys也在工具里增加了这个功能，并且也不断的完善起来，这些脚本也就荒废了。

Physical aware的提出，其实也是为了解决业界的一个痛点。那就是在timing eco阶段，因为PrimeTime无法知道具体的物理信息，（绕线，局部的density，blockage，hard macro), 这就导致了eco做完之后的结果和PrimeTime估计的结果差别很大，无形中增加了很多反复。通常，timing eco的时间占用了物理实现阶段的很大一部分时间。这在时间就是金钱的芯片行业，这是很难容忍的。

目前比较新版的PrimeTime对physical awre的支持变得更为直接和方便了。特别是如果你用的是icc2，你甚至可以直接指定icc2的design database。

来感受下：

set_eco_options-physical_icc2_lib icc2_lib_path-physical_icc2_blocks icc2_blocks

当然也可以用传统的lef+def的形式读取物理信息，就是这样的形式了：

set_eco_options-physical_tech_lib_path tech_LEF_files-physical_lib_path LEF_files-physical_design_path DEF_files-physical_constraint_file physical_constraint_file-physical_lib_constraint_file spacing_urle_file_list

哪个更简洁方便，一目了然

Timing Signoff工具知道了物理信息，那么它的效果肯定会更好吗？
应该讲，在大多数情况下，效果是好的。
比如加buffer，工具可以在绕线的中途，选择合适的位置来加。尽量利用原有的绕线，所以估算的timing结果与eco之后timing的结果会更为一致。又比如，在修hold的时候，工具不会在density已经很高的地方，不停的加hold buffer，最终导致绕线出了问题。

不过正如标题所说的，有时候，带physical awre还真不如不带physical awre。
设想这样一种情况, desgin局部denstiy很高。那么工具在修hold或者max_tran的时候, 就会非常 “智能” 的把hold buffer放到这个区域周边。

图1：形状区域为high density区域。

而这个区域又恰巧是一些摆放非常紧密的cell，他们相互之间的连线因为非常短，所以驱动非常弱。这就导致了新加的buffer的距离远超原来的绕线，加上原来的驱动太弱，导致delay比PrimeTime预估的大很多，甚至会出现比较严重的transition问题。

如果出现用physical aware来修timing，而eco的结果与预估的结果偏差很大的这种反常现象，首先应当考虑是否有density过高的区域。

我曾在在项目中遇到上述这个问题，通过关闭physical aware（即physical＿mode改为none），取得了比较好的效果。由于没有physical信息，工具会直接在pin的位置插入。在high density区域插入cell，会引起大量cell的移动，但是移动范围比较小，尚在可承受范围内。

这个现象也反映了PrimeTime在估算delay时，目前还有一定的局限性。也就是无法估算重新绕线后的新的cap值，而只是对原来net分割之后的电容值进行重新分配。

通常在非常先进工艺下（<=16nm)，cell的density不会太高（这是由pin density所决定），出现该现象的概率很低。所以如果你是用的这类工艺，可以放心的使用physical aware这个feature。
如果是比较老的工艺情况下（往往density可以做的很高），就需要注意避免此类情况：

• 在PR阶段，就尽量避免局部density过高。通常会有变量来控制这个值。

• 避免过弱驱动的cell的使用（可能带来功耗提升，谨慎评估）

• 适当减少可插入buffer的位置范围（变量：eco_insert_buffer_search_distance_in_site_rows)

如果已经进入eco阶段，可以尝试关闭phyiscal_aware, 可能有惊喜。（建议流程中physical aware默认开启）

关于physical awre的相关问题，欢迎留言讨论。

欢迎关注：