ldpack工作日记-2016/4/22

1. 发现了一个packing的bug：

    在对MUXF进行打包时，会将和MUXF相连的FF一起打包进来，这时候没有判断和FF相连的pin是不是D，所以在一个group中，一个MUXF和FF的R端相连，这个FF也被一起打包进来，这显然不符合SLICE结构。

已解决。但是这是不是说明pack的DRC有缺陷？没能发现这种错误。

2. 今天发现一种情况：

    一个LUT drive两个FF，这两个FF都和这个LUT pack在一起，虽然这种结构可以实现，但是我在计算edge delay的时候会把LUT驱动两个FF的两条net都当成是内部连线，计算成intra delay，而显然只有一条net是内部连线，还有一条net必须经过SLICE外部绕线，是inter delay，也就是说我估算的delay偏小。另外STA在计算这个SLICE的delay的时候会不会也算错？

3. 经过昨天代码的改进后，重新统计了一下detail place之后的timing数据，和原flow进行比较，有了1%的improvement。但是pre place后的min slack仍然比ldpack+global place之后的min slack小，所以我不得不对原来的想法（pre place后的timing是所有step中最优的）产生了质疑，并想出了以下几点理由：

    1）pre place虽然没有DRC constraint，但是它仍然需要满足density limit，即一个SLICE的位置只能放两个LUT和两个FF。

    2）pack后的优势是SLICE内部的连线delay将被大大缩小，拿LUT和FF的pack举例，当LUT和FF在pre place后靠的不是非常近的时候，我会把他们之间的delay计算成inter delay（>0.6），而pack的过程中会有一些LUT和FF被pack在一起，一旦pack在一起，他们之间的delay是0.057，缩小为原来的1/10！！！

    事实上，能被pack在一起的LUT和FF并不一定会靠的足够近，假设这样的情况：LUT->FF->LUT，由于pre place在满足density limit的情况下完全可以把FF->LUT这两个cell放在一个SLICE中，即左边作为驱动的LUT对FF并没有特别的“吸引力”（pre place似乎并不知道把LUT->FF放在一起可以大大缩小delay）。

    结合以上两点，我认为pre place后的timing并不一定会比ldpack+global place之后的timing好。