The JESD204B IP core incorporates:

• Media access control (MAC)—data link layer (DLL) block that controls the link states and character replacement.
• Physical layer (PHY)—physical coding sublayer (PCS) and physical media attachment (PMA) block.

The JESD204B IP core does not incorporate the Transport Layer (TL) that controls the frame assembly and disassembly. The TL and test components are provided as part of a design example component where you can customize the design for different converter devices.

The JESD204B IP core generates a single link with a single lane and up to a maximum of 8 lanes. If there are two ADC links that need to be synchronized, you have to generate two JESD204B IP cores and then manage the deterministic latency and synchronization signals, like SYSREF and SYNC_N, at your custom wrapper level.

The JESD204B IP core supports duplex mode only if the LMF configuration for ADC (RX) is the same as DAC (TX) and with the same data rate. This use case is mainly for prototyping with internal serial loopback mode. This is because typically as a unidirectional protocol, the LMF configuration of converter devices for both DAC and ADC are not identical.

In a subsystem where there are multiple ADC and DAC converters, you need to use the Intel^® Quartus^® Prime software to merge the transceivers and group them into the transceiver architecture. For example, to create two instances of the JESD204B TX IP core with four lanes each and four instances of the JESD204 RX IP core with two lanes each, you can apply one of the following options:

• MAC and PHY option
  1. Generate JESD204B TX IP core with four lanes and JESD204B RX IP core with two lanes.
  2. Instantiate the desired components.
  3. Use the Intel^® Quartus^® Prime software to merge the PHY lanes.
• MAC only and PHY only option—based on the configuration above, there are a total of eight lanes in duplex mode.
  1. Generate the JESD204B Duplex PHY with a total of eight lanes. (TX skew is reduced in this configuration as the channels are bonded).
  2. Generate the JESD204B TX MAC with four lanes and instantiate it two times.
  3. Generate the JESD204B RX MAC with two lanes and instantiate it four times.
  4. Create a wrapper to connect the JESD204B TX MAC and RX MAC with the JESD204B Duplex PHY.

The Intel^® Quartus^® Prime software installation includes the Intel^® FPGA IP library. Integrate optimized and verified Intel^® FPGA IP cores into your design to shorten design cycles and maximize performance. The Intel^® Quartus^® Prime software also supports integration of IP cores from other sources. Use the IP Catalog (Tools > IP Catalog) to efficiently parameterize and generate synthesis and simulation files for your custom IP variation. The Intel^® FPGA IP library includes the following types of IP cores:

• Basic functions
• DSP functions
• Interface protocols
• Low power functions
• Memory interfaces and controllers
• Processors and peripherals

This document provides basic information about parameterizing, generating, upgrading, and simulating stand-alone IP cores in the Intel^® Quartus^® Prime software.

The Intel^® Quartus^® Prime software installs IP cores in the following locations by default:

This walkthrough explains how to create a JESD204B IP core design using Platform Designer in the Intel^® Quartus^® Prime software. After you generate a custom variation of the JESD204B IP core, you can incorporate it into your overall project.

After successfully compiling your design, program the targeted Altera^® device with the Intel^® Quartus^® Prime Programmer and verify the design in hardware. For instructions on programming the FPGA device, refer to the Device Programming section in the Intel^® Quartus^® Prime Handbook.

You can connect standard interfaces like clock, reset, Avalon-MM, Avalon-ST, HSSI bonded clock, HSSI serial clock, and interrupt interfaces within Platform Designer. However, for conduit interfaces, you are advised to export all those interfaces and handle them outside of Platform Designer. ¹⁵ This is because conduit interfaces are not part of the standard interfaces. Thus, there is no guarantee on compatibility between different conduit interfaces.

Note: The Transport Layer provided in this JESD204B IP core design example is not supported in Platform Designer. Therefore, you must export all interfaces that connect to the Transport Layer (for example, jesd204_tx_link interface) and connect them to a transport layer outside of Platform Designer.

Figure 9. Example of Connecting JESD204B IP Core with Other Platform Designer Components in Platform Designer Figure shows an example of how you can connect the IP core with other Platform Designer components in Platform Designer.

When you generate the JESD204B IP core, your design is not yet complete and the JESD204B IP core is not yet connected in the design. The final clock names and paths are not yet known. Therefore, the Intel^® Quartus^® Prime software cannot incorporate the final signal names in the .sdc file that it automatically generates. Instead, you must manually modify the clock signal names in this file to integrate these constraints with the timing constraints for your full design.

This section describes how to integrate the timing constraints that the Intel^® Quartus^® Prime software generates with your IP core into the timing constraints for your design.

The Intel^® Quartus^® Prime software automatically generates the altera_jesd204.sdc file that contains the JESD204B IP core's timing constraints.

In the .sdc file for your project, make the following command changes:

• Specify the PLL clock reference pin frequency using the create_clock command.
• Derive the PLL generated output clocks from the PLL Altera^® FPGA IP (for Arria V, Cyclone V and Stratix V) or IOPLL Altera^® FPGA IP (for Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX) using the derive_pll_clocks command.
• For Intel^® Stratix^® 10 devices, Altera^® FPGA IOPLL IP core has SDC file which derives the PLL clocks based on your PLL configurations. You need not add the derive_pll_clocks command into your top level SDC file."
• Comment out the create_clock commands for the txlink_clk, reconfig_to_xcvr[0] or reconfig_clk, and tx_avs_clk, rxlink_clk, and rx_avs_clk clocks in the altera_jesd204.sdc file.
• Identify the base and generated clock name that correlates to the txlink_clk, reconfig_clk, and tx_avs_clk, rxlink_clk, and rx_avs_clk clocks using the report_clock command.
• Describe the relationship between base and generated clocks in the design using the set_clock_groups command.

After you complete your design, you must modify the clock names in your .sdc file to the full-design clock names, taking into account both the IP core instance name in the full design, and the design hierarchy. Be careful when adding the timing exceptions based on your design, for example, when the JESD204B IP core handles asynchronous timing between the txlink_clk, rxlink_clk, pll_ref_clk, tx_avs_clk, rx_avs_clk, and reconfig_clk (for Intel^® Arria^® 10, Intel^® Cyclone^® 10 GX, and Intel^® Stratix^® 10 only) clocks.

The table below shows an example of clock names in the altera_jesd204.sdc and input clock names in the user design. In this example, there is a dedicated input clock for the transceiver TX PLL and CDR at the refclk pin. The device_clk is the input to the core PLL clkin pin. The IP core and transceiver Avalon-MM interfaces have separate external clock sources with different frequencies.

However, if your design requires you to connect the rx_avs_clk and reconfig_clk to the same clock, you need to put them in the same clock group.

The table below shows an example where the device_clk in this design is an input into the transceiver refclk pin. The IP core's Avalon-MM interface shares the same clock source as the transceiver management clock.

To use the JESD204B IP core testbench, follow these steps:

1. Generate the simulation model. Refer to Generating the Testbench Simulation Model.
2. Simulate the testbench using the simulator-specific scripts that you have generated. Refer to Simulating the IP Core Testbench.

The JESD204B testbench simulation flow:

1. At the start, the system is under reset (all the components are in reset).
2. After 100 ns, the Transceiver Reset Controller IP core power up and wait for the tx_ready and rx_ready signal from the Transceiver Reset Controller IP to assert.
3. After 500ns The reset signal of the JESD204B TX Avalon-MM interface is released (go HIGH). At the next positive edge of the link_clk signal, the JESD204B TX link powers up by releasing its reset signal.
4. The JESD204B TX link starts transmitting K28.5 characters.
5. The reset signal of the JESD204B RX Avalon-MM interface is released (go HIGH). At the next positive edge of the link_clk signal, the JESD204B RX link powers up by releasing its reset signal.
6. Once the link is out of reset, a SYSREF pulse is generated to reset the LMFC counter inside both the JESD204B TX and RX IP core.
7. When the txlink_ready signal is asserted, the packet generator starts sending packets to the TX datapath.
8. The packet checker starts comparing the packet sent from the TX datapath and received at the RX datapath after the rxlink_valid signal is asserted.
9. The testbench reports a pass or fail when all the packets are received and compared.

The JESD204B IP core implements a transmitter (TX) and receiver (RX) block. Each block has two layers and consists of the following components:

• Media access control (MAC)—DLL block that consists of the link layer (link state machine and character replacement), CSR, Subclass 1 and 2 deterministic latency, scrambler or descrambler, and multiframe counter.
• Physical layer (PHY)—PCS and PMA block that consists of the 8B/10B encoder, word aligner, serializer, and deserializer.

You can specify the datapath and wrapper for your design and generate them separately.

The TX and RX blocks in the DLL utilizes the Avalon-ST interface to transmit or receive data and the Avalon-MM interface to access the CSRs. The TX and RX blocks operate on 32-bit data width per channel, where the frame assembly packs the data into four octets per channel. Multiple TX and RX blocks can share the clock and reset if the link rates are the same.

The transmitter block, which interfaces to DAC devices, takes one of more digital sample streams and converts them into one or more serial streams.

The transmitter performs the following functions:

• Data scrambling
• Frame or lane alignment
• Character generation
• Serial lane monitoring
• 8B/10B encoding
• Data serializer

When lane alignment sequence is enabled through the csr_lane_sync_en register, the ILAS sequence is transmitted after the CGS phase. The ILAS phase takes up four multiframes. For Subclass 0 mode, you can program the CSR (csr_ilas_multiframe) to extend the ILAS phase to a maximum of 256 multiframes before transitioning to the encoded user data phase. The ILAS data is not scrambled regardless of whether scrambling is enabled or disabled.

The multiframe has the following structure:

• Each multiframe starts with a /R/ character (K28.0) and ends with a /A/ character (K28.3)
• The second multiframe transmits the ILAS configuration data. The multiframe starts with /R/ character (K28.0), followed by /Q/ character (K28.4), and then followed by the link configuration data, which consists of 14 octets as illustrated in the table below. It is then padded with dummy data and ends with /A/ character (K28.3), marking the end of multiframe.
• Dummy octets are an 8-bit counter and is always reset when it is not in ILAS phase.
• For a configuration of more than four multiframes, the multiframe follows the same rule above and is padded with dummy data in between /R/ character and /A/ character.

The JESD204B TX IP core also supports debug feature to continuously stay in ILAS phase without exiting. You can enable this feature by setting the bit in csr_ilas_loop register. There are two modes of entry:

• RX asserts SYNC_N and deasserts it after CGS phase. This activity triggers the ILAS phase and the CSR stays in ILAS phase indefinitely until this setting changes.
• Link reinitialization through CSR is initiated. The JESD204B IP core transmits /K/ character and causes the RX converter to enter CGS phase. After RX deasserts SYNC_N, the CSR enters ILAS phase and stays in that phase indefinitely until this setting changes.

In ILAS loop, the multiframe transmission is the same where /R/ character (K28.0) marks the start of multiframe and /A/ character (K28.3) marks the end of multiframe, with dummy data in between. The dummy data is an increment of Dx.y.

The JESD204B IP core supports transmission order from MSB first as well as LSB first. For MSB first transmission, the serialization of the left-most bit of 8B/10B code group (bit "a") is transmitted first.

The receiver block, which interfaces to ADC devices, receives the serial streams from one or more TX blocks and converts the streams into one or more sample streams.

The receiver performs the following functions:

• Data deserializer
• 8B/10B decoding
• Lane alignment
• Character replacement
• Data descrambling

The CGS phase is achieved through the following process:

• Once the word boundary is aligned, the RX PHY layer detects the /K28.5/ 20-bit boundary and indicate that the character is valid.
• The receiver deasserts SYNC_N on the next frame boundary (for Subclass 0) or on the next LMFC boundary (for Subclass 1 and 2) after the reception of four successive /K/ characters.
• After correct reception of another four 8B/10B characters, the receiver assumes full code group synchronization. Error detected in this state machine is the code group error. Code group error always trigger link reinitialization through the assertion of SYNC_N signal and this cannot be disabled through the CSR. The CS state machine is defined as CS_INIT, CS_CHECK, and CS_DATA.
• The minimum duration for a synchronization request on the SYNC_N is five frames plus nine octets.

After CGS phase, the receiver assumes that the first non-/K28.5/ character marks the start of frame and multiframe. If the transmitter emits an initial lane alignment sequence, the first non-/K28.5/ character is /K28.0/. Similar to the JESD204B TX IP core, the csr_lane_sync_en is set to 1 by default, thus the RX core detects the /K/ character to /R/ character transition. If the csr_lane_sync_en is set to 0, the RX core detects the /K/ character to the first data transition. An ILAS error and unexpected /K/ character is flagged if either one of these conditions are violated.

When csr_lane_sync_en is set to 0, you have to disable data checking for the first 16 octets of data as the character replacement block takes 16 octets to recover the end-of-frame pointer for character replacement. When csr_lane_sync_en is set to 1 (default JESD204B setting), the number of octets to be discarded depends on the scrambler or descrambler block.

The receiver assumes that a new frame starts in every F octets. The octet counter is used for frame alignment and lane alignment.

The frame alignment is monitored through the alignment character /F/. The transmitter inserts this character at the end of frame. The /A/ character indicates the end of multiframe. The character replacement algorithm depends on whether scrambling is enabled or disabled, regardless of the csr_lane_sync_en register setting.

The alignment detection process:

• If two successive valid alignment characters are detected in the same position other than the assumed end of frame—without receiving a valid or invalid alignment character at the expected position between two alignment characters—the receiver realigns its frame to the new position of the received alignment characters.
• If lane realignment can result in frame alignment error, the receiver issues an error.

In the JESD204B RX IP core, the same flexible buffer is used for frame and lane alignment. Lane realignment gives a correct frame alignment because lane alignment character doubles as a frame alignment character. A frame realignment can cause an incorrect lane alignment or link latency. The course of action is for the RX to request for reinitialization through SYNC_N. ²²

After the frame synchronization phase has entered FS_DATA, the lane alignment is monitored via /A/ character (/K28.3/) at the end of multiframe. The first /A/ detection in the ILAS phase is important for the RX core to determine the minimum RX buffer release for inter-lane alignment. There are two types of error that is detected in lane alignment phase:

• Arrival of /A/ character from multiple lanes exceed one multiframe.
• Misalignment detected during user data phase.

The realignment rules for lane alignment are similar to frame alignment:

• If two successive and valid /A/ characters are detected at the same position other than the assumed end of multiframe—without receiving a valid/invalid /A/ character at the expected position between two /A/ characters—the receiver aligns the lane to the position of the newly received /A/ characters.
• If a recent frame alignment causes the loss of lane alignment, the receiver realigns the lane frame—which is already at the position of the first received /A/ character—at the unexpected position.

The JESD204B RX IP core captures 14 octets of link configuration data that are transmitted on the 2^nd multiframe of the ILAS phase. The receiver waits for the reception of /Q/ character that marks the start of link configuration data and then latch it into ILAS octets, which are per lane basis. You can read the 14 octets captured in the link configuration data through the CSR. You need to first set the csr_ilas_data_sel register to select which link configuration data lane it is trying to read from. Then, proceed to read from the csr_ilas_octet register.

The receivers in Subclass 1 and Subclass 2 modes store data in a memory buffer (Subclass 0 mode does not store data in the buffer but immediately releases them on the frame boundary as soon as the latest lane arrives.). The RX IP core detects the start of multiframe of user data per lane and then wait for the latest lane data to arrive. The latest data is reported as RBD count (csr_rbd_count) value which you can read from the status register. This is the earliest release opportunity of the data from the deskew FIFO (referred to as RBD offset).

The JESD204B RX IP core supports RBD release at 0 offset and also provides programmable offset through RBD count. By default, the RBD release can be programmed through the csr_rbd_offset to release at the LMFC boundary. If you want to implement an early release mechanism, program it in the csr_rbd_offset register. The csr_rbd_offset and csr_rbd_count is a counter based on the link clock boundary (not frame clock boundary). Therefore, the RBD release opportunity is at every four octets.

The word aligner block identifies the MSB and LSB boundaries of the 10-bit character from the serial bit stream. Manual alignment is set because the /K/ character must be detected in either LSB first or MSB first mode. When the programmed word alignment pattern is detected in the current word boundary, the PCS indicates a valid pattern in the rx_sync_status (mapped as pcs_valid to the IP core). The code synchronization state is detected after the detection of the /K/ character boundary for all lanes.

In a normal operation, whenever synchronization is lost, the JESD204B RX IP core always return back to the CS_INIT state where the word alignment is initiated. For debug purposes, you can bypass this alignment by setting the csr_patternalign_en register to 0.

The 8B/10B decoder decode the data after receiving the data through the serial line. The JESD204B IP core supports transmission order from MSB first as well as LSB first.

The PHY layer can detect 8B/10B not-in-table (NIT) error and also running disparity error.

The JESD204B IP core maintains a LMFC counter that counts from 0 to (F × K/4)–1 and wraps around again. The LMFC counter starts counting at the deassertion of SYNC_N signal from multiple DACs after synchronization. This is to align the LMFC counter upon transmission and can only be done after all the converter devices have deasserted its synchronization request signal.

The JESD204B IP core maintains a LMFC counter that counts from 0 to (F × K/4)–1 and wraps around again. The LMFC counter resets within two link clock cycles after converter devices issue a common SYSREF frequency to all the transmitters and receivers. The SYSREF frequency must be the same for converter devices that are grouped and synchronized together.

The JESD204B IP core maintains a LMFC counter that counts from 0 to (F × K/4)–1 and wraps around again. The LMFC count starts upon reset and the logic device always acts as the timing master. To support Subclass 2 for multi-link device, you must deassert the resets for all JESD204B IP core links synchronously at the same clock edge. This deassertion ensures that the internal LMFC vaunter is aligner across multi-link. The converters adjust their own internal LMFC to match the master's counter. The alignment of LMFC within the system relies on the correct alignment of SYNC_N signal deassertion at the LMFC boundary.

The alignment of LMFC to RX logic is handled within the TX converter. The RX logic releases SYNC_N at the LMFC tick and the TX converter adjust its internal LMFC to match the RX LMFC.

For the alignment of LMFC to the TX logic, the JESD204B TX IP core samples SYNC_N from the DAC receiver and reports the relative phase difference between the DAC and TX logic device LMFC in the TX CSR (dbg_phadj, dbg_adjdir, and dbg_adjcnt). Based on the reported value, you can calculate the adjustment required. Then, to initiate the link reinitialization through the CSR, set the value in the TX CSR (csr_phadj, csr_adjdir, and csr_adjcnt). The values on the phase adjustment are embedded in bytes 1 and 2 of the ILAS sequence that is sent to the DAC during link initialization. On the reception of the ILAS, the DAC adjusts its LMFC phase by step count value and sends back an error report with the new LMFC phase information. This process may be repeated until the LMFC at the DAC and the logic device are aligned.

The JESD204B TX and RX IP core support scrambling by implementing a 32-bit parallel scrambler in each lane. The scrambler and descrambler are located in the JESD204B IP MAC interfacing to the Avalon-ST interface. You can enable or disable scrambling and this option applies to all lanes. Mixed mode operation, where scrambling is enabled for some lanes, is not permitted.

The scrambling polynomial:

1 + x¹⁴ + x¹⁵

The descrambler can self-synchronize in eight octets. In a typical application where the reset value of the scrambler seed is different from the converter device to FPGA logic device, the correct user data is recovered in the receiver in two link clocks (due to the 32-bit architecture). The PRBS pattern checker on the transport layer should always disable checking of the first eight octets from the JESD204B RX IP core.

In some applications, multiple converters are grouped together in the same group path to sample a signal (referred as multipoint link). The FPGA can only start the LMFC counter and its transition to ILAS after all the links deassert the synchronization request. The JESD204B TX IP core provides three signals to facilitate this application. The SYNC_N is the direct signal from the DAC converters. The error signaling from SYNC_N is filtered and sent out as dev_sync_n signal. For Subclass 0, you need to multiplex all the dev_sync_n signals in the same multipoint link and then input them to the IP core through mdev_sync_n signal.

For Subclass 1 implementation, you may choose to combine or not to combine the SYNC_N signal from the converter device. If you implement two ADC converter devices as a multipoint link and one of the converter is unable to link up, the functional link still operates. You must manage the trace length for the SYSREF signal and also the differential pair to minimize skew.

The SYNC_N is the direct signal from the DAC converters. The error signaling from SYNC_N is filtered and sent out as dev_sync_n output signal. The dev_sync_n signal from the JESD204B TX IP core must loopback into the mdev_sync_n signal of the same instance without combining the SYNC_N signal.

You must set the same RBD offset value (csr_rbd_offset) to all the JESD204B RX IP cores within the same multipoint link for the RBD release (the latest lane arrival for each of the links). The JESD204B RX IP core deskews and outputs the data when the RBD offset value is met. The total latency is consistent in the system and is also the same across multiple resets. Setting a different RBD offset to each link or setting an early release does not guarantee deterministic latency and data alignment.

There are two modes of entry for link reinitialization:

• Hardware initiated link reinitialization:
  • For TX, the reception of SYNC_N for more than five frames and nine octets triggers link reinitialization.
  • For RX, the loss of code group synchronization, frame alignment and lane alignment errors cause the IP core to assert SYNC_N and request for link reinitialization.
• Software initiated link reinitialization—both the TX and RX IP core allow software to request for link reinitialization.
  • For TX, the IP core transmits /K/ character and wait for the receiver to assert SYNC_N to indicate that it has entered CS_INIT state.
  • For RX, the IP core asserts SYNC_N to request for link reinitialization.

Hardware initiated link reinitialization can be globally disabled through the csr_link_reinit_disable register for debug purposes.

Hardware initiated link reinitialization can be issued as interrupt depending on the error type and interrupt error enable. If lane misalignment has been detected as a result of a phase change in local timing reference, the software can rely on this interrupt trigger to initiates a LMFC realignment. The realignment process occurs by first resampling SYSREF and then issuing a link reinitialization request.

The JESD204B TX IP core can detect error reporting through SYNC_N when SYNC_N is asserted for two frame clock periods (if F >= 2) or four frame clock periods (if F = 1). When the downstream device reports an error through SYNC_N, the TX IP core issues an interrupt. The TX IP core samples the SYNC_N pulse width using the link clock.

For a special case of F = 1, two frame clock periods are less than one link clock. Therefore, the error signaling from the receiver may be lost. You must program the converter device to extend the SYNC_N pulse to four frame clocks when F = 1.

The JESD204B RX IP core does not report an error through SYNC_N signaling. Instead, the RX IP core issues an interrupt when any error is detected.

You can check the csr_tx_err, csr_rx_err0, and csr_rx_err1 register status to determine the error types.

This section describes the clocking scheme for the JESD204B IP core and transceiver.

Based on the JESD204B specification for Subclass 1, the device clock is the timing reference and is source synchronous with SYSREF. To achieve deterministic latency, match the board trace length of the SYSREF signal with the device clock. Maintain a constant phase relationship between the device clock and SYSREF signal pairs going to the FPGA and converter devices. Ideally, the SYSREF pulses from the clock generator should arrive at the FPGA and converter devices at the same time. To avoid half link clock latency variation, you must supply the device clock at the same frequency as the link clock.

The JESD204B protocol does not support rate matching. Therefore, you must ensure that the TX or RX device clock (pll_ref_clk) and the PLL reference clock that generates link clock (txlink_clk or rxlink_clk) and frame clock (txframe_clk or rxframe_clk) have 0 ppm variation. Both PLL reference clocks should come from the same clock chip.

Due to the clock network architecture in the FPGA, JESD204B IP core does not use the device clock to clock the SYSREF signal because the GCLK or RCLK is not fully compensated. You are recommended to use the PLL Intel^® FPGA IP core (in Arria V, Cyclone V, and Stratix V devices) or IOPLL Intel^® FPGA IP core (in Intel^® Arria^® 10, Intel^® Cyclone^® 10 GX, and Intel^® Stratix^® 10 devices) to generate both the link clock and frame clock. The PLL Intel^® FPGA IP core must operate in normal mode or source synchronous mode and uses a dedicated reference clock pin as the input reference clock source to achieve the following state:

• the GCLK and RCLK clock network latency is fully compensated.
• the link clock and frame clock at the registers are phase-aligned to the input of the clock pin.

To provide consistency across the design regardless of frame clock and sampling clock, the link clock is used as a timing reference.

The PLL Intel^® FPGA IP core should provide both the frame clock and link clock from the same PLL as these two clocks are treated as synchronous in the design.

For Subclass 0 mode, the device clock is not required to sample the SYSREF signal edge. The link clock does not need to be phase compensated to capture SYSREF. Therefore, you can generate both the link clock and frame clock using direct mode in the PLL Intel^® FPGA IP core. If F = 4, where link clock is the same as the frame clock, you can use the parallel clock output from the transceiver (txphy_clk or rxphy_clk signal) except when the PCS option is in PMA Direct mode.

The K parameter must be set between 1 to 32 and meet the requirement of at least a minimum of 17 octets and a maximum of 1024 octets in a single multiframe. In a 32-bit architecture, the K × F must also be in the order of four.

In a Subclass 1 deterministic latency system, the SYSREF frequency is distributed to the devices to align them in the system. The SYSREF resets the internal LMFC clock edge when the sampled SYSREF signal's rising edge transition from 0 to 1. Due to source synchronous signaling of SYSREF with respect to the device clock sampling (provided from the clock chip), the JESD204B IP core does not directly use the device clock to sample SYSREF but instead uses the link clock to sample SYSREF. Therefore, the Altera^® FPGA PLL IP core that provides the link clock must to be in normal mode to phase-compensate the link clock to the device clock.

Based on hardware testing, to get a fixed latency, at least 32 octets are recommended in an LMFC period so that there is a margin to tune the RBD release opportunity to compensate any lane-to-lane deskew across multiple resets. If F = 1, then K = 32 is optimal as it provides enough margin for system latency variation. If F = 2, then K = 16 and above (18/20/22/24/26/28/30/32) is sufficient to compensate lane-to-lane deskew.

The JESD204B IP core implements the local multiframe clock as a counter that increments in link clock counts. The local multiframe clock counter is equal to (F × K/4) in link clock as units. The rising edge of SYSREF resets the local multiframe clock counter to 0. There are two CSR bits that controls SYSREF sampling.

• csr_sysref_singledet—resets the local multiframe clock counter once and automatically cleared after SYSREF is sampled. This register also prevents CGS exit to bypass SYSREF sampling.
• csr_sysref_alwayson—resets the local multiframe clock counter at every rising edge of SYSREF that it detects. This register also enables the SYSREF period checker. If the provided SYSREF period violates the F and K parameter, an interrupt is triggered. However, this register does not prevent CGS-SYSREF race condition.

The following conditions occur if both CSR bits are set:

• resets the local multiframe clock counter at every rising edge of SYSREF.
• prevents CGS-SYSREF race condition.
• checks SYSREF period.

Features available:

• Programmable RBD offset.
• Programmable LMFC offset.

The setup time is analyzed when you set the timing constraint for the SYSREF signal in the user .sdc file. When the setup time is met, the SYSREF signal detection by the IP core is deterministic; the number of link clock cycles of SYSREF signal that arrives at the FPGA pin to the LMFC counter resets, is deterministic.

Apply the set_input_delay constraint on the SYSREF signal with respect to device clock in the user .sdc file:

set_input_delay -clock <device clock name at FPGA pin> <sysref IO delay in ns> [get_ports <sysref name at FPGA pin >]

The SYSREF IO delay is the board trace length mismatch between device clock and SYSREF. For example:

set_input_delay -clock device_clk 0.5 [get_ports sysref]

The above statement constrains the FPGA SYSREF signal (sysref), with respect to the FPGA device clock (device_clk) pin. The trace length mismatch resulted in 500 ps or 0.5 ns difference in time arrival at the FPGA pins between SYSREF and device clock.

In most cases, the register in the IP core, which detects the SYSREF signal, is far away from the SYSREF I/O pin. The long interconnect routing delay results in timing violation. You are recommended to use multi-stages pipeline registers to close timing. Use the same clock domain as the JESD204B IP core's rxlink_clk and txlink_clk to clock the multi-stages pipeline registers.

You must set a safe RBD offset value to ensure deterministic latency from one power cycle to another power cycle. Follow these steps to set a safe RBD offset value:

1. Read the RBD count from the csr_rbd_count field in rx_status0 register. Record the value.
2. Power cycle the JESD204B subsystem, which consists of the FPGA and converter devices.
3. Read the RBD count again and record the value.
4. Repeat steps 1 to 3 at least 5 times and record the RBD count values.
5. Set the csr_rbd_offset accordingly with one LMFC count tolerance.
6. Perform multiple power cycles and make sure lane deskew error does not occur using this RBD offset value.

The RBD count must be fairly consistent, within 2 counts variation from one power cycle to another power cycle. In the following examples, the parameter values are L > 1, F=1 and K=32. The legal values of the LMFC counter is 0 to ((FxK/4)-1), which is 0 to 7. In Figure 28 , the latest arrival lane variation falls within 1 local multiframe period. In this scenario, if latency is not a concern, you can leave the default value of csr_rbd_offset=0, which means the RBD elastic buffer is released at the LMFC boundary. In Figure 29 , the latest arrival lane variation spans across 2 local multiframes; the latest arrival lane variation happens before and after the LMFC boundary. In this scenario, you need to configure the RBD offset correctly to avoid lane deskew error as indicated in bit 4 of rx_err0 register.

In the example above, lane deskew error happens if the sum of the difference of /R/ character’s LMFC count in the earliest arrival lane to the latest arrival lane, and the number of LMFC count up to the release of RBD elastic buffer exceeds the RBD elastic buffer size. If this is the root cause of lane deskew error, setting RBD offset is one of the techniques to overcome this issue. Not every RBD offset value is legal. Figure below illustrates the technique to decide the legal RBD offset value.

Because the IP core does not report the position of the earliest lane arrival with respect to the LMFC boundary, you must perform multiple power cycles to observe the RBD count and tune the RBD offset accordingly until no lane deskew error occurs. From the example in the figure above, the recommended RBD offset value is 4 or 5. Setting RBD offset to 1, 2 or 3 is illegal because this exceeds the RBD elastic buffer size for the F and K configurations.

The TX LMFC offset can align the TX LMFC counter to the LMFC counter in DAC; the RX LMFC offset can align the RX LMFC counter to the LMFC counter in ADC. Phase offset between the TX and RX LMFC counters in the both ends of the JESD204B link contributes to deterministic latency uncertainty. The phase offset is caused by:

• SYSREF trace length mismatch in the PCB between the TX and RX devices (FPGA and converters).
• delay differences in resetting the LMFC counter when SYSREF pulses are detected by the FPGA and converter devices.

The RX device in the JESD204B link is responsible for deterministic latency adjustments. The following figure illustrates the adjustments that you can make to the RX LMFC offset using the csr_lmfc_offset field in the syncn_sysref_ctrl register. This is an alternative to using csr_rbd_offset to achieve deterministic latency.

You should set a safe LMFC offset value to ensure deterministic latency from one power cycle to another power cycle. In Figure 32, the illegal csr_lmfc_offset values of 1, 2, and 3 causes lane de-skew error because the RBD buffer size has exceeded.

You can use the TX LMFC offset to align the LMFC counter in IP core to the LMFC counter in DAC.

Alternative to tuning RBD offset at the DAC, adjusting TX LMFC offset in the FPGA helps you to achieve deterministic latency. You should perform multiple power cycles and read the RBD counts at the DAC to determine whether deterministic latency is achieved and RBD elastic buffer size has not exceeded.

The SYSREF pipeline registers in the FPGA introduce additional latency to SYSREF when detected by the IP core. Therefore, you can use TX LMFC offset to reduce or eliminate this additional latency. The next figure illustrates the technique of optimizing latency using TX LMFC offset.

The csr_lmfc_offset field provides a convenient way to achieve deterministic latency and potentially optimizing the IP core latency. There are other ways that you can achieve deterministic latency by using the features available at the converters. Consult the converter manufacturer for details of these features.

The converters resample the SYSREF signal and reset the internal LMFC counter. When the link is initially established, the IP core automatically clears the csr_sysref_singledet bit in the syncn_sysref_ctrl register (address 0x54) when it detects the SYSREF pulse. The IP core does not automatically resample the SYSREF pulse unless the jesd204_tx_avs_rst_n or jesd204_rx_avs_rst_n signal is asserted.

If you are performing a link reset by asserting txlink_rst_n or rxlink_rst_n to reinitialize the link, set the csr_sysref_singledet bit to "1" to force the IP core to resample the SYSREF pulse without asserting the jesd204_tx_avs_rst_n or jesd204_rx_avs_rst_n signal.