The following sections list the device family and device speed grade support offered by the CPRI Intel^® FPGA IP core:

Intel^® FPGA IP versions match the Intel^® Quartus^® Prime Design Suite software versions until v19.1. Starting in Intel^® Quartus^® Prime Design Suite software version 19.2, Intel^® FPGA IP has a new versioning scheme.

The Intel^® FPGA IP version (X.Y.Z) number can change with each Intel^® Quartus^® Prime software version. A change in:

• Simulate the behavior of a licensed Intel^® FPGA IP core in your system.
• Verify the functionality, size, and speed of the IP core quickly and easily.
• Generate time-limited device programming files for designs that include IP cores.
• Program a device with your IP core and verify your design in hardware.

Intel^® FPGA IP Evaluation Mode supports the following operation modes:

• Tethered—Allows running the design containing the licensed Intel^® FPGA IP indefinitely with a connection between your board and the host computer. Tethered mode requires a serial joint test action group (JTAG) cable connected between the JTAG port on your board and the host computer, which is running the Intel^® Quartus^® Prime Programmer for the duration of the hardware evaluation period. The Programmer only requires a minimum installation of the Intel^® Quartus^® Prime software, and requires no Intel^® Quartus^® Prime license. The host computer controls the evaluation time by sending a periodic signal to the device via the JTAG port. If all licensed IP cores in the design support tethered mode, the evaluation time runs until any IP core evaluation expires. If all of the IP cores support unlimited evaluation time, the device does not time-out.
• Untethered—Allows running the design containing the licensed IP for a limited time. The IP core reverts to untethered mode if the device disconnects from the host computer running the Intel^® Quartus^® Prime software. The IP core also reverts to untethered mode if any other licensed IP core in the design does not support tethered mode.

When the evaluation time expires for any licensed Intel^® FPGA IP in the design, the design stops functioning. All IP cores that use the Intel^® FPGA IP Evaluation Mode time out simultaneously when any IP core in the design times out. When the evaluation time expires, you must reprogram the FPGA device before continuing hardware verification. To extend use of the IP core for production, purchase a full production license for the IP core.

You must purchase the license and generate a full production license key before you can generate an unrestricted device programming file. During Intel^® FPGA IP Evaluation Mode, the Compiler only generates a time-limited device programming file (<project name> _time_limited.sof) that expires at the time limit.

Intel^® licenses IP cores on a per-seat, perpetual basis. The license fee includes first-year maintenance and support. You must renew the maintenance contract to receive updates, bug fixes, and technical support beyond the first year. You must purchase a full production license for Intel^® FPGA IP cores that require a production license, before generating programming files that you may use for an unlimited time. During Intel^® FPGA IP Evaluation Mode, the Compiler only generates a time-limited device programming file (<project name> _time_limited.sof) that expires at the time limit. To obtain your production license keys, visit the Self-Service Licensing Center.

The Intel^® FPGA Software License Agreements govern the installation and use of licensed IP cores, the Intel^® Quartus^® Prime design software, and all unlicensed IP cores.

• General
• Interfaces
• Advanced
• Simulation

CPRI Intel^® FPGA IP cores that target Arria V, Arria V GZ, Cyclone V, and Stratix V devices require an external reconfiguration controller to compile and to function correctly in hardware. CPRI IP cores that target Intel^® Arria^® 10 or Intel^® Stratix^® 10 devices include a transceiver reconfiguration controller block and do not require an external reconfiguration controller.

You can use the IP Catalog to generate the Transceiver Reconfiguration Controller Intel FPGA IP core required for Arria V, Arria V GZ, Cyclone V, and Stratix V designs.

When you configure the Transceiver Reconfiguration Controller, you must specify the number of reconfiguration interfaces. The number of reconfiguration interfaces required for the CPRI IP core depends on the CPRI IP core configuration and your design.For example, you can configure your reconfiguration controller with additional interfaces if your design connects with multiple transceiver IP cores. You can leave other options at the default settings or modify them for your preference. Refer to the V-Series Transceiver PHY User Guide.

You should connect the reconfig_to_xcvr and reconfig_from_xcvr ports of the CPRI IP core to the corresponding ports of the reconfiguration controller.

You must drive the CPRI IP core reconfig_clk input port and the Altera Transceiver Reconfiguration Controller mgmt_clk_clk input port from the same clock source. Drive both ports at a clock frequency in the range of 100–150MHz.

The F-Tile Reference and System PLL Clocks Intel FPGA IP must always connect to the F-Tile Ethernet Intel FPGA Hard IP or a protocol IP. The F-Tile Reference and System PLL Clocks Intel FPGA IP cannot be compiled or simulated as a standalone IP. For more information on parameters and port list for F-Tile Reference and System PLL Clocks Intel FPGA IP core, refer to the F-tile Architecture and PMA/FEC Direct PHY IP User Guide.

When you design multiple interfaces or protocol-based IP cores within a single F-tile, you can only use three System PLLs. For example, you can use one System PLL for PCIe and two for Ethernet and other protocols. However, there are other use cases where you can use all three for various interfaces within the Ethernet and PMA-Direct digital blocks. As there are only three System PLLs, multiple interfaces or protocol-based IP cores with different line rates may have to share a System PLL. While sharing a System PLL, the interface with the highest line rate determines the system PLL frequency, and the interfaces with the lower line rates must be overclocked. For more information, refer to the F-tile Architecture and PMA/FEC Direct PHY IP User Guide.

The main CPRI IP core clock is cpri_clkout.

To reset the entire CPRI IP core, you must assert the reset signals to the IP core and to the required external reset controller logic. The external reset controller logic resets only the transceiver. If you instantiate a duplex CPRI IP core, you must instantiate two PHY Reset Controllers to implement this logic, one for the TX data path and one for the RX data path. The two reset signals reset_tx_n and reset_rx_n each cause the reset logic to reset the relevant data path of the IP core. If you connect these two reset signals to the corresponding PHY Reset Controllers, each one also causes the transceiver in that data path to reset.

In the case of a duplex CPRI IP core , you can assert the reset_n signal instead of asserting the two reset signals reset_tx_n and reset_rx_n. However, unless you also connect the reset_n signal to the external reset controllers, the transceivers do not reset in this case.

In addition, some individual interfaces to the IP core have their own reset signals to reset only the associated interface and logic.

To reset the CPRI IP core, you must assert the active low reset_tx_n, reset_rx_n, reset_tx_n and reset_rx_n, or reset_n signals, as appropriate.

To reset the transceiver, you must trigger the reset controller logic. If you make the optional connection to drive the reset_rx_n or reset_n port from the same source as the reset signal for the RX side Reset Controller, asserting the active low reset_rx_n or reset_n signal also triggers the reset controller logic. If you make the optional connection to drive the reset_tx_n or reset_n port from the same source as the reset signal for the TX side Reset Controller, asserting the active low reset_tx_n or reset_n signal also triggers the TX reset controller logic.

When you trigger the reset controllers, they should deassert the xcvr_reset_tx_ready and xcvr_reset_rx_ready input ready signals to the IP core. After each reset controller completes resetting the transceiver and IP core data path, it should assert the relevant ready signal.

For information about resetting the Intel^® Stratix^® 10 E- tile and Intel^® Agilex™ E- tile transceiver, refer to the Resetting Transceiver Channels.

After reset, if you turned on Enable start-up sequence state machine in the CPRI IP core, the internal state machine performs link synchronization and other initialization tasks. If you did not turn on Enable start-up sequence state machine, user logic should perform these functions.

The internal state machine implements the start-up state machine transitions shown in section 4.5.2, Figure 30: Start-up states and transitions, and described in section 4.5.3, in the CPRI specification. In addition, the internal state machine implements the following transitions from State G: Passive Link.

• If you assert reconfig_reset, the start-up state machine transitions to State A.
• If the IP core detects any of the following situations, the start-up state machine transitions to State B:
  • Deassertion of reconfig_reset.
  • Loss of signal (LOS). Refer to Direct L1 Control and Status Interface and FLSAR Register.
  • Loss of frame (LOF). Refer to Direct L1 Control and Status Interface and FLSAR Register.
  • Remote alarm indication (RAI). Refer to Direct L1 Control and Status Interface and FLSAR Register.
  • L1 start-up timer expiration. If you turn on Enable start-up sequence state machine option, the IP core responds to both the nego_l1_timer_expired port and startup_timer_expired field of the START_UP_SEQ register at offset 0x24.
• When HFNSYNC = 1, either read from the L1_STATUS_REGISTER offset 0x04 or from state_l1_sync[2:0], set nego_bitrate_complete_1. Then, the start-up state machine transitions from B to C.
• If the IP core detects that protocol negotiation is not complete, the start-up state machine transitions to State C. The IP core detects that protocol negotiation is not complete if the following conditions hold:
  • You set nego_protocol_complete signal to 0 when you turn off Enable protocol version and C&M channel setting auto-negotiation option, or
  • nego_protocol_complete field of the START_UP_SEQ register at offset 0x24 has the value of 0, or
  • Slave protocol version does not match the protocol version of the CPRI master. Specifically, the rx_prot_ver and tx_prot_ver fields of the PROT_VER register at offset 0x10 have different values. When you turn on Enable protocol version and C&M channel setting auto-negotiation option, the IP core allows deframer to detect the incoming protocol version to the rx_prot_ver, and compare it to the proposed tx_prot_ver. If they are different, IP core detects that protocol negotiation is not complete. With this option ON, you can tie nego_protocol_complete input port to 0. Internally, it is set to 1 once the protocol negotiation is completed.
• When in State C, either of the following condition moves to State D:
  • When you turn on Enable protocol version and C&M channel setting auto-negotiation (prot_ver_auto sets to 1), the IP core allows deframer to detect the incoming protocol version to the rx_prot_ver, and compare it to the proposed tx_prot_ver. If the value matches, it will set nego_protocol_complete to 1 internally, the nego_protocol_complete can be tie off to 0 externally.
  • If Enable protocol version and C&M channel setting auto-negotiation is disabled. You must manually change the PROT_VER[7:0] register offset 0x10 tx_prot_ver each iteration (you can wait for few milisecond before changing to new value of 2 or 1) until read back for rx_prot_ver_valid is 1, then drive the nego_protocol_complete to 1.
• If the IP core detects that control and management negotiation is complete, the start-up state machine transitions to State D. The IP core detects that control and management negotiation is not complete if the following conditions hold:
  • You set nego_protocol_complete signal to 0 when you turn off Enable protocol version and C&M channel setting auto-negotiation option, or
  • nego_cm_complete field of the START_UP_SEQ register at offset 0x24 has the value of 0, or
  • rx_slow_cm_rate_valid field of the CM_STATUS register has the value of 0, and
  • rx_fast_cm_ptr_valid field of the CM_STATUS register has the value of 0.
• When in State D, the following condition moves to State E:
  • When you turn on Enable protocol version and C&M channel setting auto-negotiation (prot_ver_auto sets to 1), the IP core allows deframer to detect the incoming C&M rate rx_slow_cm_rate and rx_fast_cm_ptr, and compare it to the proposed tx_slow_cm_rate and tx_fast_cm_ptr. If the value matches, it will set nego_protocol_complete to 1 internally, the nego_protocol_complete can be tie off to 0 externally.
  • If Enable protocol version and C&M channel setting auto-negotiation is disabled. You must manually change the CM_CONFIG[5:0] (offset x1C) tx_fast_cm_ptr and/or CM_CONFIG[10:8] (offset x1C) tx_slow_cm_rate, and then poll CM_STATUS (offset 20h) rx_slow_cm_rate_valid or rx_fast_cn_ptr_valid (may be for few hyperframe).
    • If valid is not asserted, change to new value.
    • If valid is asserted, drive nego_cm_complete to 1 (you can wait for few milisecond before changing to new value) until read back for rx_prot_ver_valid is 1, then drive nego_protocol_complete to 1.

      Always start from higher value base on the CPRI Spec 4.2.7.6. L1 Inband Protocol, Z.66.0 for slow C&M, Z.194.0 for Fast C&M.

• When in State E, the following condition moves to State F:
  • During this state, the negotiation are vendor specific and the CPRI MAC IP core do not support any auto-negotiation. Drive the nego_vss_complete to 1 when the negotiation is completed.

After reset, if you turned on Enable start-up sequence state machine in the CPRI Intel^® FPGA IP, the internal state machine performs link synchronization and other initialization tasks. If you did not turn on Enable start-up sequence state machine, user logic must perform these functions.

The signals visible in the interface depend on whether or not you turned on Enable start-up sequence state machine.

Intel^® provides configurable write latency on the AUX TX interface and other direct TX interfaces to support user logic with sufficient advance notice of the position in the CPRI frame. The processing time that user logic requires after determining the current position in the CPRI frame is implementation specific, and the default write latency of a single cpri_clkout cycle might not be adequate. Using the Auxiliary and direct interfaces write latency cycle(s) parameter, you can set the write latency to the number of clock cycles required for your system to process data before sending it on the AUX TX interface or other direct TX interface.

In the CPRI parameter editor, you can specify a non-zero number of Auxiliary and direct interfaces write latency cycle(s) to increase the write latency on the AUX TX interface and other direct TX interfaces to the CPRI IP.

The write latency is the number of cpri_clkout cycles from when the aux_tx_seq output signal has the value of n to when user logic must write data to the AUX TX interface to target the corresponding position in the CPRI frame. For other direct interfaces, the IP core notifies user logic when it is ready for input and the user does not need to monitor the aux_tx_seq signal. However, the Auxiliary latency cycle(s) value does apply to all of the direct interfaces.

When Auxiliary and direct interfaces write latency cycle(s) has the default value of zero, the write latency on the direct TX interfaces is one cpri_clkout cycle. When Auxiliary and direct interfaces write latency cycle(s) has the value of N, the write latency is (1+N) cpri_clkout cycles.

User logic is responsible to ensure that the data presented to the Intel^® FPGA IP core on the AUX TX interface is presented at the correct write latency relative to the AUX TX interface synchronization signals.

The information on the AUX interface and all of the other direct interfaces except the L1 CSR interface, appears in the relevant data bus in 32-bit words. The CPRI Intel^® FPGA IP converts the contents of the incoming CPRI frame to a 32-bit format internally. Similarly, the IP core expects to receive data on the various direct interfaces in this format. The only exception is the L1 CSR interface, which transmits and receives information in individual bits.

The CPRI IP core passes the incoming AUX data through to the CPRI link unmodified. You must ensure that the incoming AUX data bits already include any CRC values expected by the application at the other end of the CPRI link.

This interface is Avalon-ST compliant with a ready latency value of 1.

You can alter the transmit latency with the Auxiliary and direct interfaces write latency cycle(s) parameter.

This interface is Avalon-ST compliant with a ready latency value of 1.

You can alter the transmit latency with the Auxiliary and direct interfaces write latency cycle(s) parameter.

The aux_rx_x and aux_rx_seq signals are not part of this interface and are available only if you turn on the AUX interface in your CPRI IP variation. However, their presence in the timing diagram explains the timing of the ctrl_axc_rx_valid output signal that you use to identify the clock cycles with valid Ctrl_Axc data.

This interface is Avalon-ST compliant with a ready latency value of 1.

You can alter the transmit latency with the Auxiliary and direct interfaces write latency cycle(s) parameter.

This option is only available if you specify a CPRI line bit rate of 10.1376 Gbps for your IP core.

This interface is Avalon-ST compliant with a ready latency value of 1.

You can alter the transmit write latency with the Auxiliary and direct interfaces write latency cycle(s) parameter.

This interface is Avalon-ST compliant with a ready latency value of 1.

You can alter the transmit write latency with the Auxiliary and direct interfaces write latency cycle(s) parameter. However, you do not need to view the aux_tx_seq signal for correct alignment. You can monitor the hdlc_rx_valid and hdlc_tx_ready signals to discover the correct times to read and write data on this interface.

If you turn on Enable direct Z.130.0 alarm bits access interface in the CPRI parameter editor, the direct L1 control and status interface is available. This interface provides direct access to the Z.130.0 alarm and reset signals (loss of frame (LOF), loss of signal (LOS), service access point (SAP) defect indication (SDI), remote alarm indication (RAI), and reset request or acknowledge) in the CPRI hyperframe.

If you connect the AUX interface of your RE slave IP core to a network switch or other routing layer rather than directly to the downstream RE master, or if you do not fully connect the AUX interface to the downstream RE master, you can use this Z.130.0 access interface to streamline the transfer of reset requests and SDI alarms across hops.

This interface has higher transmit priority than access through the CPRI IP core registers.

• _local_ signals are output signals from the IP core about the state of this IP core, and also indicate the IP core asserts the relevant outgoing Z.130.0 bit in the next CPRI hyperframe according to the transmit priority of this interface.
• _assert signals are input signals the application can use to request that the IP core assert the relevant outgoing Z.130.0 bit in the next CPRI hyperframe according to the transmit priority of this interface. You can also connect these signals in an RE master to the corresponding _req output signals of the upstream RE slave in a multi-hop configuration, to support efficient transfer of reset requests and SDI alarms to the IP core.
• _remote signals are output signals from the IP core that indicate the IP core received a Z.130.0 byte on the CPRI link with the relevant bit asserted by the CPRI link partner.
• _req signals are also output signals from the IP core that indicate the IP core received a Z.130.0 byte on the CPRI link with the relevant bit asserted by the CPRI link partner. However, these signals are intended to be passed downstream in a multi-hop configuration. If the IP core is an RE slave, and it connects to an RE master through the Z.130.0 alarm and reset interface in a multi-hop configuration, you can connect the RE slave IP core _req output signal directly to the corresponding _assert input signal on the downstream RE master for efficient communication of the reset request or SDI alarm.

If you turn on Enable L1 debug interfaces in the CPRI parameter editor, the L1 debug interface is available.

The MII supports the bandwidth described in the CPRI Specification in Table 12, Achievable Ethernet bit rates.

The GMII supports the bandwidth described in the CPRI Specification in Table 12, Achievable Ethernet bit rates.

When you turn on Enable all control word access via management interface in the CPRI parameter editor, you can access the 256 control words in a hyperframe through the CPRI Intel^® FPGA IP core CPU interface. The CTRL_INDEX register and the RX_CTRL register support your application in reading the incoming control words, and the L1_CONFIG register, CTRL_INDEX register, and TX_CTRL register support the application in writing to outgoing control words.

Register support provides you access to the full control word. Alternatively, in timing-critical applications, you can access the full control words through the CPRI IP core AUX interface or other dedicated direct interfaces.

The rx_ctrl_x and tx_ctrl_x fields of the CTRL_INDEX register hold the X value of the control word you want to access through the control and status interface.

You can access 32 bits in a single register access. Depending on the CPRI line bit rate, a control word may have multiple 32-bit sections. Therefore, in addition to specifying the control word location in the CPRI frame, you must also specify a 32-bit aligned position in the control word.

• At the CPRI line bit rate of 0.6144 Gbps, when you access hyperframe control word X, the 8-bit control word from hyperframe position #Z.X.0 is in bits [31:24] of the register.
• At the CPRI line bit rate of 1.2288 Gbps, the byte from position #Z.X.0.0 is in bits [31:24] of the register and the byte from position #Z.X.0.1 is in bits [23:16] of the register.
• At the CPRI line bit rate of 3.072 Gbps, you must access the register twice to retrieve or write the full control word. In the first access operation, you access the 32 bits of the control word in positions #Z.X.0.0 (in register bits [31:24]), #Z.X.0.1 (in register bits [23:16]), #Z.X.0.2 (in register bits [15:8]), and #Z.X.0.3 (in register bits [7:0]). In the second access operation, you access the eight bits of the control word in position #Z.X.0.4 in bits [31:24] of the register.

A control receive table contains one entry for each of the 256 control words in the current hyperframe. To read a control word, your application must write the control word number X to the rx_ctrl_x field of the CTRL_INDEX register and then read the last received #Z.X control word from the RX_CTRL register. Because the register can hold only 32 bits at a time, depending on the CPRI line bit rate, reading the full control word may require multiple register accesses. Increment the value in the rx_ctrl_seq field of the CTRL_INDEX register from zero to four to access the full control word when the CPRI line bit rate is 10.1376 Gbps, or from zero to two when the CPRI line bit rate is 6.144 Gbps, for example.

A control transmit table contains one entry for each of the 256 control words in the current hyperframe. Each control transmit table entry contains a control word and an enable bit. As the frame is created, if a control word entry is enabled, and the global tx_ctrl_insert_en bit in the L1_CONFIG register is set, the IP core writes the appropriate control transmit table entry to the CPRI frame's control word.

The tx_control_insert bit of the CTRL_INDEX register enables or disables the transmission of the corresponding control transmit table entry in the CPRI frame. The tx_ctrl_insert_en bit of the L1_CONFIG register is the master enable: when it is set, the CPRI IP core writes all table entries with the tx_ctrl_insert bit set into the CPRI frame.

If you turn on Enable line bit rate auto-negotiation in the CPRI parameter editor, the auto-rate negotiation control and status interface is available. The CPRI IP provides support for dynamically changing the CPRI line bit rate, but requires that you implement user logic to control the auto-rate negotiation process. You control the process through the auto-rate negotiation control and status interface or the BIT_RATE_CONFIG register at offset 0x0C.

The CPRI Intel^® FPGA IP uses a dedicated clock, ex_delay_clk, to measure the delay through the RX and TX internal buffers to your desired precision. The extended delay process is identical for the two directions of flow through the IP core; the TX_EX_DELAY and RX_EX_DELAY registers hold the same information for the two directions.

The tx_msrm_period field of the TX_EX_DELAY register contains the value N, such that N clock periods of the ex_delay_clk clock are equal to some whole number M of cpri_clkout periods. For example, N may be a multiple of M, or the M/N frequency ratio may be slightly greater than 1, such as 64/63 or 128/127. The application layer specifies N to ensure the accuracy your application requires. The accuracy of the Tx buffer delay measurement is N/least_common_multiple(N,M) cpri_clkout periods.

Similarly, the rx_msrm_period field of the RX_EX_DELAY register contains the value N, such that N clock periods of the ex_delay_clk clock are equal to some whole number M of cpri_clkout periods.

If your application does not require this precision, drive the ex_delay_clk input port with the cpri_clkout signal. In this case, the M/N ratio is 1 because the frequencies are the same.

The tx_buf_delay field of the TX_DELAY register indicates the number of 32-bit words currently in the Tx buffer. After you program the tx_msrm_period field of the TX_EX_DELAY register with the value of N, the tx_ex_delay field of the TX_EX_DELAY register holds the current measured delay through the Tx buffer. The unit of measurement is cpri_clkout periods. The tx_ex_delay_valid field indicates that a new measurement has been written to the tx_ex_delay field since the previous register read. The following sections explain how you set and use these register values to derive the extended Tx delay measurement information.

M/N Ratio Selection

As your selected M/N ratio approaches 1, the accuracy provided by the extended delay measurement increases.

The CPRI Intel^® FPGA IP uses a dedicated clock, latency_sclk, to measure the delay through the RX and TX Intel^® Stratix^® 10 device hard FIFOs that are configured in the CPRI IP core.

The delay calculation process is identical for the two directions of flow through the IP core; the XCVR_TX_FIFO_DELAY and XCVR_RX_FIFO_DELAY registers hold the same information for the two directions.

To measure the current Tx delay through the hard FIFOs:

• Check the tx_pcs_fifo_delay_valid and tx_core_fifo_delay_valid fields of the XCVR_TX_FIFO_DELAY register at offset 0x84 to ensure the delay count values are updated.
• Add the delay count values in the tx_pcs_fifo_delay and tx_core_fifo_delay fields of the XCVR_TX_FIFO_DELAY register at offset 0x84.
• Multiply the result by the clock period of the latency_sclk.
• Divide this result by 128.

To measure the current Rx delay through the hard FIFOs:

• Check the rx_pcs_fifo_delay_valid and rx_core_fifo_delay_valid fields of the XCVR_RX_FIFO_DELAY register at offset 0x88 to ensure the delay count values are updated.
• Add the delay count values in the rx_pcs_fifo_delay and rx_core_fifo_delay fields of the XCVR_RX_FIFO_DELAY register at offset 0x88.
• Multiply the result by the clock period of the latency_sclk.
• Divide this result by 128.

The CPRI IP core complies with CPRI v7.0 Specification requirements R-19, R-20, R-20A, R-21, and R-21A.

The Rx path delay to the AUX interface is the sum of the following delays:

1. The link delay is the delay between the arrival of the first bit of a 10 ms radio frame on the CPRI Rx interface and the CPRI IP internal transmission of the radio frame pulse from the CPRI protocol interface receiver.
   1. Rx transceiver latency is a fixed delay through the deterministic latency path of the Rx transceiver. Its duration depends on the device family and the current CPRI line bit rate. This delay includes comma alignment and byte alignment within the transceiver.
   2. Fixed delay from the Rx transceiver to the Rx elastic buffer. This delay depends on the device family and the CPRI line bit rate.
      Note: In IP core variations that target an Intel^® Stratix^® 10 device, you must also add the delay through the Stratix 10 hard FIFOs in the Rx path.
   3. Delay through the clock synchronization FIFO, as well as the phase difference between the recovered receive clock and the core clock cpri_clkout. The "Extended Delay Measurement" section shows how to calculate the delay in the CPRI IP core Rx elastic buffer, which includes the phase difference delay.
   4. Byte alignment delay that can occur as data is shifted out of the receiver. This variable delay appears in the rx_byte_delay field of the RX_DELAY register. When the value in rx_byte_delay is non-zero, a byte alignment delay of one cpri_clkout cycle occurs in the Rx path.
   5. Variable delay introduced by the optional single-trip delay calibration feature in CPRI link slave IP cores.
   6. Variable delay introduced by the optional round-trip delay calibration feature in CPRI link master IP cores.
2. Delay from the CPRI low-level receiver block to the AUX interface. This delay depends on the device family and the CPRI line bit rate.

The Tx path delay from the AUX interface to the CPRI link is the sum of the following delays:

1. Fixed delay from the AUX interface though the CPRI low-level transmitter to the Tx elastic buffer. This delay depends on the device family and the current CPRI line bit rate.
2. Variable delay through the Tx elastic buffer, as well as the phase difference between the core clock cpri_clkout and the transceiver tx_clkout clock. The "Extended Delay Measurement" section shows how to calculate the delay in the CPRI Intel^® FPGA IP Tx elastic buffer, which includes the phase difference delay.
3. Variable Tx bitslip delay in CPRI RE slaves. Refer to "Tx Bitslip Delay."
4. Fixed delay from the Tx elastic buffer to the transceiver. This delay depends on the device family and the CPRI line bit rate.
   Note: In Intel^® FPGA IP core variations that target an Intel^® Stratix^® 10 device, you must also add the delay through the Stratix 10 hard FIFOs in the Tx path. Refer to "Extended Delay Measurement for Intel^® Stratix^® 10 Hard FIFOs" section.
5. Link delay through the transceiver.

CPRI v7.0 Specification requirements R-20 and R-21 address the round-trip delay. Requirement R-20 addresses the measurement without including the cable delay, and requirement R-21 is the requirement for the cable delay. Both requirements state that the variation must be no more than ±16.276 ns.

To monitor the round-trip delay, you must check periodically to confirm that the variation in measurements over time is small enough that the requirements are met.

If you turn on Enable single-trip delay calibration in the CPRI parameter editor, the CPRI IP and IOPLL and dynamic phase control unit (DPCU) blocks work together to adjust the delay through the RE slave Rx path in response to information about the delay through the REC or RE master Tx path.

The feature introduces the new delay to maintain a single-trip delay measurement as close as possible to the desired single-trip delay you provide to the CPRI IP. The application can also provide Tx path delay information that is appropriate for other use scenarios. For example, you might want to adjust the latency to the synchronization SAP to compensate for the IQ mapper requirements in your system. Refer to the Altera wiki Latency Formula and Calculation Example page.

The cal_cycle_delay and cal_step_delay fields of the DELAY_CAL_STD_CTRL2 register in the CPRI link slave hold the anticipated delay that you program. The cal_current_delay field of the DELAY_CAL_STD_STATUS register in the CPRI link slave holds the total actual variable delay measurement in the single trip from the synchronization SAP in the CPRI link master to the synchronization SAP in the current CPRI link slave. You can manually specify a consistency check whenever you want, or you can specify that the IP core should run a consistency check once every hyperframe.

If you turn on single-trip delay calibration by setting the cal_en bit in the DELAY_CAL_STD_CTRL1 register, the single-trip calibration feature is active. The user programs the cal_cycle_delay and cal_step_delay fields with the number of whole and fractional cpri_clkout cycles of single-trip variable delay that the system requires. After each consistency check, the CPRI slave IP core adjusts the Rx delay to compensate for mismatches between the programmed, required single-trip delay and the actual single-trip variable delay recorded in the cal_current_delay register field. The delay adjustment mechanism is dynamic phase shifting of the cpri_coreclk.

The slave IP core requires the master IP core measured Tx delay information to calculate the cal_current_delay value. The master IP core sends this information to its downlink slave by one of two possible mechanisms. You program the master IP core DELAY_CAL_STD4 register to specify whether the master sends this information in the incoming hyperframe (and at which location in the hyperframe) or the system writes it in the dedicated slave IP core DELAY_CAL_STD_CTRL5 register. You program the slave IP core DELAY_CAL_STD3 register to specify whether the slave receives this information in the incoming hyperframe (and at which location in the hyperframe) or the system writes it in the dedicated slave DELAY_CAL_STD_CTRL5 register. If both CPRI master and slave are CPRI IP cores, and the register values in the CPRI link master and slave do not match, the single-trip delay calibration does not function correctly. If the CPRI master is not a CPRI IP, the CPRI slave must receive the correct information in the programmed register or hyperframe location.

If you turn on Enable round-trip delay calibration in the CPRI parameter editor, the dynamic pipelining feature for round-trip delay calibration introduces a delay in the Rx path in an REC or RE master. This delay is introduced to the Rx path immediately following the Rx elastic buffer. The feature introduces the new delay to maintain a round-trip delay measurement as close as possible to the anticipated round-trip delay you provide to the CPRI IP core. The DELAY_CAL_RTD register holds the anticipated delay that you program, an enable bit you turn on to activate the feature, and a status field in which the CPRI IP core reports its relative success in maintaining the round-trip delay you requested.

The CPRI IP core is configured with a set of N=2 ^B pipelined registers in the Rx path, where B is the value you specified for Round-trip delay calibration FIFO depth in the parameter editor. If the two lowest order bits of the cal_rtd_ctrl field (bits [25:24] of the DELAY_CAL_RTD register) have the value of 2'b01, the auto-calibration feature is active. The user programs the cal_rtd_usr field with the expected number of cpri_clkout cycles of round-trip delay. The CPRI IP core adjusts the number of pipeline registers the data passes through (in contrast to the number of registers it bypasses) to compensate for mismatches between the desired round-trip delay programmed in the cal_rtd_usr field and the actual round-trip delay recorded in the ROUND_TRIP_DELAY register.

The cal_rtd_status field reports whether the CPRI IP core is successful in keeping the round-trip delay at the value you prescribed in the cal_rtd_usr field. If the two lowest order bits of the cal_rtd_ctrl field (bits [25:24] of the DELAY_CAL_RTD register) have the value of 2'b01, the value of the cal_rtd_status field should remain at 2'b10. If the value reaches 2'b11, indicating that the IP core is unable to meet the calibration requirement, you should reset the link or restart the calibration. You might also need to re-instantiate the IP core with a larger number of pipeline registers to support additional adjustment.

Initially, the number of pipeline registers the CPRI IP core uses is one half the total number N of available register stages, plus one. This initial setting allows the IP core to adjust the number up or down as required, and adds (N/2)+1 latency cycles to the RX path delay and the round-trip delay. For buffer depth N, the pipeline read pointer can move (N/2)-1 entries in either direction from its initial state.

In Case 1, the application writes the value of 60 in the cal_rtd_usr field of the DELAY_CAL_RTD register. When the CPRI IP core measures the actual round-trip delay and sets the round_trip_delay field of the ROUND_TRIP_DELAY register to the value of 61, the CPRI IP core responds by moving the read pointer to decrease the pipeline length, and therefore the measured round-trip delay value, by one cpri_clkout cycle. The adjustment achieves the desired effect: the measured round-trip delay value changes to 60.

In Case 2, the application writes the value of 62 in the cal_rtd_usr field of the DELAY_CAL_RTD register. When the CPRI IP core measures the actual round-trip delay and sets the round_trip_delay field of the ROUND_TRIP_DELAY register to the value of 61, the CPRI IP core responds by moving the read pointer to increase the pipeline length, and therefore the measured round-trip delay value, by one cpri_clkout cycle. The adjustment achieves the desired effect: the measured round-trip delay value changes to 60.

The CPRI Intel^® FPGA IP core reports the Rx bitslip through the word aligner in the rx_bitslip_out field of the XCVR_BITSLIP register, and compensates for the variable delay by adding a bitslip in the Tx path. The current size of this bitslip in bits is available in the tx_bitslip_in field of the XCVR_BITSLIP register. When you leave the tx_bitslip_en field at its default value of 0, this feature is active.

The Tx bitslip feature ensures stability in the round-trip delay through a CPRI RE core, but introduces a variable component in each of the Tx and Rx paths when considered independently. In CPRI IP cores in master clocking mode, the rx_bitslip_out field has the constant value of 0.

If you set the value of the tx_bitslip_en field to 1, you can override the current rx_bitslip_out value to control the Tx bitslip delay manually. Intel^® does not recommend implementing the manual override.

In CPRI IP variations that target an Arria V, Cyclone V, or Stratix V device, the Tx bitslip functionality is included in the Transceiver PHY Intel^® FPGA IP core that is generated with the CPRI Intel^® FPGA IP. These variations include the XCVR_BITSLIP register to support manual override of the Tx bitslip delay.

The total of the Tx bitslip delay and the word aligner bitslip delay in the transceiver receiver is added to the detailed round-trip delay calculation as part of the Tx and Rx transceiver delays. However, the total of these two bit values does not reach the duration of a single cpri_clkout cycle, nor does it reach the threshold of the CPRI specification R-20 and R-21 requirements. The bitslip delay is noticeable only with an oscilloscope.

This interface is available only if you turn on at least one of these parameters in the CPRI parameter editor:

• Enable line bit rate auto-negotiation
• Enable start-up sequence state machine

If you turn on Management (CSR) interface standard parameter in the CPRI parameter editor, Intel provides a dedicated Avalon^® -MM interface, called the transceiver reconfiguration interface, to access the Intel^® Arria^® 10 or Intel^® Stratix^® 10 transceiver registers. You access the Native PHY IP core registers through this dedicated interface and not through the IP core general purpose control and status interface. You can recalibrate the PHY through the Avalon-MM interface. You also need to enable this interface for the calibration of the TX PLL. This interface provides access to the hard PCS and the PMA registers of the PHY on the device.

The Avalon-MM interface implements a standard memory-mapped protocol. You can connect an Avalon master to this bus to access the registers of the embedded Native PHY IP core.

Refer to the About the E-Tile CPRI PHY chapter of the E-tile Hard IP User Guide for more information on the Avalon-MM reconfiguration interface.

This interface is available only in variations that target an Intel^® Arria^® 10 or Intel^® Stratix^® 10 or and Intel^® Agilex™ device, and only if you turn on at least one of these parameters in the CPRI IP core parameter editor:

• Enable line bit rate auto-negotiation
• Enable start-up sequence state machine
• Enable Native PHY Debug Master Endpoint(NPDME), transceiver capability, control and status registers access
• Enable single-trip delay calibration