參考：
https://www.xilinx.com/products/intellectual-property/aurora8b10b.html#documentation
https://docs.amd.com/r/en-US/pg046-aurora-8b10b
https://docs.amd.com/v/u/en-US/aurora_8b10b_ds797
https://mp.weixin.qq.com/s/gT4QUgvoFF6UI0PAhfEPvQ
補丁：
Aurora 系 IP內部都是不含COMMON（QPLL）的；
需要開發者自行例化然後接入，這是為了方便時鐘共享；
Aurora 8b/10b僅支援小於6.6G的線速率；
64b/66b則支援10.3125G
簡介
Aurora 8B/10B 核心（此圖）是一種可擴充套件的輕量級鏈路層協議，用於高速序列通訊。
該協議是開放的，可以使用 AMD FPGA 技術實現。
該協議通常用於需要簡單、低成本、高速率資料通道的應用，並用於使用一個或多個收發器在裝置之間傳輸資料。
Aurora 8B/10B 核心在連線到 Aurora 通道合作伙伴時會自動初始化通道，並以幀或資料流的形式在通道上自由傳輸資料。
Aurora 幀可以是任意大小，並且可以隨時中斷。
有效資料位元組之間的間隙會自動填充空閒位元組，以保持鎖定並防止過度的電磁干擾。
流量控制可用於降低傳入資料的速率或透過通道傳送簡短的高優先順序訊息。
流是單個、無休止的幀。在沒有資料的情況下，將傳輸空閒位元組以保持連結處於活動狀態。
Aurora 8B/10B 核心使用 8B/10B 編碼規則檢測單位錯誤和大多數多位錯誤。過多的位錯誤、斷開連線或裝置故障會導致核心重置並嘗試重新初始化新通道。
應用
Aurora 8B/10B 核心可用於各種應用，因為它們具有低資源成本、可擴充套件的吞吐量和靈活的資料介面。核心應用示例包括：
•晶片到晶片連結：用高速序列連線取代晶片之間的並行連線可以顯著減少 PCB 上所需的走線和層數。核心提供使用 GTP、GTX 和 GTH 收發器所需的邏輯，同時將 FPGA 資源成本降至最低。
•板到板和背板連結：核心使用標準 8B/10B 編碼，使其與許多現有的電纜和背板硬體標準相容。Aurora 8B/10B 核心可以進行擴充套件，包括線路速率和通道寬度，從而允許在新的高效能系統中使用廉價的傳統硬體。
•單工連線（單向）：Aurora 協議提供了執行單向通道初始化的替代方法，使得在沒有反向通道的情況下可以使用 GTP、GTX 和 GTH 收發器，並降低因未使用全雙工資源而產生的成本。
使用者資料和流控
https://mp.weixin.qq.com/s/gT4QUgvoFF6UI0PAhfEPvQ
其中使用者與IP之間可以傳輸兩種資料，一種是使用者的傳送或者接收的資料，稱為使用者PDU。另一種是用於控制傳送資料速率的指令（簡稱流控），稱為使用者流量控制（User Flow Control Messages）。
Aurora 8B/10B協議傳送資料的流程如下所示，需要經過Padding、組幀、8B/10B編碼、序列化等幾個過程。
Padding：因為Aurora 8B/10B通道傳輸的最小資訊單位是兩個位元組，因此首先需要檢測使用者待傳送資料位元組數為奇數還是偶數。
如果是奇數，則在使用者待傳送資料後面補充一個值為0x9C（K28.4）的K碼Pad資料。
組幀：就是在開始傳送資料前傳送2位元組的起始碼SCP（值分別為K28.2、K27.7），在幀尾傳送兩位元組停止位ECP（值分別為K29.7、K30.7）。
8B/10B編碼：
在傳輸之前，透過高速收發器的PCS中的8B/10B進行編碼，用於填充資料的Pad被編碼為控制字元，其餘被編碼為資料字元。
編碼後的資料被序列化，以差分不歸零（NRZ）格式傳輸。
Aurora 8B/10B協議接收資料的流程如下所示，包含串並轉換、8B/10B解碼、去除幀頭幀尾和空閒字元、去除Pad等幾個階段。
串並轉換：序列資料流以差分NRZ格式接收，將該資料反序列化為10位資料和控制符號。
8B/10B解碼：串並轉換後，鏈路層有效負載被解碼為八位位元組流。
在解碼過程中，必須把停止位ECP之前的填充字元Pad標記，便於後續去除。
去除鏈路層：把解碼後使用者資料流中的起始位SCP、停止位ECP、空閒字元去除。
空閒字元可能是透過流控操作傳送端插入的，
但空閒序列必須在偶數字節使用者資料之後開始插入，並且插入偶數個空閒字元。去
除Pad：最後去除填充的Pad字元0x9C（K28.4），之後把得到的資料傳輸給使用者。
Aurora 8B/10B協議除了常規的使用者資料收發，主要特點是支援可選的流量控制機制和多通道繫結機制。
可選的流量控制機制提供了低延遲流量控制，防止因為傳送速率和接收速率不同導致的資料丟失。
Aurora 8B/10B協議支援User Flow Control（UFC）和Native Flow Control（NFC）兩種流量控制機制，相關的流量控制方案如下圖所示，下文將對這兩種機制進行詳細講解。
使用者流量控制（UFC）
這個介面主要用於傳輸一些高優先順序的資料，將UFC資料插入到使用者待傳送資料（UPDU）中，優先傳輸，一般用來傳輸比較重要的控制資訊。下圖是UFC資料的流向圖，均是單向傳輸。
UFC開始傳輸後不能被時鐘補償序列、NFC或空閒序列中斷。
因為UFC會中斷使用者資料的傳送，因此Aurora 8B/10B協議實現可能需要將使用者待傳送資料暫存，防止資料丟失。
UFC的資料格式如下圖所示，長度為4到18個位元組，
第一個位元組是使用者流控制開始字元（SUF），是一個K碼，值為K28.4。
第二個位元組稱為命令位元組的資料字元，之後緊跟著傳送使用者需要傳輸的高優先順序資料，資料長度為2到16個位元組。
注意K28.4可以用於SUF和填充，區別在於填充字元後面只能跟一個控制字元，不能跟一個資料字元。
UFC訊息的長度為SIZE取值乘2加2，即SIZE*2+2。因為SIZE長度只有三位，因此UFC訊息大小可以是2到16之間的任意偶數字節。
本地流量控制（NFC）
本地流量控制（Native Flow Control，簡稱NFC）是一種鏈路層流量控制機制，由Aurora 8B/10B介面生成並解釋，而UFC是上層實現的機制。
NFC的機制其實比較簡單，如下圖所示，高速收發器A透過藍色走線向高速收發器B傳輸資料。
由於雙方的速率可能並不一致，導致高速收發器B的使用者接收FIFO快溢位了，此時高速收發器B會生成NFC訊息，然後透過傳送埠傳輸給高速收發器A的接收端。
高速收發器A解析NFC訊息之後，可能會暫停傳送使用者資料（藍線暫停），而是傳送空閒資料（黃線傳送），接收端接收空閒資料會直接丟棄，不會存入接收FIFO，透過上述機制來防止接收FIFO溢位。
注意NFC的優先順序低於UFC，這是因為傳送的UFC訊息也不會存入接收端的FIFO中，即UFC的傳輸對接收端的FIFO溢位沒有影響。
高速收發器A的傳送端透過在請求的時間間隔內暫停傳送使用者資料，來響應接收端的NFC控制。
這段時間除了可以傳送空閒序列之外，暫停還可以傳輸UFC和NFC資料，因為這些都沒有儲存在接收端的FIFO中。
傳送端暫停的時間與接收端透過NFC傳輸的資料有關，
NFC的資料格式如下圖所示，長度為兩位元組。
第一個位元組是本地流控制開始字元（SNF），第二個位元組是資料字元，稱為命令位元組。
命令位元組包含暫停欄位，該欄位指定傳送空閒字元的時鐘週期數，下表顯示了暫停欄位的編碼。
NFC暫停欄位編碼
|
PAUSE |
暫停間隔（符號） |
|
0000 |
0（XON） |
|
0001 |
2 |
|
0010 |
4 |
|
0011 |
8 |
|
0100 |
16 |
|
0101 |
32 |
|
0110 |
64 |
|
0111 |
128 |
|
1000 |
256 |
|
1001~1110 |
保留 |
|
1111 |
無限（XOFF） |
當傳送埠收到接收端的NFC資料時，如果Aurora 8B/10B介面正在傳送使用者資料，
傳送端可以透過完成模式或立即模式兩種方式之一響應NFC。
完成模式需要等待使用者這一幀資料傳送完成之後才執行暫停的時間，
而立即模式可以直接中斷使用者當前資料的傳送，直接暫停規定時間，一般採用立即模式；（存疑）
透過上面分析可知，NFC與使用者收發資料的關係不大，是在Aurora 8B/10B協議內部完成的。
可能有點影響的是暫停時間設定多大合適，要考慮接收端與傳送端傳輸的延遲，不能傳送端接收到NFC時，接收端的FIFO就已經溢位了。
埠
Aurora 8B/10B 核心的主要功能模組包括：
• 通道邏輯：每個 GTP、GTX 或 GTH 收發器（以下稱為收發器）由通道邏輯模組的一個例項驅動，該模組初始化每個單獨的收發器並處理控制字元的編碼和解碼以及錯誤檢測。
• 全域性邏輯：全域性邏輯模組執行通道初始化的繫結和驗證階段。在操作期間，該模組生成 Aurora 協議所需的隨機空閒字元並監控所有通道邏輯模組的錯誤。
• RX 使用者介面：AXI4-Stream RX 使用者介面將資料從通道移動到應用程式並執行流控制功能。
• TX 使用者介面：AXI4-Stream TX 使用者介面將資料從應用程式移動到通道並執行流控制 TX 功能。標準時鍾補償模組嵌入在核心內部。該模組控制時鐘補償 (CC) 字元的定期傳輸。
埠描述
用於生成每個 Aurora 8B/10B 核心的引數決定了該特定核心可用的介面。
介面在 IP 符號中可見，如圖所示。
在 IP 符號中，如果左鍵單擊介面旁邊的 + 號，則可以看到分組在其中的埠。
在本節（即埠描述）中，通常，介面顯示為單行條目，後跟分組在其中的埠。
例如，在表：使用者 I/O 埠 (TX) (TX) 中，USER_DATA_S_AXIS_TX 是介面，s_axi_tx_* 埠分組到該介面中。核心有四到六個介面。
使用者埠
Aurora 8B/10B 核心可採用幀或流式使用者資料介面生成。此介面包括流式或幀式資料傳輸所需的所有埠。
幀式使用者介面符合 AMBA® AXI4-Stream 協議規範 [參考文獻 4]，幷包含傳輸和接收幀式使用者資料所需的訊號。
流式介面允許在沒有幀分隔符的情況下傳送資料，操作更簡單，並且比幀式介面占用更少的資源。資料埠寬度取決於通道寬度和所選通道數。
頂層架構
Aurora 8B/10B頂層架構如下圖所示，包括收發器以及控制邏輯和使用者介面。
該IP提供給使用者兩種介面，即幀介面和流介面。
其中幀介面為axi4_Stream介面，而流介面只有資料和有效指示訊號，沒有掩碼訊號和最後位元組指示訊號。
本節提供流式傳輸和幀傳輸介面的詳細資訊。使用者介面邏輯的設計應符合此處所述的相應介面的時序要求。
AXI4-Stream Bit Ordering
Aurora 8B/10B 核心採用升序排序。它們首先傳輸和接收最高有效位元組的最高有效位。此圖顯示了 Aurora 8B/10B 核心的 AXI4-Stream 資料介面的 n 位元組示例的組織。
大端傳送；
幀介面（Framing Interface）
幀介面的相關訊號流向如下圖所示，與AXI4-Stream介面訊號基本一致，該介面可以傳輸任意位元組資料。
User Interface Ports
Table: User I/O Ports (TX) and Table: User I/O Ports (RX) list duplex and simplex core AXI4-Stream TX and RX data port descriptions.
注意下圖是Aurora 8B/10B協議的高速收發器傳輸資料的幀格式，
在前文講解Aurora 8B/10B協議時詳細講解過，注意SCP和ECP以位元組為單位。
因此接收使用者資料之後，可能會像之前自定義PHY那樣去對資料進行拼接，但是這些事情都是在Aurora 8B/10B IP內部完成的，使用者不需要關心，只需要瞭解即可。
戶傳送埠的時序如下圖所示，待傳送資料位寬為n位元組，傳送的資料量為3n位元組，需要三個時鐘傳輸。
s_axi_tx_tready拉高表示AXI4_Steram介面已準備好接收資料。
起始位/SCP/放置在通道的前兩個位元組上，以指示幀的開始，然後前n–2個使用者資料位元組放在通道上。
由於/SCP/需要偏移，每個使用者資料的最後兩個位元組總是延遲一個週期，並在下一時鐘的前兩個位元組傳送。
s_axi_tx_tlast拉高表示結束使用者資料傳輸，透過s_axi_tx_tkeep匯流排上的相應值，實現任意位元組的傳輸。
下圖中的s_axi_tx_tkeep設定為N，表示最後一個資料拍中的所有位元組都有效。
當s_axi_tx_tlast拉高時，s_axi_tx_tready在下一個時鐘週期拉低，
核心利用資料流中的間隙傳送最終偏移資料位元組和停止位/ECP/，指示幀結束。
s_axi_tx_tready在下一個週期重新拉高，以允許資料傳輸繼續進行。
Aurora 8B/10B每次傳輸的資料必須是偶數字節，如果使用者資料為奇數字節，則會在資料末尾新增一個Pad字元變為偶數字節。
如下圖所示，使用者最後一個資料寬度為n-1位元組，IP內部在組幀時，會在有效資料末尾新增一個Pad字元。（KEEP也要改變的）
使用者介面使用幀格式傳輸資料，支援暫停資料傳輸功能，如下圖所示。透過拉低s_axi_tx_tvalid併傳送空閒序列來暫停前n個位元組後的資料流，直到s_axi_tx_tvalid拉高為止。
從前文可知，時鐘補償的優先順序是最高的，所以資料傳輸可能會被時鐘補償序列打斷，對應時序圖如下所示。時鐘補償序列會在每10000位元組的通道上產生12位元組的開銷。
接收埠內部沒有用於儲存使用者資料的緩衝器，因此在接收埠訊號中沒有m_axi_rx_tready訊號。
m_axi_rx_tvalid訊號與Aurora 8B/10B核心各幀的第一個資料同時拉高，m_axi_rx_tlast與各幀的最後一個資料同時拉高，m_axi_rx_tkeep埠指示每幀最後一個資料中的有效位元組數，
m_axi_rx_tkeep訊號僅在m_axi_rx_tlast拉高時有效。接收資料的時序如下圖所示，m_axi_rx_tvalid為高電平時表示m_axi_rx_tdata對應資料有效，其餘時間無效。
手冊中還對該介面傳輸的效率做了計算，透過一個公式可以計算，也就是計算起始位、停止位、空閒資料、時鐘補償序列所帶來的開銷，
從而得到資料傳輸速率，最終通道越多，資料位寬越大、幀越長，效率越高。
使用者資料位寬採用8位元組、4通道傳輸一幀資料長度為1000，則效率可以達到99.14%。有興趣的可以檢視手冊，獲取具體計算方式。
流介面（Streaming Interface）
初始化後，除了傳送時鐘補償序列時，通道始終可用於寫入。
該介面特別簡單，但是輸入和輸出資料位寬必須與資料訊號位寬保持一致，不能傳輸任意位元組資料。
Aurora 8B/10B核心透過拉高s_axi_tx_tready來表示已準備好傳輸資料。
一個週期後，使用者邏輯拉高s_axi_tx_tvalid訊號並將資料置於s_axi_tx_tdata，開始傳輸資料，如下圖所示。
在下圖中，傳送資料D0和D1之後，Aurora 8B/10B核心拉低就緒訊號s_axi_tx_tready，直到下一個時鐘週期s_axi_tx_tready訊號再次拉高時才會傳輸資料D2。
然後，使用者邏輯在下一個時鐘週期拉低s_axi_tx_tvalid，在s_axi_tx_tvalid和s_axi_tx_tready都拉高之前不傳輸資料。
接收
流模式下不做對齊，因為沒用KEEP，建議使用幀模式。
流控埠
一些差別：
UFC：在UFC 握手期間提供報文，
握手拉低後在DATA通道提供UFC資料；
前文在Aurora 8B/10B協議中講解了兩種流量控制（UFC和NFC）的基本原理，
本節介紹xilinx的Aurora 8B/10B IP如何使用這兩種流量控制。
注意只有使用成幀介面的核心才有兩個可選的流量控制介面。
本地流量控制（NFC）控制全雙工通道接收端的資料傳輸速率，使用者流控制（UFC）為控制操作提供高優先順序訊息。
只有在配置IP時開啟UFC功能，後續生成的IP才會有相應的功能，IP配置介面如下所示，當選定幀格式傳輸資料時，可以單獨啟用UFC功能，也可以同時啟用UFC和NFC功能。
UFC對應的埠訊號如下圖所示，先看接收端的資料訊號，就是axi_stream介面，與接收資料埠一致，因為UFC資料也是透過使用者資料埠傳送的。
注意axi_ufc_tx_tdata並不是需要傳輸的UFC資料，而是UFC資料個數。
下圖是UFC傳輸資料格式，第一位元組是UFC傳輸的開始字元，SIZE表示其後面UFC字元長度，axi_ufc_tx_tdata的值就是SIZE對應數值，位寬也是一致的。
UFC訊息的長度為SIZE取值乘2加2，即SIZE*2+2。因為SIZE長度只有三位，因此UFC訊息大小可以是2到16之間的任意偶數字節。
UFC資料是透過s_axi_tx_tdata訊號傳輸的，s_axi_ufc_tx_tready拉高後的第一個時鐘開始。
當s_axi_tx_tdata埠用於UFC資料時，核心會解拉低s_axi_tx_tready。
手冊給出使用者傳送資料和UFC訊息的機制如下，當s_axi_tx_tready有效時傳送使用者資料，否則傳送UFC資料。
注意：只有在完成當前UFC請求後才能提出新的UFC請求且IP可能不支援背靠背UFC請求。
下圖顯示了傳輸單週期UFC訊息的程式，在這種情況下，4位元組的UFC訊息透過4位元組的傳送資料介面傳送。
注意：s_axi _tx_tready訊號在這兩個週期內無效，Aurora 8B/10B核心利用資料流中的這一間隙來傳輸UFC報頭和訊息資料。
如下圖所示，位寬為2位元組的使用者傳送資料介面傳輸4位元組的UFC訊息。
s_axi_tx_tready被拉低三個週期，
一個週期用於在s_axi_ufc_tx_tready週期內傳送的ufc報頭，
兩個週期用於UFC資料。
當Aurora 8B/10B核心收到UFC訊息時，透過專用的UFC AXI4-Stream介面將資料輸出給使用者。
接收的UFC訊息位於m_axi_ufc_rx_tdata埠，m_axi_ufc_rx_tvalid表示訊息資料的開始，m_axi_ufc_rx_tlast表示結束，m_axi_ufc_rx_tkeep用於顯示訊息最後一個週期內m_axi_ufc_rx_tdata上的有效位元組數。
下圖顯示了一個具有4位元組資料介面的Aurora 8B/10B核心接收4位元組UFC訊息。
m_axi_ufc_rx_tkeep設定為4‘hF，表示介面只有四個最高有效位元組有效。
圖22 接收單週期UFC訊息下圖顯示了一個具有4位元組介面的Aurora 8B/10B核心接收8位元組訊息，輸出資料幀有兩個週期長，
m_axi_ufc_rx_tkeep在第二個週期設為4‘hF，表示所有四個位元組的資料都有效。
NFC介面
Aurora 8B/10B協議包括本地流量控制（NFC）介面如下圖所示，通常用於防止接收端的FIFO溢位。
該介面允許接收器透過指定必須放入資料流的空閒資料個數來控制資料接收速率，
甚至可以透過請求傳送器暫時只傳送空閒訊號（XOFF）來完全關閉資料流。
NFC介面包括一個用於傳送nfc訊息的請求（s_axi_nfc_tx_tvalid）和一個確認（s_axi_nfc_tx_tready）埠，
以及一個用於指定所請求的空閒週期數的4位s_axi_nfc_tx_tdata埠。
圖24 Aurora 8B/10B核心NFC介面如果需要使用NFC介面，則在配置IP時需要勾選下圖的四個NFC選項之一，NFC有完成模式和立即模式兩種，前文也講述過兩者區別，一般使用立即模式比較好。
前文詳細講解過NFC實現的機制和原理，本質就是接收端FIFO快要溢位時，像傳送端傳輸一個NFC訊息，讓傳送端在指定週期內傳送空閒字元，停止傳送資料，
高速收發器A解析NFC訊息之後，可能會暫停傳送使用者資料（藍線暫停），而是傳送空閒資料（黃線傳送），接收端接收空閒資料會直接丟棄，不會存入接收FIFO，透過上述機制來防止接收FIF溢位。
NFC的優先順序低於UFC，這是因為傳送的UFC訊息也不會存入接收端的FIFO中，即UFC的傳輸對接收端的FIFO溢位沒有影響。
高速收發器A的傳送端透過在請求的時間間隔內暫停傳送使用者資料，來響應接收端的NFC控制。
這段時間除了可以傳送空閒序列之外，暫停還可以傳輸UFC和NFC資料，因為這些都沒有儲存在接收端的FIFO中。
傳送端暫停的時間與接收端透過NFC傳輸的資料有關，NFC的資料格式如下圖所示，長度為兩位元組。第一個位元組是本地流控制開始字元（SNF），第二個位元組是資料字元，稱為命令位元組。
如下圖所示，當資料埠s_axi_tx_tdata傳送NFC空閒字元時，s_axi_tx_tready為低電平，此時不能傳輸使用者資料。
NFC在握手期間傳遞報文，握手拉低後傳遞NFC資料，但NFC資料只有命令，或者說延遲的標識；
表1 NFC暫停欄位編碼
|
PAUSE |
暫停間隔（符號） |
|
0000 |
0（XON） |
|
0001 |
2 |
|
0010 |
4 |
|
0011 |
8 |
|
0100 |
16 |
|
0101 |
32 |
|
0110 |
64 |
|
0111 |
128 |
|
1000 |
256 |
|
1001~1110 |
保留 |
|
1111 |
無限（XOFF） |
下圖顯示收到NFC訊息時使用者傳送資料的埠時序。
在這種情況下，NFC資料為0001，請求傳送埠傳送兩個空閒資料拍。
IP拉低使用者介面的資料應答訊號s_axi_tx_tready，
直到傳送足夠的空閒資料來滿足請求。下圖中核心在即時NFC模式下執行，NFC空閒被立即插入。Aurora 8B/10B核心也可以在完成模式下執行，在完成模式下，NFC空閒僅插入幀之間。
由上述敘述可知，UFC是需要使用者去控制s_axi_tx_tdata來傳輸資料的，而NFC由於是傳送的空閒資料，因此用於其實不需要干預其資料訊號。
狀態和控制介面
Aurora 8B/10B核心的狀態和控制埠允許應用程式監控通道並使用收發器的內建功能。
本節提供了狀態和控制介面、收發器序列I/O介面以及專用於單工模組的初始化埠的圖表和埠描述。
如下圖所示，在配置IP時，需要選擇使用全雙工還是單工模式，預設使用全雙工模式傳輸資料。
下圖表示不同模式下，狀態訊號和控制訊號型別的區別。
下表列出了一些比較常用的控制訊號和狀態訊號，一些不常用的可以自行參考手冊，這裡列多了就沒有看下去的耐心了，所以列的都是重要的。
表2 狀態和控制埠
|
訊號 |
I/O |
含義 |
|
channel_up |
O |
Aurora 8B/10B通道初始化完成且通道準備好資料傳輸時置位。 |
|
lane_up[0:m–1] |
O |
每位代表一個通道，該通道初始化成功時對應位置位。 |
|
frame_err |
O |
檢測到通道幀或協議錯誤，將該訊號拉高一個時鐘。 |
|
hard_err |
O |
檢測到硬錯誤時拉高，直到Aurora 8B/10B核心復位。 |
|
soft_err |
O |
在傳入的序列流中檢測到軟錯誤時拉高。 |
|
Reset |
I |
復位Aurora 8B/10B核心，高電平有效，必須保持至少六個user_clk週期。 |
|
gt_reset |
I |
當模組首次上電時拉高，復位收發器的PCS和PMA。該訊號使用init_clk_in消抖，且必須拉高六個init_clk_in週期。 |
|
link_reset_out |
O |
熱插拔計數到期時變為高電平。 |
|
init_clk_in |
I |
當gt_reset有效時user_clk停止，建議init_clk_in的頻率低於GT參考時鐘輸入頻率。 |
1、軟體錯誤：在高速收發器的執行過程中，由於通道噪聲等因素的影響，資料傳輸可能會遇到錯誤。
8B/10B編碼技術能夠檢測出所有單位元資料錯誤以及大多數多位元資料錯誤。當檢測到這些錯誤時，會拉高軟錯誤（soft_err）訊號。
如果在短時間內檢測到大量軟錯誤，系統將執行復位操作。
2、硬體錯誤：Aurora 8B/10B可以監控每個收發器的硬體錯誤。硬體錯誤可能包括接收端或傳送端buffer溢位、傳送端和接收端時鐘源頻率差異超過100ppm等。
當檢測到過多的軟錯誤時，這可能觸發硬體錯誤，會拉高硬體錯誤（hard_err）訊號。
一旦檢測到硬體錯誤，Aurora 8B/10B IP會自動進行復位並嘗試重新初始化。
如果該問題得到解決，通道可以重新初始化，並建立新的連線。
3、幀錯誤：Aurora 8B/10B IP可以檢測axi_stream的幀錯誤，幀錯誤可能包括空幀、連續的幀開始符號或連續的幀結束符號。
檢測到幀錯誤後，拉高幀錯誤（frame_err）訊號。
Aurora 8B/10B在上電、復位或硬錯誤後自動初始化，直到通道準備就緒。
lane_up匯流排指示通道中的哪些通道已完成通道初始化程式。
只有在核心完成整個初始化程式後，channel_up才會置位。
在channel_up有效之前，Aurora 8B/10B核心無法接收資料。
Aurora 8B/10B IP包含reset和gt_reset兩個復位訊號，前者用於復位除高速收發器以外的邏輯功能，後者用於復位高速收發器，本文以全雙工模式講解復位。
Aurora 8B/10B核心的復位至少拉高六個user_clk時間週期，channel_up會在三個user_clk週期後拉低，如下圖所示。
圖30 雙工核心中的復位拉高下圖顯示了復位高速收發器的時序，gt_reset至少拉高六個init_clk_in時間週期。
由於user_clk是由txoutclk生成的，當高速收發器復位時，txoutclk會停止產生，因此經過幾個時鐘之後user_clk也會停止產生，之後channel_up拉低。
圖31 雙工核心中的gt_reset拉高兩個復位訊號的上電時序應該如下所示，開始均處於高電平，當首先拉低gt_reset，當高速收發器復位完成，穩定產生user_clk之後，reset才拉低，然後對邏輯部分完成復位。
當核心工作過程中，如果要進入復位狀態，應該遵循以下時序。首先應該拉高reset，讓核心邏輯進入復位，之後拉高gt_reset，防止停止產生user_clk後核心邏輯卡死。
注意該IP的使用者資料的大端模式可以更改為小端模式，更改方式如下圖所示，在配置IP時勾選“Little Endian Support”即可。
延遲時間
透過Aurora 8B/10B核心的延遲是由透過協議引擎（PE，FPGA可程式設計邏輯實現）和收發器的管道延遲引起的。
PE流水線延遲隨著AXI4流介面寬度的增加而增加，收發器延遲取決於所選收發器的特性和屬性。
注意：這些延遲不包括因Aurora 8B/10B通道兩端之間的序列連線長度（PCB走線等）而產生的延遲。下圖顯示了預設配置下資料路徑的延遲，延遲可能因設計中使用的收發器和IP配置而異。
Aurora 8B/10B核心吞吐量取決於收發器數量和目標線路速率。
使用20%的Aurora 8B/10B協議編碼開銷和0.5 Gb/s至6.6 Gb/s的線路速率範圍計算單通道設計和16通道設計的吞吐量，得到吞吐量範圍[0.4,84.48]Gb/s。
本文的重點在於前兩部分，使用者需要著重瞭解使用者介面以及流控原理和實現方式，才能夠正常使用該IP。
透過本文的分析可知，該IP就是對GTX收發器的上層封裝、內部完成組幀和接收端位元組對齊、流控、時鐘補償、CRC校驗等等功能。
相比自定義PHY，該IP更加簡單，增加流控功能後接收端接收資料會更加準確，防止資料溢位，
缺點在於使用者不能操作GTX，GTX的傳送通道和接收通道必須使用buffer同步資料，不能使用相位對齊電路，導致資料延遲會比較大。如果設計對延時比較敏感，可能該IP將不再適用。