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好。
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的slac...
ldpack工作日記 2016 5 6
關於等價單元無法推開的問題，在前五次迭代中，每次迭代找出座標重疊最多的單元，對這些單元的座標加上乙個隨機的擾動，公式如下 x 0.02 rand 100 即會出現 0,2 之間的座標變化，加上隨機擾動後，大部分case能把最大密度降低到2以下，仍然有case的最大密度保持在2以上，還需要繼續debu...
ldpack工作日記 2016 5 11 12
這兩天主要對max density存在異常的case進行了除錯分析，有乙個case的max density有乙個位置的density只能收斂到1.24，debug發現在最後幾次的迭代中，處在該點位置的單元梯度較小，而處在邊界位置的單元梯度較大，導致高密度處的單元移動步長很小，和似飛討論後，修改了一些...