摘? 要: 介紹了時序分析" title="時序分析">時序分析" title="靜態時序分析" title="靜態時序分析">靜態時序分析">靜態時序分析在數字集成電路設計中的應用,并以100M以太" title="以太">以太網卡芯片設計為例,具體描述了以太網卡芯片設計中的靜態時序分析流程及其時序問題。
關鍵詞: 靜態時序分析? 100M以太網卡? 數字電路? 約束? 應用
?
集成電路自誕生以來,正如莫爾定律所預言的一樣,每隔18個月集成度就翻一番。目前的集成電路設計已經由早期的幾十μm減小到0.15μm,進入到了深亞微米級。在器件的特征尺寸降到深亞微米級的同時,器件的物理特性和電學特性也發生了很大的變化。器件本身固有延遲大大減小,而互連線所引起的延遲在整個單元延遲中所占的比例越來越大,因而時序不收斂是深亞微米集成電路設計中最常見的問題。在深亞微米集成電路設計中,傳統的分析方法使前端的邏輯設計與后端的物理設計很難保持一致。在邏輯設計中,仿真分析后功能和時序都正確的網表,卻由于布線設計后芯片空間和連線的限制,造成互連引線延遲與邏輯設計中使用的模型不一致,使得時序不再滿足約束要求,導致邏輯設計和物理設計循環不收斂,從而使設計周期大大加長。因此,傳統的分析方法在復雜的SOC設計面前,顯得無能為力,而成為整個設計流程中的瓶頸。
在這種情形下,靜態時序分析應運而生,它不僅可以根據設計規范的要求對設計進行檢查,同時還能對設計本身做全面的分析。靜態時序分析是相對于動態時序分析而言的。動態時序分析時不可能產生完備的測試向量,覆蓋門級網表中的每一條路徑。因此在動態時序分析中,無法暴露一些路徑上可能存在的時序問題;而靜態時序分析,可以方便地顯示出全部路徑的時序關系,因此逐步成為集成電路設計簽字認可的標準。
本文以100M以太網卡芯片的設計為基礎,以靜態時序分析工具PrimeTime為參考工具,以Verilog語言為參考硬件描述語言，探討100M以太網卡芯片設計中的靜態時序分析流程及其時序問題。
1 100M以太網卡的結構
100M以太網卡是一塊高集成度的快速以太網控制器,它支持IEEE802.3和802.3u協議及PCI v2.2總線接口協議,還支持10M/100M自適應功能。此芯片包括PCI接口模塊、兩個2KB的FIFO模塊、發送DMA控制模塊、接收DMA控制模塊、IEEE 802.3協議規定的MAC模塊和10/100M 集成物理層(PHY)模塊。此外,還提供了EEPROM接口和擴展BootROM接口。從整體來看,它是包含數字電路和模擬電路的混合型集成電路芯片。它采用的是0.25μm工藝,四層金屬層。圖1是該100M以太網卡的結構框架圖。
?
2 100M以太網卡設計的靜態時序分析
100M以太網卡芯片的時鐘關系如圖2所示。pmapmd是網卡芯片物理層的模擬電路部分,digital是網卡芯片物理層的數字電路部分,core則是指網卡芯片除物理層之外的部分。純模擬模塊pmapmd通過晶振產生五個時鐘:f125m、f20m、f50m、t100rxc、t10rxc，提供給digital;digital提供PRXC、PTXC、clk_10Hz;clk_1kHz四個時鐘給core模塊。pci_clk是外部時鐘,通過PCIPAD提供給digital和core;同時,pci_clk還通過一個PCIbuffer產生一個與pci_clk相位不同但頻率相同的時鐘PADCLK提供給core。
?
由于該100M以太網卡芯片比較復雜,同時還要滿足一些特殊的功能需要,所以在該網卡的設計過程中存在許多時序分析問題需要解決。首先,該網卡的大部分PAD都是雙向的。在有些模塊中,外部輸入輸出接口的時序限制是參照內部時鐘進行限定的。其次,為了省電,在該網卡內部設有許多選通時鐘(Gate Clock)和內部時鐘,多個時鐘之間的信號連接會帶來相應的麻煩。
圖3是100M以太網卡靜態時序分析流程圖。
?
2.1?時鐘的定義
在靜態時序分析中,時鐘的定義是設定限制的最重要的一個步驟,因為靜態時序分析本來就是基于時序進行分析的,而絕大多數的時序路徑的計算又都是以時鐘為基礎的。所謂時鐘定義是指對于設計中所用到的時鐘設定名稱、周期、相位、占空比。在Primetime中用如下命令來實現:
create_clock -name? [NAME] -period [P] -wave [rising_time falling_time] object_name
由于100M以太網卡芯片的門數較多,時鐘關系也比較復雜,所以對不同關系的時鐘,定義方法也不一樣。圖4給出三個不同關系的時鐘。
?
(1)CLK1和CLK2有兩種關系:一種是CLK1和 CLK2來自網卡外部毫無聯系的晶振,其相位關系是不確定的。根本無法通過Primetime正確地檢查它們之間的時序關系,但是可以正確地檢查單獨經過CLK1或是CLK2的路徑的時序。另一種是CLK1和CLK2是頻率不一致的時鐘,例如通過RxDMA控制寫RxFIFO和讀RxFIFO的時鐘頻率是不一樣的,MII通過RxDMA控制寫RxFIFO的頻率為25MHz，而PCI通過RxDMA控制讀RxFIFO的頻率是33MHz。對于這樣的異步設計,一般不是通過Primetime的報告保證其時序關系,而應該在寫代碼時就必須保證該部分的時序關系正確。所以若碰到這種情況,做靜態時序分析時一般要進行如下處理;
set_false_path -setup-from CLK1 -to CLK2
(2)CLK3是由CLK1通過組合邏輯產生的,其相移就是這些組合邏輯的延時,經過第一遍綜合之后,該延時便可從時序報告中得出,這樣就可以根據此延時對這兩個時鐘的關系給出正確的設定。在Primetime中，有以下兩種方法可以設定:
一種方法是分別定義時鐘CLK1和CLK3,并將其rising_time、period和占空比設為相同,然后再通過時鐘延時的設定來區分兩者的不同相位。當然時鐘延時的差值應該由所提之的組合邏輯延時決定。
另一種方法是只定義時鐘CLK1，再用如下命令定義CLK3：
create_generated_clock -name CLK3 -source? P1 -
divide_by 1? DFF3/ck
這樣,在布局布線" title="布局布線">布局布線之后做靜態時序分析時,CLK1被設為propagated_clock， Primetime就可以根據兩時鐘之間的延時關系來算出CLK3的特性(包括時鐘延時、時鐘抖動等),無需再另行推算。而前一方法比較適用于布局布線之前的靜態時序分析,因為這時所有的時鐘都被設為理想的,其時鐘延時、時鐘抖動和時鐘傳輸時間等都是根據實際情況來設定的。只有當源時鐘為propagated_clock時,Primetime才會自動推算CLK3的特性,否則仍需要設置。
2.2 邊界時鐘
由于100M以太網卡某些模塊涉及到邊界時鐘,所以必須考慮邊界時鐘引起的時鐘延時問題。所謂邊界時鐘是指某模塊的輸入輸出和時序限制是以某個特定的時鐘作基準的,而該時鐘是由外部時鐘分頻得到的。
但在布局布線之后做靜態時序分析時,并不用費心去計算邊界時鐘引起的時鐘時延,而是把它交給Primetime完成。正如前面所提到的,當源時鐘為propagated_clock時,Primetime會自動計算所生成時鐘的相關延時。
2.3 輸入輸出延時的聲明
做靜態時序分析時，要根據端口時序圖聲明輸入輸出延時,而不是根據內部延時確定端口時序。下面給出延時聲明和端口時序聲明之間的簡單計算公式。假設時鐘周期為T,時鐘從端口到寄存器的延時是Tx,數據從端口到寄存器的延時是Ty,工藝給定的setup_time是Tsetup,hold_time是Thold,端口時序聲明給出的輸入數據在時鐘采樣沿之前保持有效的最小時間是Tsu,輸入數據在采樣時鐘沿之后保持有效的時間是Tkeep,端口時序聲明給出采樣時鐘沿到輸出數據有效的最長時間是Tdelay。在做靜態時序分析時應保證以下關系成立:
Tsu+Tx-Ty>Tsetup????????????? (1)
Tkeep-Tx+Ty>Thold???? ???? (2)
根據輸入延時和輸出延時的定義和公式(1)和(2),可以得出最大輸入延時是:
Tinput_delay=T-Tsu????????????(3)
最大輸出延時是:
Toutput_delay=T-Tdelay???????? (4)
根據公式(3)以及圖5的端口時序圖可以定義圖5的最大輸入延時是:
Tinput_delay=Tclk-q + TM???????(5)
根據公式(4)以及圖5的端口時序圖可以定義圖5的最大的輸出延時是:
Toutput_delay=TS+Tsetup????????(6)
?
2.4?時序報告分析
靜態時序分析是采用窮盡分析方法來提取出整個電路存在的所有時序路徑,計算信號在這些路徑上的傳播延時,檢查信號的建立和保持時間" title="保持時間">保持時間是否滿足時序要求,通過對最大路徑延時和最小路徑延時的分析,找出違背時序約束的錯誤。因此分析靜態時序分析的報告是非常必要的。
下面是以100M以太網卡地址識別邏輯模塊作靜態時序分析時所產生的報告的一部分。
*******************************************
Report ： timing
??????? -path full
??????? -delay max
??????? -max_paths 1
Design ： ARLcore
Version： 2000.05-1
Date?? ： Fri Nov 21 15：38：25 2002
*******************************************
Startpoint： ARLdp/n_DAValidsN_reg
(falling edge-triggered flip-flop clocked by TXC)
Endpoint： ARLsm/Cstate_reg[3]
(rising edge-triggered flip-flop clocked by TXC)
? Path Group： TXC
? Path Type： min
?????? Point????????????????????? ? Incr??? Path
??? ——————————————————————————
clock TXC (fall edge)?????????????? 5.00?? ?? 15.00
clock network delay
(ideal)??????????????????????????? 1.00?? ?? 16.00
ARLdp/n_DAValidsN_reg
/CPN (dfpfb1)?????????????????????? 0.00????? 16.00 f
ARLdp/n_DAValidsN_reg/Q
(dfpfb1)????????????????????????????0.56????? 16.56 f
ARLdp/U394/Z (an02d1)? ???????????? 0.25????? 16.80 f
ARLdp/n_DAValids (ARLdp)?? ???????? 0.00????? 16.80 f
ARLsm/n_DAValids (ARLsm)?? ???????? 0.00????? 16.80 f
ARLsm/U260/Z (an04d1)?????????????? 0.27????? 17.08 f
ARLsm/U294/Z (aor21d1)????????????? 0.27????? 17.34 f
ARLsm/U291/Z (aor21d1)????????????? 0.30????? 17.64 f
ARLsm/Cstate_reg[3]/D
(dfcrq2)???????????????????? ?????? 0.00????? 17.64f
data arrival time????????????????????? ?????? 17.64
clock TXC (rise edge)???????? ????? 20.00???? 20.00
clock network delay
?(ideal)???????????????????? ???????? 1.00????? 21.00
ARLsm/Cstate_reg[3]/CP
?(dfcrq2)?????????????????? ????????? 0.00????? 21.00r
library hold time???????????? ????? 0.50????? 21.50
data required time?????????????????? ???????? 21.50
........................................................
??? ……
data required time?????????????????? ???????? 21.50
data arrival time?????????????????????????????-17.64
?? ————————————————————————————
slack (MET)??????????????????? ?????????????? 3.86
從報告中可以看出它非常詳細地報告了從Startpoint：ARLdp/n_DAValidsN_reg到 Endpoint：ARLsm/Cstate_reg[3]這條路徑的時序關系,并且這條路徑是滿足保持時間的。
靜態時序分析在不同階段的側重點是不一樣的。在布局布線前,往往更重視建立時間檢查,而忽視保持時間檢查。如果違背了建立時間,就必須重新優化。至于違背了保持時間,可以通過在布局布線后手工加入一定的延時來解決,在布局布線后,應重點檢查保持時間。
在100M以太網卡芯片設計中,通過做靜態時序分析,確認了其設計的可靠性,為設計獲得簽字認可起到了保證性的作用。
靜態時序分析是分析、診斷和確認設計的時序特性的方法。它不需要輸入向量就能窮盡所有的路徑,且運行速度很快、占用內存較少,不僅可以對芯片設計進行全面的時序功能檢查,而且還可利用時序分析的結果來優化設計,因此靜態時序分析已經越來越多地被用到數字集成電路設計的驗證中。
?
參考文獻
1 Barual Tuck..Deep Submicron Changes the Face of Verification[J].Computer Design， 1995(10):20
2 Musgrave G etal. User Experience with High Level Formal? Verification. In：ACM Proceedings of the35th Design Automation Conference.San Francisco:ACM，1998:327