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