1. 從靜態(tài)時(shí)序分析到PrimeTime為什么我們需要它如果你做過(guò)數(shù)字芯片設(shè)計(jì)不管是前端RTL編碼還是后端物理實(shí)現(xiàn)肯定都聽(tīng)過(guò)“時(shí)序收斂”這個(gè)詞。簡(jiǎn)單來(lái)說(shuō)就是確保芯片里的所有信號(hào)都能在時(shí)鐘規(guī)定的“節(jié)拍”內(nèi)穩(wěn)定地從一個(gè)寄存器傳到下一個(gè)寄存器。聽(tīng)起來(lái)像是個(gè)物理問(wèn)題對(duì)吧但真正動(dòng)手去“收斂”時(shí)序時(shí)你會(huì)發(fā)現(xiàn)這更像是一場(chǎng)與邏輯、約束和工具之間的復(fù)雜博弈。早期我們可能用一些簡(jiǎn)單的腳本或者綜合工具自帶的時(shí)序報(bào)告來(lái)檢查但隨著設(shè)計(jì)規(guī)模膨脹到千萬(wàn)門(mén)甚至上億門(mén)時(shí)鐘結(jié)構(gòu)變得復(fù)雜多時(shí)鐘域、動(dòng)態(tài)頻率縮放再加上各種工藝角PVT和片上變異OCV的影響靠“感覺(jué)”和“簡(jiǎn)單工具”已經(jīng)完全不夠用了。這時(shí)候就需要一個(gè)專(zhuān)業(yè)的、獨(dú)立的、且足夠強(qiáng)大的“裁判”——靜態(tài)時(shí)序分析STA工具。而Synopsys的PrimeTime就是這個(gè)領(lǐng)域的行業(yè)標(biāo)桿。它不是用來(lái)做設(shè)計(jì)的而是用來(lái)“審判”設(shè)計(jì)的。PrimeTime會(huì)在你設(shè)計(jì)的最后階段介入基于最真實(shí)的網(wǎng)表、最精確的寄生參數(shù)和最嚴(yán)苛的時(shí)序約束對(duì)整個(gè)芯片的時(shí)序路徑進(jìn)行一次無(wú)死角的“大體檢”。它不關(guān)心功能只關(guān)心時(shí)間建立時(shí)間Setup Time、保持時(shí)間Hold Time、時(shí)鐘門(mén)控檢查、數(shù)據(jù)到數(shù)據(jù)檢查等等。它的報(bào)告會(huì)告訴你哪條路徑慢了哪條路徑快了哪個(gè)時(shí)鐘域有問(wèn)題讓你在流片前把所有的時(shí)序風(fēng)險(xiǎn)都暴露出來(lái)。所以學(xué)習(xí)PrimeTime本質(zhì)上是在學(xué)習(xí)一套完整的芯片時(shí)序簽核Sign-off方法論。這不是一個(gè)可選項(xiàng)而是確保芯片能正常工作的必修課。很多人覺(jué)得PrimeTime只是跑個(gè)命令、看個(gè)報(bào)告但真正的高手懂得如何駕馭它如何解讀它報(bào)告背后的深層信息如何利用它來(lái)指導(dǎo)前端優(yōu)化和后端布局布線。接下來(lái)我就結(jié)合自己的踩坑經(jīng)驗(yàn)拆解PrimeTime學(xué)習(xí)中的幾個(gè)核心關(guān)卡。2. 環(huán)境搭建與基礎(chǔ)流程別在第一步就卡住工欲善其事必先利其器。PrimeTime的學(xué)習(xí)往往從搭建一個(gè)能跑起來(lái)的流程開(kāi)始。這一步看似簡(jiǎn)單卻埋著不少新手容易忽略的“暗樁”。2.1 安裝與License繞不開(kāi)的“門(mén)檻”P(pán)rimeTime是Synopsys EDA工具鏈的一部分通常不是獨(dú)立安裝的。你需要一個(gè)完整的Synopsys環(huán)境并且配置好正確的License。這里最容易出問(wèn)題的地方有兩個(gè)一是環(huán)境變量二是License特性。環(huán)境變量尤其是LM_LICENSE_FILE或SNPSLMD_LICENSE_FILE必須指向有效的License服務(wù)器。更關(guān)鍵的是你的License文件里必須包含PrimeTime的特性Feature。你可以用lmstat或snpslmd命令來(lái)檢查。我遇到過(guò)好幾次環(huán)境變量設(shè)對(duì)了但跑起來(lái)報(bào)錯(cuò)“找不到合適的license”一查才發(fā)現(xiàn)License里根本沒(méi)有購(gòu)買(mǎi)PT的模塊。所以第一步永遠(yuǎn)是確認(rèn)你的工具有“入場(chǎng)券”。另一個(gè)細(xì)節(jié)是啟動(dòng)命令。PrimeTime有交互模式pt_shell和批處理模式primetime。對(duì)于學(xué)習(xí)和小規(guī)模調(diào)試交互模式非常方便但對(duì)于大型項(xiàng)目簽核一定是寫(xiě)Tcl腳本用批處理模式。建議新手從交互模式入手熟悉基本命令后再轉(zhuǎn)向腳本化。2.2 基礎(chǔ)流程四步走讀入、約束、分析、報(bào)告一個(gè)最精簡(jiǎn)的PrimeTime分析流程可以概括為四個(gè)步驟。我們用一個(gè)最簡(jiǎn)單的例子來(lái)串講。第一步讀入設(shè)計(jì)Read Design這里讀入的不是RTL而是門(mén)級(jí)網(wǎng)表Netlist通常是綜合后或布局布線后帶有時(shí)序信息的.v或.vh文件以及對(duì)應(yīng)的工藝庫(kù)文件.lib。# 設(shè)置搜索路徑和庫(kù)文件 set search_path “. /path/to/libs” set link_library “* typical.db” set target_library “typical.db” # 讀入門(mén)級(jí)網(wǎng)表 read_verilog my_design_post_synth.v # 鏈接設(shè)計(jì)解析所有模塊引用 link_design注意link_library和target_library的設(shè)置是關(guān)鍵。link_library用于解析設(shè)計(jì)中的模塊實(shí)例化包括標(biāo)準(zhǔn)單元和IP*表示也搜索內(nèi)存中的設(shè)計(jì)target_library是綜合或優(yōu)化時(shí)映射到的目標(biāo)工藝庫(kù)。如果這里設(shè)錯(cuò)會(huì)導(dǎo)致鏈接失敗或使用錯(cuò)誤的庫(kù)單元。第二步施加約束Apply Constraints這是STA的靈魂。約束告訴PrimeTime你的設(shè)計(jì)應(yīng)該以怎樣的時(shí)鐘頻率工作輸入輸出端口有什么時(shí)序要求。不完整或不正確的約束會(huì)導(dǎo)致分析結(jié)果毫無(wú)意義。# 創(chuàng)建時(shí)鐘周期10ns占空比50%起點(diǎn)在0時(shí)刻 create_clock -name CLK -period 10 -waveform {0 5} [get_ports clk] # 設(shè)置輸入延遲假設(shè)外部驅(qū)動(dòng)芯片的延遲是2ns set_input_delay -clock CLK -max 2 [get_ports data_in] # 設(shè)置輸出延遲假設(shè)外部接收器需要1ns set_output_delay -clock CLK -max 1 [get_ports data_out] # 設(shè)置虛假路徑比如測(cè)試邏輯不需要分析 set_false_path -from [get_ports test_mode] -to [all_registers] # 設(shè)置多周期路徑某些計(jì)算需要多個(gè)周期完成 set_multicycle_path -setup 2 -from [get_pins calc_start_reg/Q] -to [get_pins result_reg/D]約束的學(xué)問(wèn)極深上面只是冰山一角。如何建模時(shí)鐘不確定性set_clock_uncertainty、如何設(shè)置理想網(wǎng)絡(luò)set_ideal_network、如何定義時(shí)鐘組set_clock_groups每一個(gè)都需要結(jié)合具體設(shè)計(jì)場(chǎng)景來(lái)斟酌。第三步執(zhí)行時(shí)序分析Run Analysis在約束設(shè)置好后就可以讓PrimeTime進(jìn)行計(jì)算了。# 更新時(shí)序執(zhí)行全芯片的時(shí)序計(jì)算 update_timing這個(gè)命令會(huì)基于當(dāng)前的網(wǎng)表、約束和庫(kù)計(jì)算所有時(shí)序路徑的Slack裕量。Slack為負(fù)表示時(shí)序違規(guī)Violation。第四步生成報(bào)告Generate Reports分析完成后我們需要查看結(jié)果定位問(wèn)題。# 報(bào)告最差的建立時(shí)間裕量路徑Top N條 report_timing -delay_type max -max_paths 10 -slack_lesser_than 0 setup_vio.rpt # 報(bào)告最差的保持時(shí)間裕量路徑 report_timing -delay_type min -max_paths 10 -slack_lesser_than 0 hold_vio.rpt # 報(bào)告整個(gè)設(shè)計(jì)的時(shí)序總結(jié) report_constraint -all_violators all_vios.rptreport_timing是使用最頻繁的命令它的參數(shù)非常多-from,-to,-through可以用來(lái)篩選特定路徑-nets可以顯示線網(wǎng)延遲-capacitance可以看負(fù)載電容熟練掌握這些參數(shù)是高效調(diào)試的基礎(chǔ)。3. 約束的藝術(shù)從“能用”到“精準(zhǔn)”如果說(shuō)PrimeTime引擎是強(qiáng)大的計(jì)算器那時(shí)序約束就是輸入的計(jì)算公式。公式錯(cuò)了結(jié)果再精確也沒(méi)用。很多時(shí)序問(wèn)題根源都在約束。這一章我們深入幾個(gè)約束的深水區(qū)。3.1 時(shí)鐘約束不只是周期和占空比創(chuàng)建時(shí)鐘create_clock是最基本的但真實(shí)世界的時(shí)鐘遠(yuǎn)非一個(gè)理想方波。生成時(shí)鐘Generated Clocks這是最容易出錯(cuò)的地方之一。比如設(shè)計(jì)中有個(gè)PLL輸入基準(zhǔn)時(shí)鐘100MHz輸出400MHz。你不僅要約束源頭的100MHz時(shí)鐘還必須正確定義那個(gè)400MHz的生成時(shí)鐘。create_clock -name CLK_REF -period 10 [get_ports ref_clk] # 錯(cuò)誤做法直接create_clock一個(gè)400MHz在PLL輸出端。這割裂了與源時(shí)鐘的關(guān)系。 # 正確做法用create_generated_clock create_generated_clock -name CLK_CORE -source [get_pins pll/CLKIN] -divide_by 1 -multiply_by 4 [get_pins pll/CLKOUT]-source指明了這個(gè)生成時(shí)鐘的“父親”工具會(huì)自動(dòng)推導(dǎo)其與源時(shí)鐘的相位、不確定性關(guān)系。如果定義錯(cuò)誤會(huì)導(dǎo)致跨這兩個(gè)時(shí)鐘域的路徑分析完全錯(cuò)亂。時(shí)鐘不確定性Clock Uncertainty這個(gè)值是對(duì)時(shí)鐘網(wǎng)絡(luò)本身不完美的建模包括時(shí)鐘抖動(dòng)Jitter和時(shí)鐘偏斜Skew。在預(yù)布局階段這個(gè)值要設(shè)得保守一些比如周期10ns設(shè)0.5ns在布線后有了真實(shí)的時(shí)鐘樹(shù)信息可以用set_propagated_clock讓工具使用計(jì)算出的實(shí)際偏斜此時(shí)不確定性可以設(shè)小或?yàn)榱恪；煜@兩個(gè)階段的不確定性設(shè)置是導(dǎo)致前后時(shí)序報(bào)告對(duì)不上的常見(jiàn)原因。時(shí)鐘延遲Clock Latency和不確定性類(lèi)似在時(shí)鐘樹(shù)綜合CTS前需要用set_clock_latency設(shè)置一個(gè)預(yù)估的源延遲Source Latency從時(shí)鐘源到芯片端口的延遲和網(wǎng)絡(luò)延遲Network Latency從端口到寄存器時(shí)鐘端的延遲。CTS后用set_propagated_clock替代。3.2 輸入/輸出延遲與外部世界握手set_input_delay和set_output_delay定義了芯片端口相對(duì)于某個(gè)時(shí)鐘沿的時(shí)序要求。這里最大的誤區(qū)是這個(gè)延遲值不是芯片內(nèi)部產(chǎn)生的而是對(duì)外部環(huán)境的建模。對(duì)于輸入端口set_input_delay -max 3 -clock CLK [get_ports data_in]表示數(shù)據(jù)信號(hào)data_in在時(shí)鐘CLK的有效沿比如上升沿之后最多經(jīng)過(guò)3ns就會(huì)到達(dá)芯片的輸入端口。這3ns包含了外部驅(qū)動(dòng)器的延遲和板級(jí)走線延遲。所以這個(gè)值越大留給芯片內(nèi)部用這個(gè)數(shù)據(jù)的路徑時(shí)間就越短建立時(shí)間要求更嚴(yán)。對(duì)于輸出端口set_output_delay -max 2 -clock CLK [get_ports data_out]表示芯片輸出端口的數(shù)據(jù)必須在時(shí)鐘CLK有效沿之后2ns內(nèi)穩(wěn)定地送到外部接收器的輸入端。這2ns是留給外部接收器的采樣時(shí)間。所以這個(gè)值越大對(duì)芯片內(nèi)部產(chǎn)生這個(gè)數(shù)據(jù)的速度要求就越快建立時(shí)間要求更嚴(yán)。理解這個(gè)“外部視角”至關(guān)重要。我見(jiàn)過(guò)有人把內(nèi)部組合邏輯延遲直接當(dāng)成output_delay設(shè)置結(jié)果導(dǎo)致約束完全失真工具優(yōu)化方向錯(cuò)誤。3.3 時(shí)序例外Timing Exceptions告訴工具“別管這里”時(shí)序例外是約束里最需要小心謹(jǐn)慎的部分用對(duì)了事半功倍用錯(cuò)了掩蓋致命問(wèn)題。虛假路徑False Path這條路徑在物理上存在但在功能上永遠(yuǎn)不會(huì)被用到。比如從測(cè)試模式信號(hào)到功能邏輯的路徑。設(shè)置虛假路徑能減少工具優(yōu)化負(fù)擔(dān)讓報(bào)告更干凈。但必須百分百確定它真的是“虛假”的。我犯過(guò)的一個(gè)錯(cuò)誤是把一個(gè)異步復(fù)位域到正常工作域的路徑設(shè)成了false path理由是“它們不同時(shí)有效”。但實(shí)際上復(fù)位釋放的瞬間可能存在競(jìng)爭(zhēng)這恰恰是需要檢查的恢復(fù)時(shí)間Recovery和移除時(shí)間Removal路徑。經(jīng)驗(yàn)法則對(duì)任何跨時(shí)鐘域CDC的路徑除非有經(jīng)過(guò)驗(yàn)證的同步器否則不要輕易設(shè)false path。多周期路徑Multicycle Path允許信號(hào)在多個(gè)時(shí)鐘周期內(nèi)穩(wěn)定。比如一個(gè)迭代計(jì)算單元從啟動(dòng)到輸出結(jié)果需要3個(gè)周期。這時(shí)你需要用set_multicycle_path -setup 3來(lái)告訴工具建立時(shí)間檢查放寬到3個(gè)周期后。同時(shí)必須配套設(shè)置保持時(shí)間檢查set_multicycle_path -hold 2。為什么是2因?yàn)楸３謺r(shí)間檢查默認(rèn)是相對(duì)于啟動(dòng)沿的前一個(gè)沿。設(shè)置多周期路徑后保持時(shí)間檢查應(yīng)該對(duì)應(yīng)到新的有效啟動(dòng)沿之前的一個(gè)沿。這個(gè)“setup N, hold N-1”的規(guī)則是新手必踩的坑設(shè)置不對(duì)會(huì)導(dǎo)致保持時(shí)間違規(guī)被錯(cuò)誤地掩蓋或產(chǎn)生。4. 深度解讀時(shí)序報(bào)告從“看紅字”到“挖根因”跑完分析滿屏的違規(guī)Violation新手容易慌。高手則淡定地打開(kāi)報(bào)告像偵探一樣開(kāi)始排查。report_timing的報(bào)告結(jié)構(gòu)是有固定套路的讀懂每一部分的含義才能定位真正的問(wèn)題。4.1 解剖一條時(shí)序路徑報(bào)告我們看一條典型的建立時(shí)間違規(guī)報(bào)告簡(jiǎn)化版Point Incr Path -------------------------------------------------------------------- clock CLK (rise edge) 0.00 0.00 clock network delay (ideal) 0.50 0.50 u_ff1/CLK (DFFX1) 0.00 0.50 r u_ff1/Q (DFFX1) 0.15 0.65 f u_combo_logic/A (AND2X1) 0.00 0.65 f u_combo_logic/Z (AND2X1) 0.40 1.05 f net (wire load model) 0.30 1.35 f u_ff2/D (DFFX1) 0.00 1.35 f data arrival time 1.35 -------------------------------------------------------------------- clock CLK (rise edge) 10.00 10.00 clock network delay (ideal) 0.60 10.60 clock uncertainty -0.20 10.40 u_ff2/CLK (DFFX1) 0.00 10.40 r library setup time -0.10 10.30 data required time 10.30 -------------------------------------------------------------------- data required time 10.30 data arrival time -1.35 ------------------------------------------------------------- slack (VIOLATED) -8.95路徑起點(diǎn)Startpointu_ff1被時(shí)鐘CLK觸發(fā)的寄存器。路徑終點(diǎn)Endpointu_ff2也是被CLK觸發(fā)的寄存器。數(shù)據(jù)到達(dá)時(shí)間Data Arrival Time從啟動(dòng)時(shí)鐘沿0ns開(kāi)始經(jīng)過(guò)時(shí)鐘延遲到u_ff10.5ns再經(jīng)過(guò)u_ff1的CK-Q延遲0.15ns再經(jīng)過(guò)中間組合邏輯與線網(wǎng)的延遲0.40.30.7ns總共1.35ns時(shí)數(shù)據(jù)到達(dá)u_ff2的D端。數(shù)據(jù)要求時(shí)間Data Required Time在捕獲時(shí)鐘沿10ns到達(dá)u_ff2的CLK端時(shí)10.6ns減去時(shí)鐘不確定性0.2ns再減去寄存器本身的建立時(shí)間要求0.1ns得到數(shù)據(jù)最晚必須在10.30ns之前穩(wěn)定。裕量Slack要求時(shí)間 - 到達(dá)時(shí)間 10.30 - 1.35 8.95ns。等等這是正數(shù)啊注意看報(bào)告最后slack是-8.95。這里是個(gè)關(guān)鍵報(bào)告顯示的數(shù)據(jù)到達(dá)時(shí)間是1.35但計(jì)算slack時(shí)工具是用“要求時(shí)間”減去“到達(dá)時(shí)間”。如果到達(dá)時(shí)間早于要求時(shí)間slack為正。但這里顯示為負(fù)說(shuō)明我們看報(bào)告時(shí)可能漏掉了關(guān)鍵信息這條路徑可能是最小延遲Hold路徑或者時(shí)鐘關(guān)系復(fù)雜。在建立時(shí)間報(bào)告中如果數(shù)據(jù)到達(dá)時(shí)間起點(diǎn)晚于要求時(shí)間終點(diǎn)slack才為負(fù)。這個(gè)例子中數(shù)據(jù)到達(dá)1.35ns遠(yuǎn)早于要求10.30ns理論上slack應(yīng)為正。出現(xiàn)負(fù)值極有可能是時(shí)鐘定義有問(wèn)題比如終點(diǎn)時(shí)鐘沿不是10ns后而是更早例如是同一個(gè)沿那要求時(shí)間可能就是0.3ns左右。這恰恰說(shuō)明了不能只看最后的slack數(shù)字必須從頭理解整條路徑的時(shí)鐘關(guān)系。4.2 關(guān)鍵參數(shù)為什么是它慢了當(dāng)確定一條路徑違規(guī)后下一步是看Incr增量延遲一欄找出延遲最大的環(huán)節(jié)。單元延遲Cell Delay比如上面例子中u_combo_logic/Z的0.40ns。這可能是該單元驅(qū)動(dòng)能力太弱選擇的小驅(qū)動(dòng)單元也可能是輸入轉(zhuǎn)換時(shí)間Input Transition太差導(dǎo)致單元本身延遲大。線網(wǎng)延遲Net Delay比如上面的0.30ns。在預(yù)布局階段這是由線負(fù)載模型Wire Load Model估算的在布局布線后這是根據(jù)實(shí)際RC參數(shù)提取的。過(guò)大的線網(wǎng)延遲通常意味著扇出Fanout過(guò)大一個(gè)輸出驅(qū)動(dòng)了太多輸入或者布線距離太長(zhǎng)。時(shí)鐘網(wǎng)絡(luò)延遲Clock Network Delay啟動(dòng)時(shí)鐘和捕獲時(shí)鐘的延遲差異上面是0.5 vs 0.6相差0.1ns。在時(shí)鐘樹(shù)綜合前這是你設(shè)置的set_clock_latency差異在時(shí)鐘樹(shù)綜合后這是實(shí)際的時(shí)鐘偏斜Skew。如果這個(gè)差值很大說(shuō)明時(shí)鐘樹(shù)平衡做得不好。4.3 高級(jí)調(diào)試命令定位瓶頸除了看標(biāo)準(zhǔn)報(bào)告PrimeTime提供了更強(qiáng)大的調(diào)試命令# 查看一個(gè)線網(wǎng)或引腳上的負(fù)載情況 report_net [get_nets net_name] # 這會(huì)列出該線網(wǎng)驅(qū)動(dòng)的所有引腳以及總的電容、電阻對(duì)診斷大扇出問(wèn)題非常有用。 # 查看一個(gè)單元的時(shí)序弧Timing Arc信息 report_delay_calculation -from [get_pins u_combo_logic/A] -to [get_pins u_combo_logic/Z] # 這會(huì)詳細(xì)展示工具計(jì)算該單元延遲的過(guò)程用了哪個(gè)查找表LUT、輸入轉(zhuǎn)換時(shí)間、輸出負(fù)載電容最終得出延遲值。當(dāng)你懷疑庫(kù)模型或計(jì)算不準(zhǔn)時(shí)可以用這個(gè)命令深挖。 # 檢查時(shí)鐘門(mén)控Clock Gating時(shí)序 report_clock_gating_check # 時(shí)鐘門(mén)控電路有特殊的建立/保持時(shí)間檢查門(mén)控時(shí)鐘相對(duì)于數(shù)據(jù)時(shí)鐘這個(gè)命令能專(zhuān)門(mén)報(bào)告這類(lèi)檢查的違例。5. 應(yīng)對(duì)時(shí)序違例的實(shí)戰(zhàn)策略看到違例不要只想著“優(yōu)化這條路徑”。要系統(tǒng)性地思考從約束、設(shè)計(jì)、實(shí)現(xiàn)三個(gè)層面去找解決方案。5.1 約束層面復(fù)查是不是自己綁住了手腳這是成本最低的修復(fù)方式。首先問(wèn)自己時(shí)鐘定義對(duì)嗎生成時(shí)鐘的source、分頻/倍頻關(guān)系對(duì)嗎時(shí)鐘不確定性是否設(shè)得過(guò)于悲觀輸入/輸出延遲合理嗎是否與系統(tǒng)規(guī)格書(shū)一致有沒(méi)有可能和系統(tǒng)同事協(xié)商放寬一點(diǎn)時(shí)序例外正確嗎那條false path真的假嗎多周期路徑的hold設(shè)置對(duì)嗎工作條件Operating Condition選對(duì)了嗎你是在最差的工藝角SS, 125C, 0.9V下分析嗎有時(shí)在TT條件下違例在SS條件下反而沒(méi)事因?yàn)檠舆t變大hold更容易違例但setup可能變好這需要綜合判斷。5.2 設(shè)計(jì)層面優(yōu)化動(dòng)架構(gòu)還是動(dòng)代碼如果約束無(wú)誤違例真實(shí)存在那就要?jiǎng)釉O(shè)計(jì)了。流水線插入Pipelining對(duì)于長(zhǎng)的組合邏輯路徑最根本的解決辦法是插入寄存器將其打斷成多個(gè)周期完成。這需要修改RTL。邏輯重構(gòu)Logic Restructuring比如將關(guān)鍵路徑上的寬位加法器拆分成多個(gè)小位寬的加法器并行計(jì)算。或者用優(yōu)先級(jí)編碼代替譯碼器。操作數(shù)隔離Operand Isolation當(dāng)某些邏輯模塊的輸出在特定條件下不被使用時(shí)關(guān)閉其輸入避免無(wú)謂的翻轉(zhuǎn)和功耗有時(shí)也能減少關(guān)鍵路徑上的負(fù)載。寄存器重定時(shí)Retiming在不改變電路功能的前提下移動(dòng)組合邏輯兩邊的寄存器位置平衡路徑延遲。這個(gè)可以由綜合工具自動(dòng)完成。5.3 后端實(shí)現(xiàn)指令給布局布線工具下“軍令”在PrimeTime中你可以通過(guò)設(shè)置一些屬性Attributes來(lái)指導(dǎo)后端工具如IC Compiler, Innovus進(jìn)行針對(duì)性優(yōu)化。這些指令會(huì)保存在SDC約束文件中。# 對(duì)關(guān)鍵路徑上的單元禁止尺寸縮小防止變慢 set_size_only [get_cells u_critical_cell] true # 對(duì)關(guān)鍵網(wǎng)絡(luò)設(shè)置非默認(rèn)布線規(guī)則NDR比如雙倍寬度、雙倍間距以減少電阻電容 set_dont_touch [get_nets critical_net] # 然后在后端工具中對(duì)此net應(yīng)用NDR規(guī)則 # 對(duì)高扇出網(wǎng)絡(luò)插入緩沖器Buffer來(lái)改善驅(qū)動(dòng) set_high_fanout_net_threshold 50 # 或者手動(dòng)指定 set_load [expr [get_attribute [get_nets high_fanout_net] wire_load] * 0.5] [get_nets high_fanout_net]注意這些指令是“建議”后端工具會(huì)盡量遵守但并非絕對(duì)。最終效果需要重新布局布線后再用PrimeTime驗(yàn)證。5.4 PrimeTime自身優(yōu)化嘗試自動(dòng)修復(fù)PrimeTime也具備一定的優(yōu)化能力可以在門(mén)級(jí)網(wǎng)表上進(jìn)行增量綜合Incremental Synthesis。# 啟用設(shè)計(jì)優(yōu)化 set enable_recovery_removal_arcs true # 對(duì)建立時(shí)間違例進(jìn)行優(yōu)化比如提升單元驅(qū)動(dòng)強(qiáng)度插入緩沖器 optimize_netlist -area # 對(duì)保持時(shí)間違例進(jìn)行優(yōu)化比如插入延遲單元減小單元驅(qū)動(dòng)強(qiáng)度 fix_hold [get_clocks CLK]需要注意的是fix_hold通常用在時(shí)鐘樹(shù)綜合之后因?yàn)镃TS會(huì)顯著改變時(shí)鐘延遲引入大量的保持時(shí)間違例。這些優(yōu)化會(huì)改變網(wǎng)表需要重新保存并反饋給后端流程。6. 高級(jí)話題與簽核考量當(dāng)時(shí)序基本收斂后工作并未結(jié)束。進(jìn)入簽核階段還有幾座大山要翻越。6.1 片上變異OCV與先進(jìn)時(shí)序分析在先進(jìn)工藝下同一芯片上不同位置的晶體管其速度可能因?yàn)橹圃旒?xì)微差異而不同。這就是OCV。為了模擬最壞情況PrimeTime會(huì)引入降額因子Derate。# 設(shè)置全局時(shí)序降額讓早期路徑更慢晚期路徑更快加大分析裕量 set_timing_derate -early 0.9 -late 1.1 -cell_delay set_timing_derate -early 0.8 -late 1.2 -net_delay這會(huì)導(dǎo)致分析模式爆炸式增長(zhǎng)BC-WC, WC-BC。更先進(jìn)的方法是使用“圖同時(shí)序分析”Graph-Based Analysis, GBA和“路徑同時(shí)序分析”P(pán)ath-Based Analysis, PBA。GBA速度快但悲觀PBA更精確但慢。簽核時(shí)通常對(duì)關(guān)鍵路徑用PBA再驗(yàn)證一遍。6.2 噪聲與串?dāng)_分析Crosstalk相鄰信號(hào)線之間的電容耦合會(huì)導(dǎo)致噪聲可能使延遲增加Delta Delay或引發(fā)毛刺Glitch。PrimeTime SISignal Integrity模塊可以讀入提取的耦合電容SPEF格式進(jìn)行噪聲分析。read_parasitics -format spef post_route.spef update_timing -crosstalk report_timing -crosstalk_delta串?dāng)_修復(fù)通常在后端工具中進(jìn)行如屏蔽、布線間距調(diào)整但PrimeTime的分析結(jié)果是修復(fù)的依據(jù)。6.3 功耗與時(shí)序的權(quán)衡Power vs. Performance時(shí)序收斂往往以功耗為代價(jià)使用大驅(qū)動(dòng)單元、插入緩沖器。PrimeTime可以配合功耗分析工具如PrimeTime PX進(jìn)行動(dòng)態(tài)功耗分析。在優(yōu)化時(shí)序時(shí)可以加入功耗約束。set_max_total_power 100 mW在簽核階段需要同時(shí)滿足時(shí)序、功耗、面積PPA三大指標(biāo)這是一個(gè)反復(fù)迭代、權(quán)衡的過(guò)程。6.4 形式驗(yàn)證與時(shí)序約束一致性最后也是至關(guān)重要的一步確保你的時(shí)序約束SDC與RTL功能描述是一致的。用一個(gè)錯(cuò)誤的約束去簽核一個(gè)正確的設(shè)計(jì)結(jié)果可能是災(zāi)難性的。這就需要形式驗(yàn)證工具如Formality出場(chǎng)進(jìn)行“時(shí)序約束驗(yàn)證”Constraint Verification檢查SDC中的時(shí)鐘、端口約束是否與RTL的實(shí)際情況匹配。比如RTL里某個(gè)端口明明是異步的你的SDC卻對(duì)它加了一個(gè)時(shí)鐘約束形式驗(yàn)證就能把它抓出來(lái)。學(xué)習(xí)PrimeTime的過(guò)程就是一個(gè)不斷將理論時(shí)序原理與實(shí)踐工具命令、調(diào)試、修復(fù)相結(jié)合的過(guò)程。它沒(méi)有太多炫酷的技巧更多的是嚴(yán)謹(jǐn)、細(xì)致和系統(tǒng)性的思考。每一個(gè)違例背后都可能藏著約束、設(shè)計(jì)或物理實(shí)現(xiàn)的深層次問(wèn)題。把它當(dāng)成一個(gè)強(qiáng)大的合作伙伴而不僅僅是一個(gè)檢查工具你就能從“跑流程”進(jìn)化到“做簽核”。真正的挑戰(zhàn)不在于看懂報(bào)告上的紅字而在于理解那行紅字為何會(huì)出現(xiàn)以及從哪個(gè)維度去解決它才是最有效的。這需要跨前端、后端、方法學(xué)的綜合知識(shí)也正是數(shù)字芯片設(shè)計(jì)的魅力所在。