通常RTL設計要求對芯片/module的輸入信號進行reg_in打拍處理,對芯片/module的輸出也要求做reg_out打拍處理,這是良好的代碼習慣,為時序收斂留下足夠裕量,也避免頂層例化綜合后的子模塊時出現模塊間IO時序不滿足的情況。綜合階段可根據設計、工藝需求,設置IO的input/output為時鐘周期的40%-60%。
但是,芯片timing sign off階段會偶爾遇到IO時序少量違例,比如,輸入reg的hold違例、輸出reg的setup違例,本質原因是EDA時序分析工具會在輸出輸入外部假定一個理想化的不帶clock propagation time的寄存器做時序分析。
比如,在set_propagated_clock命令后,下圖左邊寄存器的CLK2端就不帶clock propagation time,而CLK1(與CLK2同頻同相)就帶insertion delay, 擁有時鐘latency,這樣輸入IO的hold違例就可能發(fā)生,setup反而更容易滿足。
同理,在set_propagated_clock命令后,輸出IO的setup違例就可能發(fā)生,hold反而更容易滿足。
以輸出IO的register的setup建立時間為例,launch clock的data path上由于存在1.5ns的propagation time/clock latency,發(fā)生了時序違例。這是因為外部假定的register是沒有propagation time/clock latency。而保持時間則反而容易滿足。
虛擬時鐘應運而生,那么如何創(chuàng)建虛擬時鐘?其有什么好處呢?
create_clock -name vclk -period 10
注意,創(chuàng)建虛擬時鐘不用指定clk pin/port。
set_input_delay8-clockvclk[get_portsdata_in ] set_output_delay8-clockvclk[get_portsdata_out]EDA工具會基于虛擬時鐘,根據芯片/模塊內部時鐘的實際insertion delay評估IO外部假定寄存器的propagation time,這樣時序分析就可以規(guī)避不必要的“假”違例,當然也可以不指定virtual clock,只是每次分析時序時都需要檢查并排除這種“假”違例,影響了工作效率。
在約束set_input_delay/set_output_delay時,可以指定真實時鐘CLKP,也可以指定虛擬時鐘vCLKP,并且創(chuàng)建與CLKP同頻率的虛擬時鐘vCLKP時,無需指定時鐘端口,參考腳本如下:
setperiod5 create_clock-nameCLKP-period$period[get_portsCLKP] create_clock-namevCLKP-period$period
在約束set_input_delay/set_output_delay時,是否使用虛擬時鐘在CTS之前是沒有區(qū)別的,可以認為都是理想時鐘,畢竟clock tree還沒實際建立,時序評估還不能使用propagated clock。而在CTS之后就有如下需要注意的地方:
1)如果指定的是真實時鐘,那么下圖中的Virtual flip-flop虛擬寄存器的時鐘延遲就被忽略了,或者說該虛擬寄存器會被EDA工具認為是理想模型,不帶clock propagated time。 2)如果指定的是虛擬時鐘,工具往往可以根據內部真實時鐘的平均延遲來估算外部虛擬寄存器的時鐘延遲,更加合理。
為了讓頂層的時序更容易滿足,一般會在IN2REG和REG2OUT過約束,可設置外部延遲為60%的時鐘周期,給內部的數據路徑留40%的空間。具體根據實際項目需求、設計規(guī)格、工藝條件等決定。
另外,set_input_delay要指定-max和-min選項,分別對應setup和hold時序檢查,如果只指定其中一個選項或都不指定,那么工具在檢查setup和hold時,會使用相同的值。
#參考值為0.6,根據實際情況調整 set_input_delay[expr0.6*$period]-clockvCLKP[get_portsCIN]
-
芯片
+關注
關注
456文章
50874瀏覽量
424130 -
寄存器
+關注
關注
31文章
5346瀏覽量
120481 -
RTL
+關注
關注
1文章
385瀏覽量
59827 -
虛擬時鐘
+關注
關注
0文章
5瀏覽量
6599
原文標題:為什么要用虛擬時鐘Virtual clock?
文章出處:【微信號:全棧芯片工程師,微信公眾號:全棧芯片工程師】歡迎添加關注!文章轉載請注明出處。
發(fā)布評論請先 登錄
相關推薦
評論