電子發燒友App
1 數據鏈路層
數據鏈路層包括發送和接收兩個部分，本章主要介紹數據流從進入到發射器的數據鏈路層到從接收器的數據鏈路層出來的所經過的具體處理過程以及涉及到的模塊。
下面的圖21和圖22分別是發送數據鏈路層和接收數據鏈路層的內部結構圖，本章節將從發送鏈路層開始介紹每一個具體模塊的功能，同時由于接收鏈路層中包含的模塊總是發送的模塊的功能是相對的，所以在介紹發送鏈路層中的模塊時，將同時介紹接收部分模塊的功能。
進入鏈路層的數據是在傳輸層映射為數據幀的，進入數據鏈路層的數據以幀為最小單元，而數據鏈路層工作在charcter clock時鐘域，所以在進入數據鏈路層后，farme data 將先經過Frame_to_octet模塊，Frame_to_octet模塊將輸入的數據幀轉換成octet的數據流。
數據流在Scrambler模塊將進行加擾處，加擾的功能是可選擇的。
經過加擾處理的數據流經過alignment_character_generator模塊將進行字節替換，字節替換的目的是為了檢測數據通道數據流是否工作正常。
Mux模塊通過TX_controller模塊選擇需要數據的數據流
數據流在8b/10bcoder模塊中將進行編碼操作，并最終輸出到serdes_tx模塊。
TX_contrller 為數據鏈路層的控制模塊，該模塊通過control interface與上層接口交互控制信息，并對控制信息進行解析，進而控制數據鏈路層的工作流程。
Initial_lane_alignment_sequcence_generator是不同數據通道間的同步序列的生成模塊，該模塊將在系統啟動同步后，產生所需要的同步序列。
?
圖21：數據鏈路層發送器的內部結構圖
在接收器部分，數據鏈路層的數據流的具體操作如下：
物理層的serdes模塊將輸入的1bit的串行數據流轉換為10bit并行數據流，并通過特殊的對齊字節完成數據流的對齊，并將對齊完后的數據通過8b/10b進行解碼，并出輸出8bit位寬的octet數據流。
解碼輸出的數據流將通過lane_alignment_buffering_detection_monitoring模塊，該模塊將通過對校準字符在數據幀中的位置，來判斷現階段的數據傳輸不同通道間是否同步。
接下來數據流經過Frame_alignment_detection_monitoring模塊，該模塊也是通過對校準字符在數據幀中的檢測來數據幀是否發生對齊的錯誤。
在經過兩級的對齊檢測后，數據將進入descrambler模塊進行數據的解擾。
解擾后的數據流將通過octet_to_frame模塊從新組合成數據幀，傳輸到數據傳輸層。
圖22：數據鏈路層接收射器的內部結構圖
以上便是系統中數據鏈路層對數據流的控制和處理流程，SystemC的模型中，上述的每一個模塊將有相對應的模型，并且SystemC中模塊的名字將與上述圖中的模塊名稱保持一致。
1.1 RX Controller
Rxcontroller作為數據鏈路成的控制核心，其內部需要完成的工作主要為兩個方面，一方面通過數據接口與上層進行控制數據交換，一方面完成數據鏈路層的工作狀態控制，本章將系統的介紹數據鏈路層的工作狀態控制。
在Rx controller內需要完成的工作包括：code group synchronization、initial frame synchronization，這兩部分表現為兩個狀態機的控制，完成數據流的同步和數據幀的同步。
1.1.1 code group synchronization
code group synchronization的功能在系統上電或者要求系統從新同步時完成數據流的同步，該同步的具體的過程是在serdes的CDR模塊中實現的，完成1bit數據流到10bit的串行轉換。具體的同步細節如下：
在同步要求開始后，接收控制器發送同步請求，此時SYNC信號將保持低電平，發射器在接收到同步請求后，將會發送comma碼：/K/=/K28.5/
接收控制器在接收以下的情況下降釋放同步請求：
Subclass 0 devcies：在接收到4個有效的K碼后，在任何數據幀的邊界釋放同步請求。
Subclass 1和Subclass 2：在接收到4個有效的k碼后，在數據的復幀(mutliframe)的邊界釋放同步請求，也就是將SYNC信號拉高。
在接收到另外4個有效的comma碼后，系統將認為數據code group synchronization完成。
當接收到一個無效的數據時，狀態機將進入檢測模式。
如果在檢測模式中，累積收到3個無效數據時，認為系統未同步。
在檢測模式中，如果檢測到4個正確數據后會認為系統同步正常。
同步請求由接收器通過SYNC信號傳輸到發送器，并且SYNC低電平有效，SYNC信號只有在frame clock 的上升沿才會發送變化，但是也分兩種情況:
Subclass 0:任何frame clock的上升沿
Subclass 1和Subclass 2：任何frame clock 和multiframe clock對齊的上升沿。
SYNC信號的低電平持續時間必須大于5個數據幀或者9個octet的持續時間。
Code groupsynchronization 同步的狀態機轉換圖如圖23所示，變量的具體意義在表1中有詳細的描述。
圖23：Code groupsynchronization state machine
?
Variable
?
Meaning
?
Icounter
?
Counter used in the CS_CHECK phase to count the number of invalid symbols
?
INVALID
?
Asserted by receiver to indicate that the current symbol is an invalid symbol given the current running disparity.
?
K_received
?
Asserted when the current symbol corresponds to control character K28.5
?
Kcounter
?
Counter used in the CS_INIT phase to count the number of valid K28.5 symbols
?
sync_request
?
Asserted by receiver when loss of code group synchronization has been detected. Note that sync_request does not drive SYNC~ directly, as SYNC~ assertion/de-assertion is based on more than just the sync_request signal described here.
?
VALID
?
Asserted by receiver to indicate that the current symbol is a valid symbol given the current running disparity.
?
Vcounter
?
Counter used in the CS_CHECK phase to count the number of successive valid symbols
?
code groupsynchronization只需要在SYNC有效時進行，而在數據的正常傳輸時，兩個相鄰字節中的某1bit出現錯誤，也將有可能出現comma碼，而此時的comma碼將不能用來作為同步的檢測的標準。
1.1.2 Initial frame synchronization
Initial framesynchronization 的狀態機如圖24所示，該系統復位時，狀態機將進入initial state，octet counter 將會被清零，而的code group synchronization 將在系統復位后生成同步請求，在這種情況下，framesynchronization 將一直處于initialstate。
圖23：frame synchronizationstate machine
Frame synchronization的狀態機將在code group synchronization完成后，并且發送器停止發送K碼后進入FS_DATA狀態，在該狀態下，octet counter將會進行計算，以標記當前的octet在frame中的位置，octet counter的計數范圍是：0 到F-1.如果有同步請求狀態機將直接回到FS_INIT狀態，但是如果有各個接受器的情況下，其他接受器發送SYNC請求時，當前接收器并不知道有同步請求的情況下，狀態機只能通過檢測連續的K28.5來判斷狀態機是否跳轉。
如果K28.5被檢測到，狀態機將進入FS_CHECK狀態，在FS_CHECK狀態中，octet counter將繼續計數，如果有4個K28.5被檢測到，狀態機將直接跳轉到initial 狀態。
?
Variable
?
Meaning
?
any_sync_request
?
A sync request asserted by any receiver connected to the link.
?
CHECK_ALIGNMENT
?
Perform frame alignment monitoring, see subclause 7.3
?
F
?
Number of octets per frame
?
Kcounter
?
Counter used in the FS_CHECK phase to count the number of K28.5 symbols
?
K_received
?
Asserted when the current symbol corresponds to control character K28.5 (valid or invalid)
?
Ocounter
?
Counter used to mark the position of the current octet in the frame.
?
sync_request
?
Asserted by receiver when loss of code group synchronization has been detected or if another error requires re-initialization.
?
1.2 Tx controller
Tx controller主要功能與Rx controller是保持一致的，其內部需要完成狀態如下圖所示：
具體的流程如下：
在系統復位后，狀態機進入SYNC狀態，在該狀態下發送器將持續的發送K28.5的comma碼，在SYNC信號被釋放后的第一個數據幀到來時，狀態機將跳轉到INIT_LANE狀態。
在LINIT_LANE狀態下，狀態機將通過控制信號控制Initial lanealignment sequence generator模塊開始生產lane同步的序列，并控制MUX模塊輸出Initial lane alignment sequence。
在Initial lane alignment sequence發送完畢后，狀態機將進入正常的數據發送狀況，并在系統要求同步時進入SYNC狀態。
?
Variable
?
Meaning
?
7C_octet
?
Asserted when the scrambler outputs a 0x7C (28.3) octet
?
alignment_sent
?
Used to indicate a /K28.3/ or /K28.7/ has been sent in the previous frame.
?
FC_octet
?
Asserted when the scrambler outputs a 0xFC (28.7) octet
?
frame_end
?
Asserted by transmitter to indicate end of frame.
?
(multi)frame_start
?
Asserted by transmitter to indicate start of frame for devices belonging to the NMCDA-SL device class, or start of multiframe for devices belonging to other device classes. (See clause 9).
?
lane_seq_end
?
Asserted by transmitter to indicate end of initial lane alignment sequence
?
multiframe_end
?
Asserted by transmitter to indicate end of multiframe. Only to be asserted if both sides of the lane support lane synchronization.
?
NewOvalue
?
Value of last octet in current frame
?
OldOvalue
?
Used for storage of last octet in frame
?
SEND_A
?
Send /K28.3/ symbol
?
SEND_DATA
?
Send code group belonging to current data octet
?
SEND_F
?
Send /K28.7/ symbol
?
SEND_K
?
Send /K28.5/ symbol
?
SEND_LANE_SEQ
?
Send initial lane alignment sequence
?
sync_request_tx
?
asserted when transmitter detects a synchronization request
1.3 Initial frame synchronization
在系統數據鏈路建立起來時，數據幀的同步將通過以下方式實現：
在code group synchronization期間，發送器將一直發送標志符comma碼K28.5。
在code group synchronization結束后，在接收器接收到第一個不是K28.5的字符開始，認為是數據幀的開始，如果發送器發送的是initial lanealignment sequence，那么K28.5后面緊跟的將是K28.0。
在第一個K28.0以后，接收器認為每F個octet為一個數據幀。
1.3.1 Frame alignment monitoring andcorrection
1.3.1.1 Alignment charaters
數據幀的對齊通過對齊標志符comma碼來完成，這些comma將在特定的情況下插入到數據流中，接收器將在確定接收到的comma有效時，將以comma在數據幀的位置為標志，從新的同步接收器中的數據幀，在一般的情況下，系統認為多次在數據幀的某一個位置檢測到comma，才會認為該comma是有效的，并且以此作為依據來從新同步接收器中的數據幀。
對齊數據幀的標準符是comma碼/F/=/K28.5/,但是如果發送和接收器都支持通道間的通道，那么comma碼/A/=/28.3/也將會出現在復幀的結束，他也可以作為數據幀同步的標志符。
根據數據是否進行加擾處理，對于對齊標志符的處理將分為兩種情況。
1.3.1.2 Character replacement withoutscrambling
在接收器和發送器都支持通道同步的情況下，對齊標志符的在發送器內的替換和在接收器中的還原需要遵循如下的操作:
當前數字幀的最后一個octet，當前復幀的最后一個octe除外，等于上一次數據幀的最后一個octet，那么當前數據幀的最后的octet將用/F/=/K28.7/來代替，但是如果上數據幀已經發生了對齊標志符，本次數據幀將不進行替換。
當前數據幀的最后一個octet，并且是復幀的最后一個octet，等于上一次數據幀的最后一個octet，那么當前數據幀的最后的octet將用/A/=/K28.3/來代替，即使上一次數據幀已經發生了對齊標志符，本次數據幀也會進行替代
在接收器中，在接收到對齊標志符/F/或者/A/時，接收器需要用上一數據幀中位置相同的數據進行替代。
如果接收和發送器中，有某一個器件不支持通道同步，對齊標志符的替換將遵循如下的原則:
當前數字幀的最后一個octet，當前復幀的最后一個octe除外，等于上一次數據幀的最后一個octet，那么當前數據幀的最后的octet將用/F/=/K28.7/來代替，但是如果上數據幀已經發生了對齊標志符，本次數據幀將不進行替換。
在接收器中，在接收到對齊標志符/F/時，接收器需要用上一數據幀中位置相同的數據進行替代。
1.3.1.3 Character replacement withscrambling
在接收器和發送器都支持通道同步的情況下，對齊標志符的在發送器內的替換和在接收器中的還原需要遵循如下的操作:
當前數字幀的最后一個octet，當前復幀的最后一個octe除外，等于0xFC時，那么當前數據幀的最后的octet將用/F/=/K28.7/來代替。
當前數據幀的最后一個octet，并且是復幀的最后一個octet，等于0x7C時，那么當前數據幀的最后的octet將用/F/=/K28.3/來代替。
在接收器中，在接收到對齊標志符/F/或者/A/時，接收器需要用0xFC或者0x7C替代。
如果接收和發送器中，有某一個器件不支持通道同步，對齊標志符的替換將遵循如下的原則:
當前數字幀的最后一個octet，當前復幀的最后一個octe除外，等于0xFC時，那么當前數據幀的最后的octet將用/F/=/K28.7/來代替。
在接收器中，在接收到對齊標志符/F/時，接收器需要用0xFC替代。
1.3.1.4 Frame alignment character generator
對齊標志符的檢測與校準的處理過程如圖24所示，具體的變量信息解釋如表4所示，當數據流中沒有提供足夠的機會產生數據對齊標志符時，數據幀的對齊的校準的功能可以通過控制接口屏蔽。
圖24：Frame alignmentcharacter generator
?
Variable
?
Meaning
?
7C_octet
?
Asserted when the scrambler outputs a 0x7C (28.3) octet
?
alignment_sent
?
Used to indicate a /K28.3/ or /K28.7/ has been sent in the previous frame.
?
FC_octet
?
Asserted when the scrambler outputs a 0xFC (28.7) octet
?
frame_end
?
Asserted by transmitter to indicate end of frame.
?
(multi)frame_start
?
Asserted by transmitter to indicate start of frame for devices belonging to the NMCDA-SL device class, or start of multiframe for devices belonging to other device classes. (See clause 9).
?
lane_seq_end
?
Asserted by transmitter to indicate end of initial lane alignment sequence
?
multiframe_end
?
Asserted by transmitter to indicate end of multiframe. Only to be asserted if both sides of the lane support lane synchronization.
?
NewOvalue
?
Value of last octet in current frame
?
OldOvalue
?
Used for storage of last octet in frame
?
SEND_A
?
Send /K28.3/ symbol
?
SEND_DATA
?
Send code group belonging to current data octet
?
SEND_F
?
Send /K28.7/ symbol
?
SEND_K
?
Send /K28.5/ symbol
?
SEND_LANE_SEQ
?
Send initial lane alignment sequence
?
sync_request_tx
?
asserted when transmitter detects a synchronization request
?
1.3.1.5 Frame alignment monitoring andcorrection
對齊標志符的檢測與校準的處理過程如圖25所示，具體的變量信息解釋如表5所示，當數據流中沒有提供足夠的機會產生數據對齊標志符時，數據幀的對齊的校準的功能可以通過控制接口屏蔽。
圖25：Frame alignmentmonitoring and correction
?
Variable
?
Meaning
?
A_received
?
Asserted when the current symbol, before possible substitution in lane alignment monitoring, corresponds to control character K28.3 Note: detection of K28.3 is not required in NMCDA-SL DACs.
?
CROSS_COUPLING
?
Frame misalignment expected because of cross coupling between lane and frame alignment
?
F
?
Number of octets per frame
?
F_received
?
Asserted when the current symbol corresponds to control character K28.7
?
Ocounter
?
Counter used to mark the position of the current octet in the frame. Octet indexing starts from 0.
?
previous_AF_position
?
Variable into which to store the position in the frame of a K28.3 or K28.7 symbol
?
REPLACE_ALIGNMENT_CHARACTER
?
Replace the alignment character at the decoder output by:
? The data character decoded or used at the same position in the previous frame when scrambling is disabled
? The data character with the same value when scrambling is enabled
?
Mark the possition of a K28.3 character if needed in subsequent lane synchronization or lane alignment monitoring.
?
RESET_OCTET_COUNTER
?
Reset octet counter to zero at reception of next octet
?
VALID
?
Asserted by receiver to indicate that the current symbol is a valid symbol given the current running disparity.
?
1.4 Initial lane synchronization
在正常數據的發送與接收前，需要對系統進行通道間的同步，以保證不同通道數據在接收輸出是同步的，在一個合適的時間點上，所以的發送器將同時發送字節對齊標志位/A/=/28.3，但是由于不同通道間的延時不同，會導致接收器接收到標志字符的時間是不同的。所以當接收器接收到標志字符/A/時，每一個接收器都將從A以后的序列存儲起來，并通過ready標準位通知其他通道，該通道已經接收到有效的對齊字符，當系統中的所有通道都已經接收到有效的對齊字符時，系統將在一個同一時間點將緩存的數據進行釋放，這樣便保證了系統中所有通道數據的同步輸出。
支持JESD204B的器件是可以讓發送與接收之間保持固定延遲的，對于系統中的某一個接收器件沒有接收到有效的對齊字符而其他器件正常接收時，JESD204B定義了具體的出錯處理機制。
不同通道間的同步是通過通道同步序列(initial lane alignment sequence)來完成的，通道同步的序列將在code group synchronization完成后立即發送，initial lane alignment sequence是不經過加擾的，對于ADC器件來說initiallane alignment sequence的長度固定為4個multiframe，對于DAC器件來說，在Subclass 1和Subclass 2中，initial lane alignment sequence的要求長度也是4個multiframe，所以，對于FPGA來說，initial lane alignment sequence的長度必須可以編程，長度范圍是4-256，其中multiframe的長度是K個frame，K的取值范圍為：1-32,而multiframe中octet的個數范圍為：17-1024。
對于JESD204B的發送器來說，K的值必須是可編程的，而JESD204B的接收器中，K的值是建議可編程，JESD204的接收器必須明確定義對于K值的處理是是要求還是建議，而在本次的建模中，K值都是可編程的。
initial lanealignment sequence的結構如圖26所示，每復幀開始標志位為/R/=/28.0/，結束標準位為/A/=/28.3/，R標志著initial lane alignment sequence的開始，A標志著initiallane alignment sequence每一復幀的結束。標志位A表示每一復幀的結束并不僅僅用于initial lane alignment sequence，在正常的數據發送中也會用到，在initial lane alignment sequence的第二個復幀中，包含了系統配置的參數，從復幀的第三個字節開始，K28.4作為第二個標志字符，標志著配置字節的開始。
圖26：initial lane alignmentsequence的結構
?
圖27：initiallane alignment sequence生成的流程圖內容
initial lane alignment sequence的生成流程圖如上圖所示，數據復幀的第一個字節為0x1c/28.0/,結束字節為/28.3/,在第二復幀的第二個字節為0x9c/28.4/，配置字符是從第二復幀的第3字節開始。
1.4.2 Link configuration data andencoding
下表為系統中配置參數的具體解釋和參考圖。
?
Parameter
?
Description
?
Parameter Range
?
Field
?
Encoding
?
ADJCNT
?
Number of adjustment resolution steps to adjust DAC LMFC.
Applies to Subclass 2 operation only.
?
0 … 15
?
ADJCNT<3:0>
?
Binary value
?
ADJDIR
?
Direction to adjust DAC LMFC 0 – Advance 1 – Delay
Applies to Subclass 2 operation only
?
0 … 1
?
ADJDIR<0>
?
Binary value
?
BID
?
Bank ID – Extension to DID
?
0 ... 15
?
BID<3:0>
?
Binary value
?
CF
?
No. of control words per frame clock period per link
?
0 ... 32
?
CF<4:0>
?
Binary value*
?
CS
?
No. of control bits per sample
?
0 ... 3
?
CS<1:0>
?
Binary value
?
DID
?
Device (= link) identification no.
?
0 ... 255
?
DID<7:0>
?
Binary value
?
F
?
No. of octets per frame
?
1 ... 256
?
F<7:0>
?
Binary value minus 1
?
HD
?
High Density format
?
0 ... 1
?
HD<0>
?
Binary value
?
JESDV
?
JESD204 version 000 – JESD204A 001 – JESD204B
?
0 … 7
?
JESDV<2:0>
?
Binary Value
?
K
?
No. of frames per multiframe
?
1 ... 32
?
K<4:0>
?
Binary value minus 1
?
L
?
No. of lanes per converter device (link)
?
1 ... 32
?
L<4:0>
?
Binary value minus 1
?
LID
?
Lane identification no. (within link)
?
0 ... 31
?
LID<4:0>
?
Binary value
?
M
?
No. of converters per device
?
1 ... 256
?
M<7:0>
?
Binary value minus 1
?
N
?
Converter resolution
?
1 ... 32
?
N<4:0>
?
Binary value minus 1
?
N’
?
Total no. of bits per sample
?
1 ... 32
?
N'<4:0>
?
Binary value minus 1
?
PHADJ
?
Phase adjustment request to DAC Subclass 2 only.
?
0 … 1
?
PHADJ<0>
?
Binary value
?
S
?
No. of samples per converter per frame cycle
?
1 ... 32
?
S<4:0>
?
Binary value minus 1
?
SCR
?
Scrambling enabled
?
0 ... 1
?
SCR<0>
?
Binary value
?
SUBCLASSV
?
Device Subclass Version 000 – Subclass 0 001 – Subclass 1 010 – Subclass 2
?
0 … 7
?
SUBCLASSV
<2:0>
?
Binary Value
?
RES1
?
Reserved field 1
?
0 ... 255
?
RES1<7:0>
?
Binary value
?
RES2
?
Reserved field 2
?
0 ... 255
?
RES2<7:0>
?
Binary value
?
CHKSUM
?
Checksum Σ(all above fields)mod 256
?
0 ... 255
?
FCHK<7:0>
?
Binary value
?
*?CF==L?shall always be encoded as 31: control words on all lanes.?CF==31 can only occur when?L==31, see 5.1.3.
?
Configuration octet no.
?
Bits
?
MSB
?
6
?
5
?
4
?
3
?
2
?
1
?
LSB
?
0
?
DID<7:0>
?
1
?
ADJCNT<3:0>
?
BID<3:0>
?
2
?
X
?
ADJDIR<0>
?
PHADJ<0>
?
LID<4:0>
?
3
?
SCR<0>
?
X
?
X
?
L<4:0>
?
4
?
F<7:0>
?
5
?
X
?
X
?
X
?
K<4:0>
?
6
?
M<7:0>
?
7
?
CS<1:0>
?
X
?
N<4:0>
?
8
?
SUBCLASSV<2:0>
?
N’<4:0>
?
9
?
JESDV<2:0>
?
S<4:0>
?
10
?
HD<0>
?
X
?
X
?
CF<4:0>
?
11
?
RES1<7:0> - Set to all X
?
12
?
RES2<7:0> - Set to all X
?
13
?
FCHK<7:0>
?
1.4.3 Lane alignment buffering /detection and monitoring
在開始數據幀和通道對齊后，通道將會進入對齊字節檢測狀態，通道的對齊是通過對齊標志符/A/=/28.3/來決定的，該對齊標志符在復幀的結尾，對于對齊標識符A的插入，可以參考frame alignmentmonitoring。
在一般的情況下，不是所有的通道都會發生同時發生對齊標識符A，但是通道可以通過A在復幀中的位置來檢測數據通道的數據是否同步上。
在多個接收通道的情況下，每一個接收器都應該可以從更高層的應用中授權數據鏈路層對鏈路中的數據進行從新的動態調整，已完成不同數據通道間的對齊。
?數據通道中發現未對齊
?發現新的對齊字符，但是不在數據復幀的幀尾
?根據對齊字符緩存區中的數據進行從新對齊
?如果連續接在同一個位置上接收到兩個有效的A，并且不在數據復幀的結束，并且在兩個A之間沒有接收到有效或者無效A標識符，通道需要從新的將通道中的數據進行對齊。
?如果在最近的數據幀出現通道間不對齊的可能性很大時，接收器需要將第一個接收到A的位置作為對齊的標準。
1.4.4 Lane alignment detection andmonitoring
通道間的數據檢測和對齊處理過程如圖27所示，圖中變量的具體意思參照表8，具體的操作流程如下:
?
Variable
?
Meaning
?
A_received
?
Asserted when the current symbol, before possible substitution in frame alignment monitoring, corresponds to control character K28.3
?
CROSS_COUPLING
?
Lane misalignment expected because of cross coupling between frame and lane alignment
?
Fcounter
?
Counter used to mark the position of the current frame in the multiframe. Frame indexing starts from 0.
?
K
?
Number of frames in multiframe.
?
previous_A_position
?
Variable into which to store the position in the multiframe of a K28.3 symbol
?
REPLACE_A
?
Replace the K28.3 at the decoder output by:
? The data character decoded or used at the same position in the previous frame when scrambling is disabled
? D28.3 when scrambling is enabled
?
However, if the position of the K28.3 is required in subsequent frame alignment monitoring, the K28.3 shall not be replaced or it shall be marked.
?
RESET_FRAME_COUNTER
?
Reset frame counter to zero at reception of next frame
?
INITIATE_SYNC_CHECK
?
In receivers belonging to a MCDA device class (see clause 9), if authorized via the control interface, initiate a synchronization check between the LMFCs via one of the methods supported by the device class and subclass.
?
VALID
?
Asserted by receiver to indicate that the current symbol is a valid symbol given the current running disparity.
?
1.5 Scrambler and Descrambler
加擾編碼和解擾編碼存在JESD204 TX和RX的模塊中，并可以通過控制字使能是否對數據流進行加擾。
加擾模塊都是針對單獨的數據通道，不會出現不同數據通道的數據混合加擾的情況，也就是說每一個數據通道有自己獨立的加擾通道。
加擾編碼模塊的功能是為了增加數據流中的高頻分量，減小數據流中連續0和1的個數。如果出現長時間的連續“1”或連續“0”，會影響接收端從數字信號中提取時鐘。
圖28： Functional location of scrambler and descrambler
1.5.1 加擾公式
1+x[14]+x[15]
該公式的作用周期可以長達32767bit，非常適合對頻譜敏感的收發應用，而解擾器只需要2個字節緩存就能解擾。
1.5.2 加擾的流程
加擾器解擾器都是通過數據流串行輸入實現的，最小的處理單位為幀，加擾與解擾的順序是由高位到低位。具體的流程如下圖所示：
圖29：Serial scrambling
1.5.3 加擾的方式
加擾的實現方式可以分為兩種，串行加擾和并行加擾，串行加擾的時鐘域為發送接口的串行時鐘速率，雖然串行的加擾方式實現簡單，但是工作的頻率很高，RTL的實現難度要大于并行加擾模式，因此設計中采用并行加擾模式。
串行加擾和并行加擾的流程圖如下圖所示：
圖30：Serial scrambler anddescrambler implementation
scrambler模塊加入了使能信號，其結構如下圖所示，當en信號無效時，scrambler模塊將會被bypass，同時在code group synchronization sequence和transmission of an initial lane alignment sequence發送時，scrambler也是bypass的。在使能scrambler后，scrambler和descramber模塊將會有兩個octet的數據延遲。
1.6 8b/10 Encoder andDecoder/monitoring
8b/10b編碼的原理是將一組連續的8位數據分解成兩組數據，一組3位，一組5位，經過編碼后分別成為一組4位的代碼和一組6位的代碼，從而組成一組10位的數據發送出去。相反，解碼是將一組10位的輸入數據經過變換得到8位數據位。數據值可以統一的表示為DX．Y或KX．Y，其中D表示為數據代碼，K表示為特殊的命令代碼。X表示輸入的原始數據的低5位EDCBA，Y表示輸入的原始數據的高3位HGF。因此8b／10b編碼邏輯可分解為兩個子邏輯塊，一個5b／6b編碼器(EDCBA<—>iedcba)和一個3b／4b編碼器(HGF<—>jhgf)。編碼原理圖如下圖所示。
圖30：8b/10 Encoder and Decoder
在8b/10b編碼過程中，會出現字符不一致的情況，即一組字符中“1”和“0”的個數不一致的情況，這種情況稱作差異度。當字符中的“0”比“1”多時，稱作負極性；“1”比“0”多時，稱作正極性；“0”和“1”相等時，為零極性。編碼規則規定，非零極性的編碼結果（包括4位結果，6位結果和組合的10位結果）的極性必須依次翻轉[1]。比如，如果6位編碼結果具有正的極性，則接下來的4位結果應該具有負的極性，如果接下來的4位結果具有零極性，則繼續要求4位結果后面6位結果具有負的極性，以此類推。
1.6.1 K_encode模塊設計
控制字在 8b/10b 編碼中只有 12 組，可以整體查表的方法實現：
表10：8b/10b 編碼K碼
1.6.2 D_encode 模塊設計
數據字編碼共有 256 組，通常將其劃分為 3b/4b 編碼和 5b/6b 編碼分別進行編碼，5b/6b 和 3b/4b 編碼表如表 4-2 和 4-3 所示。編碼結果欄目下，編碼結果為中性的只有 1 列，編碼結果極性不平衡的，分成了兩列，左邊一列的編碼結果具有正極性，右邊一列的編碼結果具有負極性。
表11：8b/10b 編碼D碼表
編碼表中有兩點需要注意：
1、表 4-2 中的 D.7 和表 4-3 中 D.x.3 的編碼結果，其編碼結果中“1”與“0”的個數相等，它本身是零極性的，但是其編碼結果卻有兩種可能；
2、表 4-3 中輸入為 D.x.7 的編碼結果可能四種：1110、0001、0111 和 1000，
做出這樣規定的目的是為了消除編碼結果 eifgh 出現 5 個連續“1”或者“0”的情況。
表12：8b/10b 編碼D碼表
1.6.3 Comma 檢測原理
SerDes 接口在發送端將字節信息經過編碼和串并轉換后，經過信道傳輸到接收機上，接收機對收到的串行碼流進行重定時，并把它們重新恢復成并行的字節數據。Comma 信號就是用來指示字節邊界，獲取和驗證字節同步（ByteSynchronization）的。為了有效達到這個目的，Comma 信號必須具有以下兩個特性：它必須是獨一無二的，2、相對于字節邊界，它能產生一個統一的對齊。在不考慮錯誤的情況下，Comma 信息不能出現在其他 bit 位上，既不能出現在其他字符中，也不能出現在兩個字符之間。符合這兩個條件的0011111 和 0011111 被選作是 Comma 信號，包含有 Comma 信號的 K.28.1（001111 1001 或 110000 0110），K.28.5（001111 1010 或 110000 0101），K.28.7（001111 1000 或 110000 0111）被稱為 Comma 字符。如果碼流中出現兩個或者 3 個交疊的 Comma 信號，只有第一個和第三個 Comma 信息會被檢測出來。比如出現兩個 K.28.7，碼流00111110000011111000 中會出現三個 Comma 信號：0011111，1100000 和 0011111，這樣只有第一個和第三個 Comma 會被認為是合法的，這符合碼流中實際上只有兩個 K.28.7 的情況。雖然 K.28.7 不容易出現錯碼（其他碼要錯兩位才可能變為K.28.7），但是它的跳變密度比較低，不利于時鐘數據恢復。所以在實際應用中，一般只使用 K.28.1、K.28.5 作為 Comma 字符，而不使用 K.28.7。
Comma 檢測就是檢測串行碼流中的 Comma 信息，然后把字節邊界調整到Comma 信號之前，實現字節邊界的對準，為 8b/10b 解碼器提供正確的并行輸入信號，其功能如圖31所示。
圖31：comma檢測器
1.7 數據鏈路層的SystemC仿真
發送器數據鏈路層的仿真包括數據進入數據鏈路層后先進行scrambler、然后通過同步字替換模塊、再通過8b/10b編碼輸出，輸出的并行數據進入到物理層的SerDes模塊，最終輸出1bit位寬的數據流。
接收器通過物理層的SerDes模塊將輸入的1bit數據流數據轉為10bit并行的數據，CDR模塊將對數據進行恢復，并通過comma碼K28.5對輸入的數據完成邊界的對齊，數據經過8b/10b解碼模塊后，最終輸出到數據通道同步檢測模塊和幀同步檢測模塊，通道同步檢測模塊完成不同數據通道間數據的同步與檢測，而幀同步檢測模塊完成數據幀幀頭的識別，同步后的數據將通過descramber模塊完成數據的解擾工作，并最終將數據輸出到數據傳輸層，以下是SystemC的仿真圖：
上圖中，模擬了AD9250的兩個AD轉換通道，一個通道采樣的為數據三角波，一個通道采樣的正弦波，而下面的是接收器接收到的數據，該數據的前半段的毛刺是由于系統同步而導致的。
工商網監
評論