molinfeng507-CSDN博客

原创 ldpack工作日记-2016/6/12

今天对packing产生了一个想法，目前的算法主要可以分为两部分，第一部分是对cell进行排序，来选择优先对哪个cell进行pack，第二部分则是最优化，选择一个最优的cell和第一部分的cell进行pack（这是t-vpack的思想，公司的算法和这个有些不同，但是我觉得基于公司的算法很难做出成果）。这种贪婪算法很难得到一个全局最优的结果，那么我们是不是可以找出一个方程，通过求解这个方程，来得到一

2016-06-12 21:27:03 337

原创 ldpack工作日记-2016/5/30

今天对t-vpack的参数做了些调整和测试，发现edge delay estimation的作用非常小，另外net share的权重变大使性能提高。下午和吴老师讨论了一些目前的工作进展，主要有以下问题：1. global placement的timing比pack+global placement的timing差，对此，预布局对packing的意义受到质疑。2. 一次预布局对packi

2016-05-30 21:45:57 261

原创 ldpack工作日记-2016/5/26

为了使设计的pack算法和ISE的map两者的结果比较更具可靠性，后续的步骤都通过ISE的工具实现，具体步骤如下：1. 用pack生成XDL2. 利用xdl生成NCD文件3. 利用par生成布线后的NCD文件4. 利用trce命令输出时序报告5. 与全部用ISE工具得到的布线结果比较今天主要修改了一些参数做了一些测试，以及熟悉了ISE的命令使用方法。

2016-05-26 19:26:30 368

原创 ldpack工作日记-2016/5/25

今天对procise的pack和ISE的map的结果进行了对比，比较方法是对两种结果都进行布局和布线，统计三个阶段（global place, detail place, route）的slack/require，ISE在三个阶段的slack/require比procise平均大分别1.3%，2.1%，0.96%。说明procise的pack算法不如ISE。之前也提到packEdge函数的作用

2016-05-25 19:26:47 226

原创 ldpack工作日记-2016/5/23

经过调参测试发现，将packEdge函数注释掉反而比原pack的结果要好1%，所以pack算法本身就存在很多问题，我打算按照T-vpack的思路重新写一个新的pack算法，观察一下结果。

2016-05-23 19:39:55 187

原创 ldpack工作日记-2016/5/19&20

修改了packEdge的算法，每次group后更新当前path的criticality（=10 / (1 + slack - wns)），计算方法如下：1. 计算group前的edge delay（ed1）2. 计算group之后的edge delay（ed2）3. 计算差值edoffset = ed1 - ed2，其中必有ed1 >= ed24. 计算新的criticality

2016-05-20 19:23:40 202

原创 ldpack工作日记-2016/5/18

在global placement之后的时序分析前没有更新edge delay，统计的时序信息有误差，现已修复。修改penalty参数做了18组测试，初始值设为128较好。明天尝试修改pack算法，几次group之后更新pack优先级。

2016-05-18 20:16:53 165

原创 ldpack工作日记-2016/5/16

今天在观察预布局的gui显示的时候，发现SLICE构成的chain的移动幅度很大，并不是一点一点向外扩散，debug发现chain的gradient是要除以它的长度的，否则chain内部的每个SLICE的梯度都会叠加到这个chain上，而我把这个长度设成了1，导致梯度过大。今天修改了迭代次数的参数，从2到24，每次叠加2，共12组测试，统计了平均增益，最高是迭代次数为4的时候，为0.3

2016-05-16 20:08:29 200

原创 ldpack工作日记-2016/5/11&12

这两天主要对max density存在异常的case进行了调试分析，有一个case的max density有一个位置的density只能收敛到1.24，debug发现在最后几次的迭代中，处在该点位置的单元梯度较小，而处在边界位置的单元梯度较大，导致高密度处的单元移动步长很小，和似飞讨论后，修改了一些参数，虽然能够降低max density，但是对其他case测试后发现延时性能下降了，所以又将参数改

2016-05-12 21:42:37 292

原创 ldpack工作日记-2016/5/9

今天在查找一些case的max density降不下去的原因的过程中，发现了3个问题：1. 在判断坐标相等的时候，一些cell的double类型的坐标只有最后一两位不相等，我怀疑在计算坐标的时候有一些操作涉及到float类型，产生了误差。解决方法：先将坐标都转换成float类型，再判断是否相等。2. 当坐标重叠的cell个数达到8个以上时，我才会做随机扰动。然而一个bin最多只能放4个

2016-05-09 19:18:48 249

原创 ldpack工作日记-2016/5/6

关于等价单元无法推开的问题，在前五次迭代中，每次迭代找出坐标重叠最多的单元，对这些单元的坐标加上一个随机的扰动，公式如下：x += 0.02 * (rand() % 100) 即会出现[0,2)之间的坐标变化，加上随机扰动后，大部分case能把最大密度降低到2以下，仍然有case的最大密度保持在2以上，还需要继续debug，和似飞讨论一下这个问题。在LUT层的global

2016-05-06 19:58:08 256

原创 ldpack工作日记-2016/5/4&5

这两天把所有case中导致crash的bug修复了，主要有以下bug：1. 在global placement中，将所有cell分类成movable和fixed两类，其中fixed cell是从movable cell出发找出相连的fixed cell，而有case中出现一种连接情况是in->IBUF->OBUF->out，即两个fixed的BUF无法通过movable cell找到，于是在访

2016-05-05 19:13:48 262

原创 ldpack工作日记-2016/4/28

今天将原来LUT层的global placement不支持MUXF8的bug修复了，但是这个case的max density仍然保持在2.6，降不下去，在debug的过程当中，我发现我在计算LUT/FF的密度梯度的时候没有加上SLICE的梯度，也就是SLICE的高密度的状态不能不会影响LUT/FF，而LUT/FF的高密度的状态可以影响SLICE，为了保持一致性，我就把SLICE的梯度也加到LUT/

2016-04-28 21:22:38 252

原创 ldpack工作日记-2016/4/27

今天把公式criticality=l*10/(1+slack-wns)+(1-l)*10/(1+dis)中的l从0.9调小做了数据统计，发现时序在0.9的情况下是最好的，对此我认为，distance在公式中相当于是一个tie break的参数，因为对于一条critical path上的所有pin的slack是相同的，所以用原公式计算的这些pin的criticality是相同的，选择哪个pin的

2016-04-27 22:33:18 188

原创 ldpack工作日记-2016/4/25

将criticality的计算公式修改为criticality=l*10/(1+slack-wns)+(1-l)*10/(1+dis)，其中l设为0.9，即以slack为主，location为辅，然后统计detail placement之后的slack，平均improvement为2%！上午和琼华讨论了一下我的工作以及最近碰到的问题与解决的方法，然后觉得有必要修改l的值进行更多的测

2016-04-25 20:19:36 276

原创 ldpack工作日记-2016/4/22

1. 发现了一个packing的bug：在对MUXF进行打包时，会将和MUXF相连的FF一起打包进来，这时候没有判断和FF相连的pin是不是D，所以在一个group中，一个MUXF和FF的R端相连，这个FF也被一起打包进来，这显然不符合SLICE结构。已解决。但是这是不是说明pack的DRC有缺陷？没能发现这种错误。2. 今天发现一种情况：一个LUT dri

2016-04-22 20:53:21 227

原创 ldpack工作日记-2016/4/21

1. 今天和似飞讨论了一下SLICE和LUT的density map互相不能影响移动的问题，这个问题得到了解决。首先阐述一下这个问题：假设有一种SLICE中只有两个LUT（未塞满的状态），将其定义为0.25x0.5的大小，那么在SLICE的density map上，在一个SLICE的面积（0.5x0.5）上可以放置两个这种SLICE，此时在该点相当于放置了4个LUT，LUT的密度为2（

2016-04-21 20:39:05 236

原创 ldpack工作日记-2016/4/20

今天早上参加了前端组会，简单汇报了一下目前的工作进度，经过讨论以后，决定先将ldpack中的delay table和timing数据记录下来和吴老师他们分析讨论。在讨论过程中我也发现了对原代码中packGroup函数理解的错误，我原本以为packGroup是优先将非critical的group打包在一起，其实是根据pack的需要选定一个非critical的区间，在这个区间内选择一个critical

2016-04-20 21:21:51 305

molinfeng507的博客