LEF转Milkyway的问题

把生成的SRAM的lef，在Milkyway中用read_lef即可生成FRAM和CEL，但是打开后发现FRAM和CEL两个cell，CEL的和LEF的描述情况一致，FRAM和LEF不一致。用BPV的默认设置过了一遍，也没有什么改进。
这样的FRAM在ICC中congestion不严重的情况下没问题，如果congestion严重的时候，就产生了绕线的问题了。LEF文件在encounter下是没问题的，就是FRAM生成的不好。
只是read_lef不进行BPV是不能用的吧?
BPV需要有什么设置么?
第一次转，没经验，SOS！

你用的是LEF阿，只能生成FRAM了

有lef，即不需要BPV了

教程上写read_lef完事后，extract BPV，PRboundary，multiple_height proterty, defineWireTrack也同时完成了，自己创建了一个完整的供PR的库，
可问题是它的FRAM的pin周围的blockage的形状和用encounter读入lef的不一致，也容易造成最终的drc问题。
而CEL的形状就和LEF在encounter中见到的一样。
好奇怪呀

也可以生成CEL，但是不能用作生成最终GDS，最终gds数据需要merge一下

哇 大牛

这个是对于STD cell的情况吧，macro应该是readlef就ok了

可是现在的问题是encounter读lef绕线没问题
ICC用这个FRAM就有DRC问题，FRAM的形状和LEF的描述不一致，好奇怪，FRAM产生机制是什么

很复杂，以前在没有read_lef 的时候， 使用auLefIn 这个命令的
以及bpv等， 都是完整的flow
后来Astro发明了一个read_lef 命令，专门用于简化lef 到fram view的flow，自动bpv完了，用户不用干预，
如果是fram没做好， 看看lef 写的问题吧，
FRAM和Cel view当然是不一样的， fram view主要体现的是blockage， pin， via，
哪个memory compiler，一般来说MC出来的lef还是比较标准的

Artisan的MC

artisan的MC很好啊，用了很多年的，没啥问题啊，lef，

是啊，lef没问题，在EDI中一点问题都没有
但是read_lef后FRAM就变化了，PIN的周围blockage的范围发生了变化，有点奇怪

一般Standard cell的处理是用BPV的。而IP（macro）的是用geNewMakeMacro这个命令的。
read_lef后，在用geNewMakeMacro它。
你试试看。

果然如你所说，搞定了，只要用这个命令在进行相关一些layer的设置就可以出来我想要的了
多谢多谢！

小编，为什么我的Milkyway里面只有CEL，没有FRAM，FRAM是怎么来的呢?

FRAM view是不是从LEF转换来的，我的LEF读不进去啊?

就是lef产生FRAM view

layer 设置要注意些什么吗?我用astro的read_lib转得库，结果出来后，只有一个空空模块，无法显示金属层出来?

你给的什么文件呢?
应该用Milkyway来转吧

我给.tfstd.lefcell.lef三个文件，一样的流程我转了四个宏模块，有一个金属层显示不出来。

map文件没问题吧?

没有用到map文件。

你用Milkyway命令，然后转试试
需要一个map文件吧，因为lef中定义的layer可能和tf文件中的不一致。

转出来number_of_pin是零，这个是cell_lef没有定义pin吧，好的，我去试试。

我也碰到跟你描述的同样的问题了。read_lef后生成的FRAM跟lef中的描述不一样，pin周围blockage不对。用geNewMakeMacro这个命令如何设置layer啊?请指教，谢谢！

不用设置吧
还有的需要先用tf建个milkyway的library，然后再用lef导入

我先用tf建库，然后用lef导入，生成FRAM和CEL，然后再用geNewMakeMacro从CEL view中抽取blockage。就是抽取的时候选哪些选项?我采用默认设置，报错了，说是指定的CEL中没有pin。接着我用geNewMakeMacro抽取pin信息，也是采用默认设置。然后我再用geNewMakeMacro重新抽取blockage信息，就可以了。但是FRAM中的blockage信息跟CEL中的还是有点出入。抽取blockage的时候有很多种设置方法，就是不知道应该选哪一种。

最近也遇到这种情况，Milkyway sram的lef产生的fram和layout不一致，附图
图

绿色是layout中存在的真实metal4，lef中有描述x2-x3之间的metal4为port，x1-x4之间盖有OBS，
生成的FRAM中只有x2-x3之间的的metal4，route时旁边走线就会有DRC错。
说明一下x1-x2和x3-x4小于design rule的最少space和最小width，这一点比较重要
我的理解是这样的：metal的port属性比OBS高，工具优先考虑port的metal，其次再把OBS转换成对应的metal，由于x1-x2和x3-x4小于design rule的最少space和最小width，所以工具就直接忽略了这一片OBS，也就发生了这种情况！

我也是遇到number of pin 0这问题 ，怎么修改啊?

这种转库问题真的是好麻烦啊