ldpack工作日记-2016/4/20

    今天早上参加了前端组会，简单汇报了一下目前的工作进度，经过讨论以后，决定先将ldpack中的delay table和timing数据记录下来和吴老师他们分析讨论。在讨论过程中我也发现了对原代码中packGroup函数理解的错误，我原本以为packGroup是优先将非critical的group打包在一起，其实是根据pack的需要选定一个非critical的区间，在这个区间内选择一个critical的group和一个非critical的group pack在一起，从而在对critical path影响不大的情况下优化面积，在这种方法下我设计的针对该函数的criticality计算公式（Crit=l*10/(1+slack-wns)+(1-l)*10*dis/maxdis）就失去了意义。

    然后下午我就在做记录数据的工作，下班前我也向吴老师解释了一个之前解决的问题，就是一个由两个LUT组成的SLICE，如果面积定义为0.25x0.5，那么就会出现两个这种SLICE拼接在一起的情况，因为满足了SLICE的密度限制，所以global placement并不会把这两个SLICE推开，但是在这个位置LUT的密度就会过高（一个SLICE只能放两个LUT），于是global placement只能将周围的LUT全部推向边界，就会形成LUT包围SLICE的布局，然而用这种布局得到的坐标来估算edge delay，得到的timing结果却有1.8%左右的improvement（目前结果中最好的一次），我猜测这是因为在这种LUT被推到边界处的极端情况下，LUT的坐标能够更好的反应相互之间的布局关系，而preprocess之后的packing主要针对的是LUT（？），所以得到了一个不错的结果。但是这终究是在错误的布局下得到的结果，所以暂且保留对其的分析。

    吴老师提出了是否可以在pre global placement中去掉SLICE这一层，只用LUT和FF来驱动密度控制，后来我仔细想了一下，认为这不能实现。假设有一个塞满的group（2LUT+2FF），我在global placement中必须给它定义一个类型，很明显，将它定义成LUT或者FF都不合适，所以我将它定义成SLICE，一个类型的单元的移动只能由这个类型自己的density map来驱动，也就是说如果在这个点LUT密度过高，那么global placement只会将这个点的LUT推开，而不能将SLICE推开，也就是说如果我没有SLICE的density map，那SLICE就不能正常的移动。这个想法我还需要和似飞确认一下，再和吴老师进行讨论。