ldpack工作日记-2016/4/28

来源:互联网 发布:linq to sql group by 编辑:程序博客网 时间:2024/06/04 05:31

    今天将原来LUT层的global placement不支持MUXF8的bug修复了,但是这个case的max density仍然保持在2.6,降不下去,在debug的过程当中,我发现我在计算LUT/FF的密度梯度的时候没有加上SLICE的梯度,也就是SLICE的高密度的状态不能不会影响LUT/FF,而LUT/FF的高密度的状态可以影响SLICE,为了保持一致性,我就把SLICE的梯度也加到LUT/FF的梯度上,虽然我认为这对global placement不会有太大的影响,因为在某一个点SLICE呈现高密度的同时,LUT/FF的密度也肯定是过高的状态(1SLICE等价于2LUT/2FF),另外,这种方法也会有重复计算梯度的问题,导致梯度过大,使cell移动的过程更快。修改后,max density降为了1.4,仍然是一个异常的状态,debug发现,很多FF的坐标是一样的,这是因为这些FF在电路中的连线关系完全等价,所以它们在global placement中的移动方向和长度完全一致,无法推开。

    这个问题可以通过在移动过程中加一些随机扰动来解决,先判断max density在连续的几次迭代中是不是一直没有发生变化,然后找到坐标完全相同的cell,然后在这些cell的move过程中加上随机扰动。目前还没有做这部分的工作。

    目前修改了global placement后,hard_bt case的detail placement的平均时序收益变为1.4%(原为2%),而global placement的收益就更小了(目前做的几组测试中,global placement的收益都是小于detail placement的收益的),无法做到吴老师要求的5%。

    目前我的想法是对更多的case进行测试,由于很多case出现了bug,在debug的过程中发现代码中存在的问题,但是这会是一个很花时间的过程,但是目前我并没有想到什么好方法来优化我的算法

0 0
原创粉丝点击