HLMC_55 IP數字後端設計

        前段時間完成了一個IP在HLMC_55工藝下的後端設計,在此記錄如下。

        關於工藝

        本次設計選用工藝庫爲IH55LP_HS_RVT_V2p3_1P4M_1TM2X,設計中不包含IO及Memory,因此物理庫只引用standard_cell。關於時序庫,target_library選擇ih55lp_hs_rvt_ss_1p08_125c_basic.db,link_library選擇ih55lp_hs_rvt_ss_1p08_125c_basic.db和ih55lp_hs_rvt_ff_1p32_-40c_basic.db。tech_file選擇tf/HLMC_cl055lp_1p4m_1tm2x_mw.tf。因爲此工藝只有4層金屬,相比其他工藝,繞線問題將成爲本設計的設計瓶頸。

        拿到的初始文件

        從前端拿到的東西只有一個網表和一個sdc,因此本次設計不包含掃描鏈。從sdc可看出,本次設計包含8個主時鐘,其中最高頻時鐘週期爲1.25ns(爲了減輕後面修正時序的工作量,在apr時把週期調整爲1.2),另有17個衍生時鐘,用於產生分頻。

        從版圖拿到的floorplan size爲{{0 0}, {0 482},{2550 482},{2550 0},{2005 0},{2005 382},{545 382},{545 0}},這是一個不規則圖形,一開始跑流程的時候僅僅意識到這個不規則形狀可能對時序有惡劣的影響,沒有考慮到其對繞線的影響,這一點後面再詳細講述。

        開始後端流程

        建立設計庫和加載網表沒有什麼特別之處,和其他大多數項目的流程相同。

create_mw_lib  {自己指定的設計庫路徑(文件夾)}     -technology  {tech_file}   -bus_naming_style {[%d]}   -mw_reference_library  {物理庫路徑}   -open

set_tlu_plus_files   -max_tluplus  {max_tluplus}    -min_tluplus  {min_tluplus}    -tech2itf   {mapfile}

import_designs   -format verilog  -top {design}   -cell {design}    {網表}

current_design

link

change_names -rules verilog  -hierarchy

uniquify

        在創建floorplan時,從原則上講,對於不規則形狀應該使用initialize_rectilinear_block命令,對於規則形狀才能用create_floorplan命令,然而此次設計爲不規則形狀,使用create_floorplan命令居然也成功了,有點不明白~~

        在preplace階段,出於優化時序的考慮,把最高頻時鐘輸入後經過的兩個MUX和第一個分頻點拉到該時鐘的輸入端口附近,並fix住。

        在place階段,有一個設置值得一提,set_app_var placer_max_cell_density_threshold -1,此設置使得工具在佈局時充分利用core的全部面積對cell進行均勻佈局,此設置可能導致時序不夠理想,但有利於解決繞線困難的問題。在place階段向設計中加入spare cell時,對所有加入的spare都加上keepout_margin,這也是出於優化繞線考慮。

        做時鐘樹階段,設置target_skew爲0.1,max_transition爲0.2。時鐘樹做完之後報告顯示,最長時鐘樹的longest path爲2.4,max_skew爲0.18,時鐘情況整體看來可以接受。

       後面的流程時鐘優化和繞線其實沒什麼特別的,按照正常流程進行即可。在繞線階段,因爲繞線資源的限制,在解決短路問題上花費了一點時間。總體而言,短路多出現在內拐角附近,以後再做類似floorplan的IP時應該在佈局之前在內拐角區域打上blockage,通過降低局部cell密度來解決局部擁塞。

      APR流程跑完後cell數爲38734,利用率爲16.5%。

        關於signoff

        APR之後跑出來的結果,時序果然非常差,原因可能是兩方面的:1. floorplan的形狀比較畸形,2. 金屬層較少,繞線資源緊張。

        STA在21個corner下進行,OCV設定爲early:0.9,late:1.15。uncertainty設定爲:setup:0.15,hold:0.06。max transition設定爲:data:0.4,clock:0.2。修正時序的具體過程在此不再詳細描述。值得一提的是,在修正noise時,考慮當前繞線資源已經比較緊張,採用的是在有noise的線中間位置插buffer的方法來修正,而不是採用更常用的加倍線寬和線距的方法,而這種方法又會對時序產生影響(或許出現noise的線剛好處於關鍵路徑上?),因此在修正時序和noise的過程經歷了較多次eco迭代,並且迭代過程中也多次出現新產生的短路,總而言之,eco迭代過程相當不順利。

      LVS比較順利,短路解決後,LVS一次通過。DRC存在少量的間距問題,刪掉個別線重繞即可解決。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章