JESD204B IP Core Design Example User Guide

Download PDF
ID 683094
Date 11/06/2017
Public

A newer version of this document is available. Customers should click here to go to the newest version.

Document Table of Contents
Document Table of Contents x
1. JESD204B IP Core Design Example User Guide
1. JESD204B IP Core Design Example User Guide x
1.1. JESD204B Design Example Quick Start Guide 1.2. Supported Configurations 1.3. Generic Design Example 1.4. Presets 1.5. Selecting and Generating the Design Example 1.6. Design Example with RTL State Machine Control Unit 1.7. Design Example with Nios II Processor Control Unit 1.8. JESD204B IP Core Design Example Document Archives 1.9. JESD204B IP Core Design Example User Guide Document Revision History
1.1. JESD204B Design Example Quick Start Guide x
1.1.1. Directory Structure 1.1.2. Generating the Design 1.1.3. Compiling and Simulating the Design 1.1.4. Compiling and Testing the Design
1.1.2. Generating the Design x
1.1.2.1. Procedure 1.1.2.2. Design Example Parameters
1.1.3. Compiling and Simulating the Design x
1.1.3.1. Procedure
1.6. Design Example with RTL State Machine Control Unit x
1.6.1. Design Example Components 1.6.2. System Parameters 1.6.3. System Interface Signals 1.6.4. Example Feature: Dynamic Reconfiguration 1.6.5. Generating and Simulating the Design Example 1.6.6. Generating the Design Example For Compilation 1.6.7. Compiling the JESD204B IP Core Design Example
1.6.1. Design Example Components x
1.6.1.1. PLL 1.6.1.2. PLL Reconfiguration 1.6.1.3. Transceiver Reconfiguration Controller 1.6.1.4. Transceiver Reset Controller 1.6.1.5. Pattern Generator 1.6.1.6. Pattern Checker 1.6.1.7. Transport Layer 1.6.1.8. Serial Port Interface (SPI) 1.6.1.9. Control Unit
1.6.1.5. Pattern Generator x
1.6.1.5.1. Parallel PRBS Generator 1.6.1.5.2. Alternate Checkerboard Generator 1.6.1.5.3. Ramp Wave Generator
1.6.1.6. Pattern Checker x
1.6.1.6.1. Parallel PRBS Checker 1.6.1.6.2. Alternate Checkerboard Checker 1.6.1.6.3. Ramp Wave Checker
1.6.1.7. Transport Layer x
1.6.1.7.1. Supported System Configuration 1.6.1.7.2. Data Bit and Content Mapping Scheme 1.6.1.7.3. TX Path 1.6.1.7.4. RX Path
1.6.1.9. Control Unit x
1.6.1.9.1. Memory Block (ROM) 1.6.1.9.2. Finite State Machine (FSM)
1.6.2. System Parameters x
1.6.2.1. Run-Time Reconfiguration
1.6.4. Example Feature: Dynamic Reconfiguration x
1.6.4.1. Dynamic Reconfiguration Operation 1.6.4.2. MIF ROM
1.6.5. Generating and Simulating the Design Example x
1.6.5.1. Generating the Design Example Simulation Model 1.6.5.2. Simulating the JESD204B IP Core Design Example
1.7. Design Example with Nios II Processor Control Unit x
1.7.1. Design Example Components 1.7.2. System Clocking 1.7.3. Nios II Processor Design Example Files 1.7.4. Nios II Processor Design Example System Parameters 1.7.5. Nios II Processor Design Example System Interface Signals 1.7.6. Compiling the Design Example for Synthesis 1.7.7. Implementing the Design on the Development Kit 1.7.8. Running the Software Control Flow 1.7.9. Customizing the Design Example
1.7.1. Design Example Components x
1.7.1.1. Qsys System Component 1.7.1.2. Transport Layer 1.7.1.3. Test Pattern Generator 1.7.1.4. Test Pattern Checker
1.7.1.1. Qsys System Component x
1.7.1.1.1. JESD204B Subsystem in Qsys 1.7.1.1.2. Nios II Subsystem in Qsys 1.7.1.1.3. Core PLL 1.7.1.1.4. PLL Reconfiguration Controller 1.7.1.1.5. SPI Master
1.7.7. Implementing the Design on the Development Kit x
1.7.7.1. Pin Assignments 1.7.7.2. Hardware Setup 1.7.7.3. Programming the Device
1.7.8. Running the Software Control Flow x
1.7.8.1. Executing the Software C Code 1.7.8.2. Software Parameters 1.7.8.3. Software Interrupt Service Routines (ISR) 1.7.8.4. Software Functions Description
1.7.8.4. Software Functions Description x
1.7.8.4.1. Functions in main.c Source File 1.7.8.4.2. Custom Peripheral Access Macros in macros.c Source File
1.7.9. Customizing the Design Example x
1.7.9.1. Modifying the JESD204B IP Core Parameters Post-Generation 1.7.9.2. Changing the Data Rate or Reference Clock Frequency 1.7.9.3. Implementing a Multi-Link Design
1.7.9.3. Implementing a Multi-Link Design x
1.7.9.3.1. Editing the Qsys Project 1.7.9.3.2. Editing the Top Level HDL File 1.7.9.3.3. Editing the Software C Code
1. JESD204B IP Core Design Example User Guide

1.6.1.7.4. RX Path

The deassembler in the RX path consists of the tail bits dropping, deassembling, and multiplexing blocks.
Figure 12. RX Path Assembler Block Diagram


  • Tail bit dropping block—drops padded tail bits in the incoming data (jesd204_rx_link_datain).
  • Deassembling block—rearranges the resulting data bits in a specific way according to the mapping scheme (refer to figure).
  • Multiplexing block—sends the multiplexed data to the Avalon-ST interface, determined by certain control signals from the RX control block.
Table 23.  Deassembler Parameter Settings
Parameter Description Value
L Number of lanes per converter device. 1–8
F Number of octets per frame. 1, 2, 4, 8
CS Number of control bits per conversion sample. 0–3
N Number of conversion bits per converter. 12-16
N' Number of transmitted bits per sample in the user data format. 16
F1_FRAMECLK_DIV Only applies to cases where F=1.

The divider ratio on the frame_clk. The deassembler always uses the post-divided frame_clk (rxframe_clk). 13

1, 4
F2_FRAMECLK_DIV Only applies to cases where F=2.

The divider ratio on the frame_clk. The deassembler always uses the post-divided frame_clk (rxframe_clk). 13

1, 2
RECONFIG_EN Enable reconfiguration support in the transport layer. Only downscaling reconfiguration is supported. Disable the reconfiguration to reduce the logic. 0, 1
OUTPUT_BUS_WIDTH The data output bus width size that depends on the F and L.

bus_width = M*S*N

F = (M*S*N_PRIME)/(8*L)

M*S = (8*F*L)/N_PRIME

Therefore the output bus width = (8*F*L*N)/N_PRIME

(8*F*L*N)/N_PRIME
CONTROL_BUS_WIDTH The control output bus width size. The width depends on the CS parameter as well as the M and S parameters. When CS is 0, the control data is one bit wide (tie the signal to 0).

If CS = 0, the bus width = 1. Otherwise, the bus width = (OUTPUT_BUS_WIDTH/N*CS) while OUTPUT_BUS_WIDTH/N = M*S

OUTPUT_BUS_WIDTH/N*CS
Table 24.  Deassembler Signals

Signal

Clock Domain

Direction

Description

Control Unit
rxlink_clk

—

Input

RX link clock signal. This clock is equal to the RX data rate divided by 40. This clock is synchronous to the rxframe_clk signal.
rxframe_clk

—

Input

RX frame clock used by the deassembler. The frequency is a function of parameters F, F1_FRAMECLK_DIV, F2_FRAMECLK_DIV and rxlink_clk.

This clock is synchronous to the rxlink_clk signal.

rxlink_rst_n rxlink_clk

Input

Reset for the RX link clock domain logic in the deassembler. This reset is an active low signal and the deassertion is synchronous to the rising-edge of rxlink_clk.
rxframe_rst_n rxframe_clk

Input

Reset for the RX frame clock domain logic in the deassembler. This reset is an active low signal and the deassertion is synchronous to the rising-edge of rxframe_clk.

Signal

Clock Domain

Direction

Description

Between Avalon- ST and Transport Layer
jesd204_rx_ dataout[(OUTPUT_BUS_WIDTH)-1:0] rxframe_clk

Output

RX data to the Avalon-ST source interface. The transport layer arranges the data in a specific order, as illustrated in the cases listed in RX Path Data Remapping section.
jesd204_rx_controlout[CONTROL_BUS_WIDTH -1:0] rxframe_clk Output RX control data to the Avalon-ST source interface. The transport layer arranges the data in a specific order, as illustrated in the cases listed in RX Path Data Remapping section.
jesd204_rx_data_valid rxframe_clk

Output

Indicates whether the data from the transport layer to the Avalon-ST sink interface is valid or invalid.
  • 0—data is invalid
  • 1—data is valid
jesd204_rx_data_ready

rxframe_clk

Input

Indicates that the Avalon-ST sink interface is ready to accept data from the transport layer.
  • 0—Avalon-ST sink interface is not ready to receive data
  • 1—Avalon-ST sink interface is ready to receive data

Signal

Clock Domain

Direction

Description

Between Transport Layer and DLL
jesd204_rx_link_datain[(L*32)-1:0]

rxlink_clk

Input

Indicates received data from the DLL to the transport layer, where four octets are packed into a 32-bit data width per lane. The data format is big endian. The table below illustrates the data mapping for L = 4:
jesd204_rx_link_datain [x:y] Lane
[31:0] 0
[63:32] 1
[95:64] 2
[127:96] 3

Connect this signal to the RX DLL jesd204_rx_link_data[] output pin.

jesd204_rx_link_data_valid

rxlink_clk

Input

Indicates whether the jesd204_rx_link_datain[] is valid or invalid.
  • 0—jesd204_rx_link_datain[] is invalid
  • 1—jesd204_rx_link_datain[] is valid

Connect this signal to the RX DLL jesd204_rx_link_valid output pin.

jesd204_rx_link_data_ready

rxframe_clk

Output

Indicates that the transport layer is ready to sample jesd204_rx_link_datain[].
  • 0—transport layer is not ready to sample jesd204_rx_link_datain[]
  • 1—transport layer starts sampling jesd204_rx_link_datain[] at the next clock cycle.

Connect this signal to the RX DLL jesd204_rx_link_ready input pin.

jesd204_rx_link_error

rxlink_clk

Output

Indicates an empty data stream due to invalid data. This signal is asserted high to indicate an error at the Avalon-ST sink interface (for example, when jesd204_rx_data_valid = "1" while jesd204_rx_data_ready = "0"). The DLL subsequently reports this error to the CSR block.

Connect this signal to the RX DLL jesd204_rx_frame_error input pin.

Signal

Clock Domain

Direction

Description

CSR in DLL
csr_l[4:0] 14 mgmt_clk

Input

Indicates the number of active lanes for the link. This 5-bit bus represents the L value in zero-based binary format. For example, if L = 1, the csr_l[4:0] = "00000". This design example supports the following values:
  • 00000
  • 00001
  • 00011
  • 00111
Any programmed value beyond the supported range may result in undeterminable behavior in the transport layer. You must ensure that the csr_l[4:0] value always match the system parameter L value.

Runtime reconfiguration supports L fallback. For static configuration, set the maximum L and reconfigure csr_l[] to a smaller value during runtime. This transport layer only supports higher index channels to be powered down. To interleave the de-commision channels, you need to modify the interface connection from the DLL to transport layer.

Connect this signal to the RX DLLcsr_l[] output pin.

csr_f[7:0] 14 mgmt_clk

Input

Indicates the number of octets per frame. This 8-bit bus represents the F value in zero-based binary format. For example, if F = 2, the csr_f[7:0] = "00000001". This design example supports the following values:
  • 00000000
  • 00000001
  • 00000011
  • 00000111
Any programmed value beyond the supported range may result in undeterminable behavior in the transport layer. You must ensure that the csr_f[7:0] value always match the system parameter F value.

Connect this signal to the RX DLL csr_f[] output pin.

csr_n[4:0] 14 mgmt_clk

Input

Indicates the converter resolution. This 5-bit bus represents the N value in zero-based binary format. For example, if N = 16, the csr_n[4:0] = "01111". This design example supports the following values:
  • 01011
  • 01100
  • 01101
  • 01110
  • 01111
Any programmed value beyond the supported range may result in undeterminable behavior in the transport layer. You must ensure that the csr_n[4:0] value always match the system parameter N value.

Connect this signal to the RX DLL csr_n[] output pin.

RX Path Operation

The data transfer protocol between the Avalon-ST interface and the RX path transport layer is data transfer without backpressure. Therefore, the sink shall always be ready to sample the incoming data whenever data at the source is valid.

Figure 13. RX Operation BehaviorThis figure shows the data transmission for a system configuration of LMF = 112, N = 12, N' = 16, S =1.

Operation:

  • Upon the deassertion of the rxframe_rst_n signal, the jesd204_rx_link_data_ready signal from the deassembler to the DLL is asserted at the next rxframe_clk.
  • Subsequently, the DLL asserts the jesd204_rx_link_data_valid signal for the deassembler to activate the f2_div1_cnt signal logic and to start sampling the jesd204_rx_link_datain[31:0] signal. 15
  • At the following rxframe_clk, the jesd204_rx_data_valid is asserted along with the multiplexed jesd204_rx_dataout[11:0] signal to stream data to the Avalon-ST interface.
  • Finally, the DLL deasserts the jesd204_rx_link_data_valid signal when there is no more valid data.
  • The deassembler deactivates the f2_div1_cnt signal logic accordingly, and deasserts the jesd204_rx_data_valid at the next rxframe_clk.


RX Data Reception

This section explains when there is a valid RX data out from the DLL to the TL to with scrambler enabled.

The MAC layer process the jesd204_rx_dataout signal once the TL asserts the jesd204_rx_data_valid signal. However, there are some data that should be discarded by the upper layer when the you enable the scrambler. This is because the initial unknown seed value within the scrambler can corrupt the very first eight octets, which is the data for the first two link clock cycles. The data can be translated to the frame clock cycle depending on the F and FRAMECLK_DIV parameters selected based on the frame clock to link clock relationship.

Figure 15. RX Data Reception


RX Path Data Remapping

The JESD204B IP core implements the data transfer in big endian format.

The RX path data remapping is the reverse of TX path data remapping. Refer to unresolvable-reference.html#bhc1411117018854__fig_gkk_5rc_4rfor the RX transport layer remapping operation.

The following tables show examples of data mapping for L=4, F=1, 2, 4, 8 and M*S=2, 4, 8, 16. The configurations that the transport layer support are not limited to these examples.

Table 25.  Data Mapping for F=1, L=4
F = 1
Lane L3 L2 L1 L0
Data In {F12, F13, F14, F15} {F8, F9, F10, F11} {F4, F5, F6, F7} {F0, F1, F2, F3}
Supported M and S M*S=2 for F=1, L=4

F=1 supports either (case1: M=1, S=2) or (case2: M=2, S=1)

Assuming N=16, M0S0=jesd204_rx_dataout[15:0], M0S1/M1S0= jesd204_rx_dataout[31:16]

F1_FRAMCLK_DIV=1 1st frameclk

cnt=0 :

jesd204_rx_dataout[31:0] = {F8F12, F0F4}

Case1: M=1, S=2 M0S0=F0F4, M0S1=F8F12
Case2: M=2, S=1 M0S0=F0F4, M1S0=F8F12
2nd frameclk

cnt=1:

jesd204_rx_dataout[31:0] = {F9F13, F1F5}

Case1: M=1, S=2 M0S0=F1F5, M0S1=F9F13
Case2: M=2, S=1 M0S0=F1F5, M1S0=F9F13
3rd frameclk

cnt=2:

jesd204_rx_dataout[31:0] = {F10F114, F2F6}

Case1: M=1, S=2 M0S0=F2F6, M0S1=F10F14
Case2: M=2, S=1 M0S0=F2F6, M1S0=F10F14
4th frameclk

cnt=3:

jesd204_rx_dataout[31:0] = {F11F15, F3F7}

Case1: M=1, S=2 M0S0=F3F7, M0S1=F11F15
Case2: M=2, S=1 M0S0=F3F7, M1S0=F11F15
F1_FRAMCLK_DIV=4

jesd204_rx_dataout[127:0] = {{F11F15, F3F7},{F10F114, F2F6},{F9F13, F1F5},{F8F12, F0F4}}

Table 26.  Data Mapping for F=2, L=4
F = 2
Lane L3 L2 L1 L0
Data In {F12, F13, F14, F15} {F8, F9, F10, F11} {F4, F5, F6, F7} {F0, F1, F2, F3}
Supported M and S M*S=4 for F=2, L=4

F=2 supports either (case1: M=1, S=4), (case2: M=2, S=2) or (case3: M=4, S=1)

F2_FRAMCLK_DIV=1 1st frameclk

cnt=0:

jesd204_rx_dataout[63:0] = {F12F13, F8F9,F4F5, F0F1}

Case1: M=1, S=4 M0S0=F0F1, M0S1=F4F5, M0S2=F8F9, M0S3=F12F13
Case2: M=2, S=2 M0S0=F0F1, M0S1=F4F5, M1S0=F8F9, M1S1=F12F13
Case3: M=4, S=1 M0S0=F0F1, M1S0=F4F5, M2S0=F8F9, M3S0=F12F13
2nd frameclk

cnt=1:

jesd204_rx_dataout[63:0] = {F14F15, F10F11,F6F7, F2F3}

Case1: M=1, S=4 M0S0=F2F3, M0S1=F6F7, M0S2=F10F11, M0S3=F14F15
Case2: M=2, S=2 M0S0=F2F3, M0S1=F6F7, M1S0=F10F11, M1S1=F14F15
Case3: M=4, S=1 M0S0=F2F3, M1S0=F6F7, M2S0=F10F11, M3S0=F14F15
F2_FRAMCLK_DIV=2

jesd204_rx_dataout[127:0] = {{F14F15, F10F11,F6F7, F2F3}, {F12F13, F8F9,F4F5, F0F1}}

Table 27.  Data Mapping for F=4, L=4
F = 4
Lane L3 L2 L1 L0
Data In {F12, F13, F14, F15} {F8, F9, F10, F11} {F4, F5, F6, F7} {F0, F1, F2, F3}
Supported M and S M*S=8 for F=4, L=4

F=4 supports either (case1: M=1, S=8), (case2: M=2, S=4), (case3: M=4, S=2) or (case4: M=8, S=1)

F=4

jesd204_rx_dataout[127:0] = {F14F15, F12F13,F10F11, F8F9,F6F7,F4F5, F2F3,F0F1}

Case1: M=1, S=8 {M0S7, M0S6, M0S5, M0S4, M0S3, M0S2, M0S1, M0S0}
Case2: M=2, S=4 {M1S3, M1S2, M1S1, M1S0, M0S3, M0S2, M0S1, M0S0}
Case3: M=4, S=2 {M3S1, M3S0, M2S1, M2S0, M1S1, M1S0, M0S1, M0S0}
Case4: M=8, S=1 {M7S0, M6S0, M5S0, M4S0, M3S0, M2S0, M1S0, M0S0}
Table 28.  Data Mapping for F=8, L=4
F = 8
Lane L3 L2 L1 L0
Data In linkclk T0 {F24, F25, F26, F27} {F16, F17, F18, F19} {F8, F9, F10, F11} {F0, F1, F2, F3}
Data In linkclk T1 {F28, F29, F30, F31} {F20, F21, F22, F23} {F12, F13, F14, F15} {F4, F5, F6, F7}
Supported M and S M*S=16 for F=8, L=4

F=8 supports either (case1: M=1, S=16), (case2: M=2, S=8), (case3: M=4, S=4), (case4: M=8, S=2) or (case5: M=16, S=1)

F=8

jesd204_rx_dataout[255:0] = {{F3031, F28F29,F26F27, F24F25},{F22F23, F20F21,F18F19, F16F17},{F14F15, F12F13, F10F11,F8F9}, {F6F7,F4F5, F2F3,F0F1}}

Case1: M=1, S=16 {M0S15, M0S14, M0S13, M0S12, M0S11, M0S10, M0S9, M0S8, M0S7, M0S6, M0S5, M0S4, M0S3, M0S2, M0S1, M0S0}

RX Error Reporting

For RX path error reporting, the transport layer expects the AL to always be ready to sample the RX data (as indicated by the jesd204_rx_data_ready signal equal to "1") as long as the jesd204_rx_data_valid remains asserted. If the jesd204_rx_data_ready signal unexpectedly deasserts, the transport layer reports the error to the DLL by asserting the jesd204_rx_link_error signal, as shown in the timing diagram below.

Figure 16. RX Error Reporting


RX Latency

The RX latency is defined as the time needed to fully transfer a 32-bit data in a lane (jesd204_rx_link_datain*) to the Avalon-ST interface (jesd204_rx_dataout*) when the jesd204_rx_link_data_valid signal equals to "1".

Table 29.   RX Latency Associated with Different F and FRAMECLK_DIV Settings.
F FRAMECLK_DIV RX Latency
1 1
  • Maximum 5 rxframe_clk period for byte 3
  • Minimum 2 rxframe_clk period for byte 0
1 4 2 rxframe_clk period
2 1
  • Maximum 3 rxframe_clk period for byte 2 and byte 3
  • Minimum 2 rxframe_clk period for byte 0 and byte 1
2 2 2 txframe_clk period
4 — 2 txframe_clk period
8 — 2 txframe_clk period
13 Refer to the txframe_clk and rxframe_clk frequencies table to set the desired frame clock frequency with different FRAMECLK_DIV and F parameter values.
14 This signal should be static and valid before the deassertion of the link_rst_n and frame_rst_n signals.
15 The f2_div1_cnt signal is internally generated in the RX control block to correctly stream data to the Avalon-ST interface.
Level Two Title