一、 緒 綸
3.6 實體編碼子層中的狀態機…
實體編碼子層中有四個狀態機，分別為同步鎖定狀態機、位元錯誤率監測狀 態機、接收資料狀態機與傳送資料狀態機。這四個狀態機分布於上述硬體之中，
底下四個圖為IEEE 802.3ae 標準中所制定的狀態機功能圖。
LOCK_INIT blk_lock <= false test_sh <= false
UCT
RST_CNT sh_cnt <= 0 sh_invalid_cnt <= 0 slip_done <= false
test_sh
TEST_SH
VALID_SH
test_sh &
sh_cnt < 64 sh_cnt = 64 &
sh_invalid_cnt = 0 64_GOOD blk_lock <= true sh_cnt ++
sh_valid
sh_cnt = 64 &
sh_invalid_cnt > 0 sh_cnt =64 &
sh_invalid_cnt < 16
& blk_;ock test_sh <= false
!sh_valid
test_sh & sh_cnt < 64 &
sh_invalid_cnt < 16 &
blk_lock INVALID_SH
SLIP
sh_invalid_cnt = 16
| !blk_lock
blk_lock <= false SLIP
slip_done UCT
sh_cnt ++
sh_invalid_cnt ++
reset |
!signal_ok
圖3–9 同步資料鎖定狀態機
BER_MT_INIT hi_ber <= false ber_test_sh <= false
UCT
START_TIMER ber_cnt <= 0 start 125us_timer
ber_test_sh
BER_TEST_SH
BER_BAD_SH
ber_test_sh &
ber_cmt < 16 &
125us_timer_not_done
HI_BER hi_ber <= true ber_cnt ++
!sh_valid
ber_cnt < 16 &
125us_timer_done ber_test_sh <= false
sh_valid &
125us_timer_done
GOOD_BER hi_ber <= false
UCT reset |
!blk_lock
ber_cnt = 16
125us_timer_done
圖3–10 位元錯誤率監測狀態機
TX_INIT tx_code <= LBLOCK_T
T_TYPE = S T_TYPE = (E + D + T) T_TYPE = C
T_TYPE = C
TX_C
tx_coded <= ENCODE
T_TYPE = (E + D +T) C
T_TYPE = D
TX_D tx_coded <= ENCODE
T_TYPE = (E + C + S) D
TX_E
tx_coded <= EBLOCK_T T_TYPE = T
T_TYPE = T
TX_T tx_coded <= ENCODE
T_TYPE = (E + D + T)
RX_INIT rx_raw <= LBLOCK_R
R_TYPE = S R_TYPE = (E + D + T) R_TYPE = C
R_TYPE = C
RX_C rx_raw <= DECODE
R_TYPE = (E + D +T) C
R_TYPE = D
RX_D rx_raw <= DECODE
R_TYPE = (E + C + S) &
(R_TYPE_NEXT = (E + D + T) | R_TYPE = T)
D
RX_E
rx_raw <= EBLOCK_R R_TYPE = T &
R_TYPE_NEXT = (S + C) R_TYPE = T &
R_TYPE = (S + C)
RX_T rx_raw <= DECODE
(R_TYPE = (E + D + T) &
| !blk_lock
圖3–12 接收資料狀態機
第四章 硬體模擬與驗證
設計完成的硬體需要透過模擬與驗證來確定其功能的正確性。在電路設計的 過程中，主要是利用 Cadence 的 NC-Verilog 軟體來模擬電路動作，在透過 SprinSoft 的 Debussy 軟體來觀察模擬結果的波形圖。由於此電路是採用 Top to Bottom 的設計方式，所以在整合完整電路之前，每一個子硬體模組的驗證都必 須要正確無誤。針對每一個子硬體模組都有其測試向量，這些測試向量在最後硬 體整合模擬驗證也必需通過。
硬體整合完成之後要做整體資料傳輸與接收的模擬驗證，由於在此階段需要 大量的測試向量來做驗證，如果用手工方式一一撰寫測試向量不僅耗時並且也可 能發生不必要的錯誤，所以在本研究之中採用自動測試向量產生器與自動測試向 量檢查器的方法來幫硬體驗證的進行[10]。自動測試向量產生器也是由 Verilog 語言所寫成，在此產生器中我們設定一些拘束條件，讓它所產生的測試向量必須 符合資料傳輸接收的格式。有了自動測試向量產生器就可以依據不同的傳輸模式 來產生所需要的測試向量，除此之外大量產生的隨機測試向量也能提高測試的覆 蓋率，使硬體驗證更加完整。當測試向量越來越多，我們已經無法用人工方式逐 一檢查波形圖，所以利用測試向量檢查器可以輕易的找出發生錯誤的測試向量。
當自動測試向量產生器產生測試向量，它會將向量送至硬體另外也會傳送至測試 向量檢查器中，當檢查器接收到待測硬體的測試向量時便會開始比對，如果發生 錯誤測試向量檢查器便會將錯誤訊息紀錄下來，只要根據最後的錯誤訊息我們就 能輕易的找錯誤發生的地方。
在完成所有測試向量之後，我們利用 Cadence 的程式碼覆蓋率分析(Code Coverage Analysis)軟體來確認測試向量的覆蓋率足不足夠。利用程式碼覆蓋率分 析我們可以更確保測試向量的完整度與硬體程式的正確性。
為了完成硬體在電腦上的模擬驗證，所以必須加入一些功能模組來幫助硬體
了模擬驗證。圖4–1 為實體編碼子層功能驗證架構圖︰
1:4 解多工器Sync Header 偵測器 SLIP FunctionBER 監測器
De-Scrambler資料整合 器Async FIFO64B/66B 解碼器
4:1 多工器GearboxScrambler資料整合 器Async FIFO64B/66B 編碼器 時脈訊 號管理 器
時脈訊 號管理 器 32-bit data 4 control
66-bit64-bit 2-bit sync header
64-bit66-bit64-bit16-bit
txref_clk tx_clk 16-bit64-bit control signal rxref_clkrx_clk
66-bit64-bit 66-bit66-bit
32-bit data 4 control
clk_156
Loo pback
2-bit Sync header
XGMII 功能模組 自動測試向量 產生器
測試向量檢查器 實體媒介接觸子層 功能模組
圖4–1 實體編碼子層功能驗證架構圖
實體編碼子層驗證除了增加自動測試向量產生器與測試向量檢查器之外，還 有XGMII 功能模組與實體媒介接觸子層功能模組。模擬驗證的環境架構好之後 可以開始進行硬體的模擬驗證。實體編碼子層的硬模擬體驗證主要分為底下幾個 部分：
1. 純控制字元的傳送接收。
2. 控制字元與資料的傳送接收。
3. 包含錯誤資料的傳送接收。
4. 鏈結錯誤處理。
5. 其它的驗證。
6. 完整資料傳輸接收。
分為六個不同的部分來做硬體模擬驗證是為了單純化錯誤發生的狀態。底下章節 會針對每一個硬體驗證部分來說明。
4.1 純控制字元的傳送接收
這個階段的硬體驗證只針對控制字元的傳輸與接收。根據表 3–1 所示，可 以歸納出此階段硬體驗證的測試向量主要有三種，第一種為包含起始控制字元
（Start）的測試向量，第二種為包含終止控制字元（Terminite）的測試向量，第 三種為不包含起始控制字元與終止控制字元的測試向量。
由於起始控制字元只能在 lan 0 上被傳送與接收，所以在硬體驗證部分必須 確定起始控制字元只會正確的存在於lan 0 上，若是發生在 lan 1 到 lan 3 上，則 硬體必須產生錯誤的訊息，並且傳送至XGMII 做處理。起始控制字元一定要接 在其他控制字元之後被傳輸與接收，除了終止控制字元之外。正確的測試向量編 碼圖如圖4–2 所示，任何不符合圖 4–2 的編碼方式，硬體都必須產生錯誤的訊息 告知上層的系統。
0x1e C0 C1 C2 C3 C4 C5 C6 C7
1 0
. . . .
1 0 0x78 D1 D2 D3 D4 D5 D6 D7圖4–2 包含起始控制字元編碼示意圖
終止控制字元代表傳輸的資料已經結束，所以終止控制字元必定緊接在資料 之後發生。在終止控制字元之後是連續的閒置控制字元（Idle），在硬體閒置狀 態之下產生任何的資料傳輸都會有錯誤的訊息產生。圖4–3 為包含終止控制字元 之編碼圖︰
D0 D1 D2 D3 D4 D5 D6 D7
0 1 . . . 1 0 0x87 C1 C2 C3 C4 C5 C6 C7 圖4–3 包含終止控制字元編碼示意圖
終止控制字元可以發生在lan 0 到 lan 3 任何一條線路上，所以終止控制字元可 能會發生再資料區塊中的任意位置上，在做硬體驗證時所有會發生終止控制字元 的位置上都必須測試。
不包含起始控制字元與終止控制字元的測試向量只是單純的傳送與接收閒 置控制字元。傳送閒置控制字元發生在資料傳輸起始之前、資料傳輸完成之後等 待下一筆傳送資料之間的空閒時間；或是發生錯誤訊息後等待系統修正的時間，
如鏈結錯誤發生之時。圖4–4 為不包含起始與終止控制字元之編碼示意圖︰
0x1e C0 C1 C2 C3 C4 C5 C6 C7
1 0 . . . .
圖4–4 不包含起始與終止控制字元編碼示意圖
4.2 控制字元與資料的傳送接收
這部分的硬體驗證重點主要是放在起始控制字元與終止控制字元產生的狀 況。由前一小節所知，起始控制字元只能存在於lan 0 之中，因此起始控制字元 只能在資料區塊的第一個位元組位置，其後跟隨著的位元組為純資料格式，所以 在純資料傳輸之中除了終止控制字元與錯誤控制字元之外，其他的控制字元當將 被視為純資料格式。
終止控制字元只會發生在資料傳輸結束之時，因此它跟隨在純資料之後，在 其它控制狀態之下產生的終止控制字元都為不合法的傳輸。終止控制字元之後緊 接著是閒置控制字元，在進行下一筆資料傳輸之前，系統必須不斷的傳送閒置控 制字元，直到資料開始傳輸。由於資料傳輸是以66 位元為一個區塊，起始的兩 個位元為同步標頭位元，不像起始控制字元只能發生於區資料區塊的第一個位元 組，終止控制字元可以發生在區塊中的任何一個位元組的位置，硬體必須能夠偵 測終止控制字元所發生的位置。
在起始控制字元與終止控制字員之間為純資料傳輸格式，在純資料傳輸之中 除了錯誤控制字元之外，其它的控制字元都將不被承認。圖4–5 為控制字元與資 料的編碼示意圖︰
0x1e C0 C1 C2 C3 C4 C5 C6 C7
1 0 . . . 1 0 0x78 D1 D2 D3 D4 D5 D6 D7
D0 D1 D2 D3 D4 D5 D6 D7
0 1 . . . 1 0 0x87 C1 C2 C3 C4 C5 C6 C7
圖4–5 控制字元與資料編碼示意圖
4.3 包含錯誤資料的傳送與接收
錯誤的資料傳輸主要分為傳送資料的錯誤與接收資料的錯誤兩個部分。傳送 與接收資料發生錯誤的狀況不盡相同，在下面小節之中會做進一步的解釋。
4.3.1 傳送端錯誤測試
硬體傳送端發生的錯誤主要是因為XGMII 端傳送錯的資料訊息。XGMII 傳 送過來的錯誤資料主要分為兩種，第一種為XGMII 在傳送的資料與控制訊號中 已將錯誤的狀況顯示出來。例如在傳輸資料的過程中，XGMII 傳送過來的控制 訊號 TXC 被設定為 1，而傳送的資料顯示為錯誤控制字元，實體編碼子層不需 要做任處理，只需要將錯誤的訊息傳送出去。第二種傳送端發生的錯誤是為 XGMII 傳送給實體編碼子層的資料並沒有顯示出錯誤的訊息，但是實體編碼子 層接收到XGMII 的資料格式卻是錯誤，這時候實體編碼子層要將接收到的錯誤 資料轉換為合法的錯誤資料格式。
上述二種傳送端所發生的錯誤可以細分為以下五種狀況：
1. 傳輸初始階段錯誤
傳輸初始階段意謂硬體剛完成傳輸鏈結的動作，這時候系統已經準 備好做資料傳輸。實體編碼子層便會開始接收 XGMII 傳送過來的資 料，如果此時的資料為錯誤控制字元、終止控制字元或是純資料，則 資料傳輸發生錯誤，實體編碼子層也會進入錯誤資料處理狀態。
2. 傳輸控制字元發生錯誤
當系統進入傳輸控制字元的階段，如果這時候從 XGMII 傳送過來 的資料為錯誤控制字元、終止控制字元或是純資料，則同樣也會發生
傳輸的錯誤。
3. 純資料傳輸發生錯誤
在純資料傳輸階段，如果此時實體編碼子層從 XGMII 接收到的資 料為起始控制字元、錯誤控制字元或是控制字元（不包含終止控制字
在純資料傳輸階段，如果此時實體編碼子層從 XGMII 接收到的資 料為起始控制字元、錯誤控制字元或是控制字元（不包含終止控制字