Design Compiler指南——设计综合过程
????????在前面一章介紹完施加約束之后，接下來要做的工作就是將設(shè)計進行綜合編譯(compile)，本文我們將主要討論綜合編譯的過程。主要分為這樣幾個部分：
- 優(yōu)化的三個階段及其特點
- 編譯的策略
- 編譯層次化的設(shè)計
一、優(yōu)化的三個階段
????????這一節(jié)我們介紹Design Compiler進行優(yōu)化的三個階段：結(jié)構(gòu)級、邏輯級以及門級，在不同的階段，DC運用的方法和優(yōu)化余地是不一樣的，我們將對這幾個階段的特點和優(yōu)化方法進行一個介紹，這里一起歸納一下，希望能加深認識。
????????上圖是這三個階段的關(guān)系圖，可以看到，結(jié)構(gòu)級屬于最高的抽象層次，當(dāng)讀入Verilog代碼或者沒有經(jīng)過映射的db文件后，DC的優(yōu)化從這個階段層次開始，可以說，結(jié)構(gòu)級是優(yōu)化的最高層次，所以對DC來說，這個層次的綜合可以稱為高層次綜合(High-Level Synthesis)。結(jié)構(gòu)層的下一個優(yōu)化階段是邏輯級階段，也是讀入映射過的db文件的DC的初始優(yōu)化階段。再往下一個階段是門級階段，也是優(yōu)化的最后階段，這里所要作的工作主要就是GTECH到工藝庫的映射。
1、結(jié)構(gòu)級優(yōu)化
????????因為結(jié)構(gòu)級是優(yōu)化過程中層次最高的一級，因此它也是DC可以采用的優(yōu)化方法最多的一級，它的主要優(yōu)化方法如下圖所示
1）DesignWare選擇
????????DW選擇是結(jié)構(gòu)級優(yōu)化的一個很主要的特點，在這個階段DC能夠根據(jù)設(shè)計者施加的時序或者面積的約束在DW的不同實現(xiàn)方式中找到它認為最佳的實現(xiàn)方案。比如加法器的實現(xiàn)方式一共有如下幾種
????????其中DW Foundation需要有專門的license，而且使用之前還要設(shè)置綜合庫(synthetic library)。?
2）共享子表達式(Sub-Expressions)
????????這里的子表達式主要是指數(shù)學(xué)表達式，比如下面這個例子，如果按照原來的語句綜合，會包含6各加法器，但是如果表達式之間的公共項提取出來，便可以大大的減小面積，如下圖
????????如果要直接綜合出共享后的電路，可以在編寫RTL代碼的時候強制指定共享項：
3）資源共享(Resource Sharing)
????????資源共享的原理與共享子表達式類似，只不過這里指的所謂資源是一些HDL的運算符和表達式，比如加(+)、減(-)、乘(*)、除(/)以及大于(>)、大于等于(>=)、小于(<)、小于等于(<=)。比如給定一個語句
????????DC會根據(jù)具體的約束條件綜合出最符合要求的結(jié)構(gòu)來。
4）運算符排序(Operator Reordering)
????????對于下面這個表達式Z <= A + B + C + D(輸出Z是施加了一定時序約束)，DC最初是按照從左至右的順序計算的，也就是說它最初的排序如下
????????如果幾個輸入信號到達的時間相同，DC會通過運算符排序優(yōu)化成下圖的平衡的結(jié)構(gòu)，減小延時:
????????如果A信號較遲到達，則綜合出的電路結(jié)構(gòu)會如下 :
2、邏輯級優(yōu)化
????????在經(jīng)過結(jié)構(gòu)級優(yōu)化之后，電路被轉(zhuǎn)化成了工藝無關(guān)的GTECH庫的形式，這級也稱為邏輯級，對于邏輯級優(yōu)化來說，只有一個方法，那就是——結(jié)構(gòu)化 (structure)或者扁平化(flatten)。
1）結(jié)構(gòu)化(structure)
????????結(jié)構(gòu)化是DC在邏輯級的默認的優(yōu)化方法，它是指：使用電路的一些中間項構(gòu)成一個多級的電路結(jié)構(gòu)。如下圖的電路一共有三級邏輯，下一級的輸入是上一級的輸出，使用這種優(yōu)化方法一般情況下能綜合出兼顧時序和面積的電路來。
????????結(jié)構(gòu)化電路的典型是奇偶校驗電路。
2）扁平化(flatten)
????????扁平化是將所有的組合邏輯打平成乘積項和(SOP)的兩級結(jié)構(gòu)，類似與可編程陣列邏輯(PAL)。使用這種結(jié)構(gòu)的特點由于沒有利用中間項，綜合后電路面積將會變得很大，但是卻不一定能取得較好的時序。
????????扁平化結(jié)構(gòu)的電路和設(shè)置扁平化的DC命令如下所示：
dc_shell > set_flatten true -effort low | medium | high
綜合結(jié)構(gòu)化和扁平化的特點，可以歸納如下:
????????由于DC默認是用結(jié)構(gòu)化的方式綜合邏輯級電路，而且這種方式可以得到兼顧時序和面積的結(jié)果，因此我們可以先用這種（結(jié)構(gòu)化）方式優(yōu)化。在優(yōu)化后的電路中找出關(guān)鍵路徑，看看關(guān)鍵路徑上有沒有符合使用SOP電路的模塊，再將這些方便使用SOP的模塊set_flatten，以便取得最佳的效果。?
3、門級優(yōu)化
????????門級優(yōu)化是優(yōu)化的最后階段，它所要完成的任務(wù)就是將GTECH的電路映射到最終的工藝庫中，并且保證映射后的電路不違反設(shè)計規(guī)則(Design Rule)。
1）工藝映射
????????工藝映射包括組合邏輯映射和時序邏輯映射。組合邏輯映射是指DC使用工藝庫中的各種門替換GTECH單元，并選擇能實現(xiàn)相同邏輯的符合時序及面積要求的單元。
????????時序邏輯映射的方法和組合邏輯相類似，也是出于速度和面積的考慮，盡量使用復(fù)雜的時序單元吸收一部分組合邏輯。?
?
2）設(shè)計規(guī)則檢查(DRC)
????????對于工藝庫的單元而言，Foundry都指定了每個單元的工作條件的限制，比如最大電容(max_capacitance)等等，這些限制也可以稱為設(shè)計規(guī)則(Design Rule)，在設(shè)計規(guī)則限定的范圍內(nèi)，Foundry提供的參數(shù)才有實際的意義。比如一個單元允許的最大電容為5pf，而實際工作電路中出現(xiàn)的電容值為10pf，那么這時，便違反了設(shè)計規(guī)則，單元的參數(shù)也就不能確保是準(zhǔn)確的了。
????????因此，DC在作門級優(yōu)化的時候，在映射的過程中也會檢查電路的設(shè)計規(guī)則，一般的做法是在單元中插入buffer增加驅(qū)動能力，或者將小驅(qū)動的單元替換為大單元。設(shè)計規(guī)則檢查分為兩個過程——DRC I 和DRC II 。
????????DRC I是指Design Compiler在不影響電路的時序和面積的前提下修正違反規(guī)則的一些單元，如果在這個前提下不能完全修正，則要進行下一步的檢查，即DRC II，這一步的修正必然是以犧牲一部分時序和面積為代價的。
二、編譯策略
????????編譯過程是指設(shè)計經(jīng)過三個階段的優(yōu)化，最終形成門級網(wǎng)表的過程，在這一節(jié)里，我們主要就編譯的策略，它包含如下幾方面的內(nèi)容——
- 中斷編譯的方法
- 從報告中檢查時序，調(diào)整策略
- 修正保持時間違反(Hold time violations)
1、中斷編譯的方法
????????在DC-Tcl的界面下，當(dāng)我們鍵入compile命令時，DC就開始了編譯，也就是優(yōu)化的過程。優(yōu)化是在設(shè)計規(guī)則的條件下，運用不同的算法，綜合最終出滿足時序和面積的電路。優(yōu)化首先是時序驅(qū)動(timing-driven)的一個過程，其次再是面積。如果找到了一個滿足時序和面積等約束的電路，編譯將會停止；如果通過種種編譯仍不能滿足時序，編譯也會停止下來；另外，我們也可以人為的中斷編譯。
????????人為中斷編譯的方法是鍵入Ctrl-C，經(jīng)過一段時間的等待后（有可能時間會很長），優(yōu)化過程暫停，并彈出如下菜單：
????????這里有四個選項，設(shè)計者可以根據(jù)情況作出選擇。
????????DC在編譯的過程中，會自動打印出一個報表，報告編譯的總時間，設(shè)計的面積，關(guān)鍵路徑的時序違反和總共時序違反情況，我們可以根據(jù)需要更改打印的列項目：
2、分析報告，調(diào)整策略
????????一般情況下，我們先作一個默認的編譯，這樣一般可以取得既快又準(zhǔn)確的結(jié)果，然后在編譯完成后使用一些報告時序的命令，并分析它們的輸出結(jié)果，使用的命令主要有
????????從這些報告中，我們可以看到電路中是否有違反的約束，如果有，那么它是什么類型，還有電路中的最大負裕量(worst negative slack)是多少，等等。下面我們就幾個常見的約束違反情況，談?wù)劶m正它的綜合策略
1）較大的時序違例
? ? ? ? 以下圖為例
????????從report_constraint –all這個命令的報告可以看出，需要到達的時間是1.20ns，而實際到達為2.84ns，違反了1.64ns。之所以判斷它是一個較大時序違反的情況，并不是因為1.64這個絕對值很大，而是相比較需要時間而言，1.64是一個較大的值。一般而言，如果電路中的最大負裕量(簡稱WNS)所占時鐘周期的15％以上的話，可以認為電路存在較大的時序違反。
??????確認存在較大時序違反之后，下一步就是找出原因，消除違反情況。可供參考的步驟有下面幾種：
重新編譯(Re-Compile)
????????當(dāng)重新讀入映射后的網(wǎng)表進行重新編譯時，DC會自動將門級的網(wǎng)表重新返回到GTECH的結(jié)構(gòu)，相當(dāng)于邏輯級。然后分別進行邏輯級和門級的優(yōu)化，但是同時也可以進行DesignWare的替換。
????????如果設(shè)計者僅僅將映射后的網(wǎng)表拿來再做一次compile，編譯后的結(jié)果并不會不一定會比原來的好，無非把以前做過的優(yōu)化再跑一遍。因此，重新編譯之前會改變一些參數(shù)，如——改變設(shè)計約束、改變set_structure和set_flatten參數(shù)以及改變編譯的map_effort。
改變map_effort重新編譯
????????對設(shè)計進行編譯的時候，有三種編譯級別可以選擇，它們分別時低級、中級和高級。
dc_shell > compile?-map_effort low | medium | high
????????不同的級別編譯要求的編譯時間和編譯結(jié)果都各不相同，compile –map_effort low編譯時間最短，但是結(jié)果不一定好，它一般用于設(shè)計預(yù)估(Design Exploration)，不用在重新編譯環(huán)節(jié)。
compile –map_effort medium是DC默認的編譯級別，大多能在一定的時間內(nèi)得到較為滿意的結(jié)果。這也是我們推薦的初始編譯級別。
????????compile –map_effort high 編譯的過程中會使用前面的級別中沒有的算法，因此它所要求的時間是最多的，結(jié)果也是相對最好的。這種級別一般用在重新編譯的階段。
修改RTL代碼
????????修改源代碼所能取得的效果是最直接的，同時也是代價最高的。修改代碼后，DC會從最上層的結(jié)構(gòu)級開始優(yōu)化，前面也討論過，越上層次的優(yōu)化方法越多。所以通常這樣得到的結(jié)果也越滿意。但是，修改代碼也不一定放之四海皆準(zhǔn)的方法，因此并不是所有的設(shè)計我們都能獲得源代碼，同時也不是可以隨便修改的。
2）較小的時序違例
? ? ? ? 以下圖為例
????????從上圖看出，相比較1.20的允許路徑延時，0.10的負最大裕量(WNS)是比較小的(小于15%)，而且已經(jīng)認定了約束和模塊劃分都是正確的，那么應(yīng)該怎樣修復(fù)這個錯誤呢？
????????這里主要講一下Incremental Mapping：
dc_shell > compile?-incremental_mapping
????????這個開關(guān)告訴DC，在重新編譯的時候不需要把網(wǎng)表返回到GTECH結(jié)構(gòu)，因此也不需要作邏輯級優(yōu)化，速度也較一般的編譯更省時間。這里DC所要作的是進行門級單元的替換，即在不違反設(shè)計規(guī)則的情況下用延時小的單元替換延時較大的單元。另外，如果讀入的是db格式的網(wǎng)表，在這個階段也可以進行DesignWare的替換。
????????如果要同時優(yōu)化多條路徑，需要使用另外一個命令——set_critical_range。這個命令設(shè)置的critical_range是以WNS的值為基準(zhǔn)的，優(yōu)化的是和這個值的絕對值差設(shè)置值的那些路徑。因此，如果設(shè)置值為0，那么就僅僅優(yōu)化一條關(guān)鍵路徑。
dc_shell > set_critical_range 2 [current_design]
3）設(shè)計規(guī)則違反
????????有些時候的時序違反是由于設(shè)計規(guī)則違反引起的，比如說一個單元的扇出（fanout）過大，導(dǎo)致它的transition time的時間迅速增加。對于這種情況，我們可以通過
dc_shell > report_net -connections -verbose
dc_shell > report_timing -net
????????兩個命令審查連線的連接和負載情況。
????????要修正設(shè)計規(guī)則的錯誤，可以使用一個編譯的開關(guān):
dc_shell > compile -only_design_rule
????????如下面這個例子，為了滿足最大電容的規(guī)則，在A端口的內(nèi)部加上了一個buffer，用于緩沖N路徑對A的負載。
3、修正保持時間違例
????????一個時序電路要想正常工作，除了必須滿足建立時間要求之外，也需要滿足保持時間要求。雖然保持時間檢查和建立時間檢查是同樣重要的，但是我們在實際綜合的過程中卻不是把它們同時考慮，而是更多的把保持時間的檢查放到布局后。這是因為
- 時鐘偏移必須要到布局完成后才能得到準(zhǔn)確值
- 修正保持時間的通常做法是插入buffer，而這可能會增加建立時間違反的可能性，并且增大了組合電路的面積
- 保持時間檢查用的一般都是電路工作的最佳條件，而在這個條件下，連線延時往往是被忽略的，連線延時也是必須在布局后才準(zhǔn)確。
????????如果確定要同時作建立和保持時間檢查，那么在施加電路約束的時候要加入相應(yīng)的開關(guān)，如：
????????以及設(shè)置各自的工藝庫——?
????????
????????默認情況下，DC不修正保持時間的違反。如果確定要作修正，需要先設(shè)置一個變量再作檢查 ：
dc_shell > set_fix_hold [all clocks]
dc_shell > compile -only_design_rule
????????加上only_design_rule的開關(guān)后，編譯過程中僅僅更換單元大小，并增加buffer，以便修正設(shè)計規(guī)則違反和保持時間違反。
三、層次化設(shè)計的編譯
????????一個層次化設(shè)計的編譯過程包含兩個階段：1、將所有的子模塊映射到門級，2、優(yōu)化。
??????????在一個層次化的設(shè)計中，我們可能會遇到下面這種情況
??????
????????上圖中，被綜合的模塊中D_design中含有三個子模塊U1、U2和U3，其中U1和U3都是由模塊Ades例化而來，這里的Ades稱為多次例化的模塊。對于這樣一個設(shè)計，在compile之前使用check_design作檢查的時候會報一個warning，即設(shè)計中存在多次例化的模塊(multiple instantiations)，如果在這種情況下，我們不考慮多次例化的模塊(Ades)，那么在繼續(xù)的compile時候程序會終止退出。因此，必須對它進行處理，這里我們介紹兩種方法——uniquify和compile + dont_touch。?
1、uniquify
????????使用uniquify，DC會對每個例化的模塊作一份拷貝，然后對它們分別取一個名字，即把不同的例化模塊當(dāng)作不同的兩個模塊處理。
????????注意看上圖，U1和U3兩個模塊的設(shè)計名分別由原來的Ades變成了Ades_0和Ades_1，因此在編譯時，DC會將它們當(dāng)作兩個不同的模塊，這樣就可以根據(jù)它們不同的周圍環(huán)境作優(yōu)化。
????????使用uniquify的具體實現(xiàn)方法如下
?dc_shell > uniquify
dc_shell > compile
2、compile ＋ dont_touch
????????這種方法先將多次例化的模塊作單獨的約束和編譯，然后在整合到上一級模塊的過程中將它的屬性設(shè)置為dont_touch，再編譯。
????????上圖中，U1和U3兩個模塊的設(shè)計名都沒有變化，只是在編譯D_design之前先將Ades編譯一次。這樣U1和U3實際上是一模一樣的模塊。
????????compile+dont_touch的實現(xiàn)方法如下
????????這里的約束文件有兩個，一個是Ades的Aconstraints.tcl，另一個是D_design的Dconstraints.tcl，并且在source后一個約束文件之前要對編譯過的Ades設(shè)置成dont_touch。
在設(shè)置了dont_touch屬性之后，編譯D_design的時候就會忽略Ades，這樣有好處也有壞處，好處是可以保護模塊不被修改，但是這樣同時也限制了DC對U1和U3的進一步的優(yōu)化。?
3、uniquify Vs compile + dont_touch
????????通過對上述兩種方法的介紹，我們不難看出它們各自的優(yōu)缺點——
????????compile+dont_touch由于只需要對多次例化的模塊編譯一次，因此可以減少整個設(shè)計的編譯時間，也可以減少內(nèi)存的使用量。在多次例化的模塊很復(fù)雜并且工作站的硬件條件有限的情況下，使用這種方法的優(yōu)越性的比較明顯的。還有，如果這個Ades是一個第三方提供的硬核(hard-core)，那么我們也只能使用這種方法。
????????使用這種方法的缺陷也是顯而易見的：由于頂層模塊在編譯的時候Ades設(shè)置了dont_touch，這就妨礙了DC針對Ades的各個實例周圍環(huán)境的不同的進一步優(yōu)化，從而使得結(jié)果不能真實的反映各個實例周圍的環(huán)境變化。
????????uniquify由于把各個多例化模塊作為獨立的模塊來看，因此DC可以分別針對它們作出更好的優(yōu)化，從而得到的結(jié)果也是比較理想的。缺點就是編譯的時間稍微較長，但是對于一些不大的模塊來說，這些是可以忽略的。????????
????????正因為uniquify可以綜合出更好的結(jié)果，所以如果一般推薦使用uniquify解決多例化模塊的綜合問題。
總結(jié)
以上是生活随笔為你收集整理的Design Compiler指南——设计综合过程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【例3-4】求后序遍历
- 下一篇： 【算法学习】整体二分