The RapidIO Intel FPGA IP core complies with the RapidIO v2.1 specification and targets high-performance, multicomputing, high-bandwidth, and coprocessing I/O applications. The RapidIO Interconnect is an open standard developed by the RapidIO Trade Association. It is a high-performance packet-switched interconnect technology designed to pass data and control information between microprocessors, digital signal processors (DSPs), communications and network processors, system memories, and peripheral devices.

The RapidIO IP core has the following features:

• Compliant with RapidIO Interconnect Specification, Revision 2.1, August 2009, available from the RapidIO Trade Association website.
• Successfully passed RIOLAB’s Device Interoperability Level-3 (DIL-3) testing.
• Supports 8-bit or 16-bit device IDs.
• Supports incoming and outgoing multi-cast events.
• All RapidIO IP core variations include configuration of the high-speed transceivers on the device.
• All RapidIO IP core variations have a Transport layer.
• Physical layer features:
  • 1x/2x/4x serial with integrated transceivers in selected device families and support for external transceivers in older device families.
  • All four standard serial data rates supported: 1.25, 2.5, 3.125, and 5.0 gigabaud (Gbaud).
  • Receive/transmit packet buffering, flow control, error detection, packet assembly, and packet delineation.
  • Automatic freeing of resources used by acknowledged packets.
  • Automatic retransmission of retried packets.
  • Scheduling of transmission, based on priority.
  • Automatic recovery from fatal errors.
  • Optional automatic resetting of link partner after detection of fatal errors.
  • Support for synchronizing with link partner’s expected ackID after reset.
  • Full control over integrated transceiver parameters.
  • Configurable number of recovery attempts after link response time-out before declaring fatal error.
• Transport layer features:
  • Supports multiple Logical layer modules.
  • A round-robin outgoing scheduler chooses packets to transmit from various Logical layer modules.
• Logical layer features:
  • Generation and management of transaction IDs.
  • Automatic response generation and processing.
  • Request to response time-out checking.
  • Capability registers (CARs) and command and status registers (CSRs).
  • Direct register access, either remotely or locally.
  • Maintenance master and slave Logical layer modules.
  • Input/Output Avalon^® Memory-Mapped ( Avalon^® -MM) master and slave Logical layer modules with burst support.
  • Avalon^® streaming ( Avalon^® -ST) interface for custom implementation of message passing.
  • Doorbell module supporting 16 outstanding DOORBELL packets with time-out mechanism.
  • Support for preservation of transaction order between outgoing DOORBELL messages and I/O write requests.
  • New registers and interrupt indicate NWRITE_R transaction completion.
  • Support for preservation of transaction order between outgoing I/O read requests and I/O write requests from Avalon^® -MM interfaces.
• Platform Designer (Standard) support.
• IP functional simulation models for use in Intel^® -supported VHDL and Verilog HDL simulators.
• Support for Intel^® FPGA IP Evaluation Mode.

The following are the device support level definitions for Intel^® FPGA IP cores:

Before releasing a version of the RapidIO IP core, Intel^® runs comprehensive regression tests in the current version of the Intel^® Intel^® Quartus^® Prime software. These tests use the parameter editor and the Platform Designer (Standard) system integration tool to create the instance files. These files are tested in simulation and hardware to confirm functionality.

Intel^® also performs interoperability testing to verify the performance of the IP core and to ensure compatibility with ASSP devices.

The RapidIO IP core v9.0 successfully passed RIOLAB’s Device Interoperability Level-3 (DIL-3) testing in 2009.

The test suite contains testbenches that use the RapidIO bus functional model (BFM) from the RapidIO Trade Association to verify the functionality of the IP core.

The regression suite tests various functions, including the following functionality:

• Link initialization
• Packet format
• Packet priority
• Error handling
• Throughput
• Flow control

Constrained random techniques generate appropriate stimulus for the functional verification of the IP core. Functional coverage metrics measure the quality of the random stimulus, and ensure that all important features are verified.

Intel^® tests and verifies the RapidIO IP core in hardware for different platforms and environments.

The hardware tests cover 1x, 2x, and 4x variations running at 1.25, 2.5, 3.125, and 5.0 Gbaud, and processing the following traffic types:

• NREADs of various size payloads—4 bytes to 256 bytes
• NWRITEs of various size payloads—4 bytes to 256 bytes
• NWRITE_Rs of several different size packets
• SWRITEs
• Port-writes
• DOORBELL messages
• MAINTENANCE reads and writes

The hardware tests also cover the following control symbol types:

• Status
• Packet-accepted
• Packet-retry
• Packet-not-accepted
• Start-of-packet
• End-of-packet
• Link-request, Link-response
• Stomp
• Restart-from-retry
• Multicast-event

Intel^® performs interoperability tests on the RapidIO IP core, which certify that the RapidIO IP core is compatible with third-party RapidIO devices.

Intel^® performs interoperability testing with processors and switches from various manufacturers including:

• Texas Instruments Incorporated
• Integrated Device Technology, Inc. (IDT)

Testing of additional devices is an on-going process.

In addition, the RapidIO IP core v9.0 successfully passed RIOLAB’s Device Interoperability Level-3 (DIL-3) testing in 2009.

You can customize the RapidIO IP core to support a wide variety of applications.

When you generate the IP core you can choose whether or not to generate a simulation model. If you generate a simulation model, Intel^® provides a Verilog testbench customized for your IP core variation. If you specify a VHDL simulation model, you must use a mixed-language simulator to run the testbench, or create your own VHDL-only simulation environment.

The following sections provide generic instructions and information for Intel^® FPGA IP cores. It explains how to install, parameterize, simulate, and initialize the RapidIO IP core.

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

The Intel^® Quartus^® Prime software supports RTL- and gate-level design simulation of Intel^® FPGA IP cores in supported EDA simulators¹⁵. Simulation involves setting up your simulator working environment, compiling simulation model libraries, and running your simulation.

You can use the functional simulation model and the testbench or example design generated with your IP core for simulation. The functional simulation model and testbench files are generated in a project subdirectory. This directory may also include scripts to compile and run the testbench. For a complete list of models or libraries required to simulate your IP core, refer to the scripts generated with the testbench. You can use the Intel^® Quartus^® Prime NativeLink feature to automatically generate simulation files and scripts. NativeLink launches your preferred simulator from within the Intel^® Quartus^® Prime software.

When you integrate your IP core instance in your design, you must pay attention to some additional requirements. If you generate your IP core from the Platform Designer (Standard) IP catalog and build your design in Platform Designer (Standard), you can perform these steps in Platform Designer (Standard). If you generate your IP core directly from the Intel^® Quartus^® Prime IP catalog, you must implement these steps manually in your design.

For Arria II GX, Arria II GZ, Cyclone IV GX, and Stratix IV GX designs, ensure that you connect the calibration clock (cal_blk_clk) to a clock signal with the appropriate frequency range of 10 to 125 MHz. The cal_blk_clk ports on other components that use transceivers must be connected to the same clock signal.

RapidIO IP core variations that target an Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX devices include a reconfiguration controller block and do not require an external reconfiguration controller. All other RapidIO IP core variations require an external reconfiguration controller to function correctly in hardware.

For Arria II GX, Arria II GZ, Cyclone IV GX, and Stratix IV GX designs with high-speed transceivers, you must add a dynamic reconfiguration block (altgx_reconfig) to your design. You must connect it as specified in device handbook.This block supports offset cancellation. The design compiles without the altgx_reconfig block, but it cannot function correctly in hardware.

For Arria^® V, Cyclone^® V, and Stratix^® V designs, you must add a dynamic reconfiguration block (Transceiver Reconfiguration Controller) to your design, and connect it to the RapidIO IP core dynamic reconfiguration signals reconfig_fromgxb and reconfig_togxb. This block supports offset cancellation. The design compiles without the Transceiver Reconfiguration Controller, but it cannot function correctly in hardware.

For information about the number of reconfiguration interfaces you must configure in your Arria^® V, Cyclone^® V , or Stratix^® V dynamic reconfiguration block, refer to the descriptions of the reconfig_togxb and reconfig_fromgxb signals. An informational message in the RapidIO parameter editor tells you the required number of reconfiguration interfaces.

If you want to modify the high-speed transceiver settings in an Arria II GX, Arria II GZ, Cyclone IV GX, or Stratix IV GX variation, you must first generate the IP core and then edit the existing ALTGX megafunction in the Intel^® Quartus^® Prime software. Regenerating overwrites the changes.

The ALTGX megafunction that is generated in your RapidIO IP core is not accessible through Platform Designer (Standard). You must edit this megafunction using the Intel^® Quartus^® Prime software.

If your RapidIO IP core targets an Arria^® V, Cyclone^® V, or Stratix^® V device, Intel^® recommends you do not modify the default transceiver settings configured in the Custom PHY IP core instance generated with the RapidIO IP core.

If your RapidIO IP core targets Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX devices, Intel^® recommends you do not modify the default transceiver settings configured in the Intel^® Arria^® 10 Native PHY and the Intel^® Cyclone^® 10 GX Transceiver Native PHY IP cores.

For Arria II GX, Arria II GZ, and Stratix IV GX designs, after you generate the system, you must create assignments for the high-speed transceiver VCCH settings by following these instructions:

1. In the Intel^® Quartus^® Prime window, on the Assignments menu, click Assignment Editor.
2. In the <<new>> cell in the To column, type the top-level signal name for your RapidIO IP core instance td signal.
3. Double-click in the Assignment Name column and click I/O Standard.
4. Double-click in the Value column and click your standard (for example, 1.5-V PCML).
5. In the <<new>> row, repeat steps 2 to 4 for your RapidIO IP core instance rd signal.

RapidIO IP cores that target Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX devices require an external TX transceiver PLL to compile and to function correctly in hardware. You must instantiate and connect this IP core to the RapidIO IP core.

You can create an external transceiver PLL from the IP Catalog. Select the ATX PLL IP core or the fPLL IP core. In the PLL parameter editor, set the following parameter values:

• Set PLL output frequency to one half the value you select for the Baud rate parameter in the RapidIO parameter editor. The transceiver performs dual edge clocking, using both the rising and falling edges of the input clock from the PLL. Therefore, this PLL output frequency setting supports the customer-selected maximum data rate on the RapidIO link.
• Set PLL reference clock frequency to the value you select for the Reference clock frequency parameter in the RapidIO parameter editor.
• Turn on Include Master Clock Generation Block.
• Turn on Enable bonding clock output ports.
• Set PMA interface width to 20.

When you generate a RapidIO IP core, the Quartus Prime software also generates the HDL code for an ATX PLL, in the following file: <your_ip>/altera_rapidio_<version>/synth/<your_ip>_altera_rapidio_<version>_<random_string>.v/.vhd.¹⁶

However, the HDL code for the RapidIO IP core does not instantiate the ATX PLL. If you choose to use the ATX PLL provided with the RapidIO IP core, you must instantiate and connect the ATX PLL instance with the RapidIO IP core in user logic.

You must connect the TX PLL IP core to the RapidIO IP core according to the following rules.

To see how to configure and connect a TX PLL IP core to the other system components, such as the external reset controller, refer to the cleartext testbench files.

You must add a Transceiver PHY Reset Controller IP core to your design, and connect it to the RapidIO IP core reset signals. This block implements a reset sequence that resets the device transceivers correctly.

When you generate a RapidIO IP core that target Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX devices, the Intel^® Quartus^® Prime software generates the HDL code for the Transceiver PHY Reset Controller in the following file: <your_ip>/altera_rapidio_<version>/synth/<your_ip>_altera_rapidio_<version>_<random_string>.v/.vhd ¹⁷

To use the generated constraint files, follow these steps:

1. Open your project in the Intel^® Quartus^® Prime software.
2. On the View menu, point to Utility Windows and then click Tcl Console.
3. Source the generated constraint file by typing the following command at the Tcl console command prompt:

   source <variation_name>/synthesis/submodules/<instance_name >_constraints.tcl

4. Add the Rapid IO constraints to your project by typing the following command at the Tcl console command prompt:

   add_rio_constraints

   This command adds the necessary logic constraints to your Intel^® Quartus^® Prime project.

   If you rename any clocks in Platform Designer (Standard), you require the -ref_clk_name, -sys_clk_name, -phy_mgmt_clk, and -patch_sdc command-line options specified.

The script automatically constrains the system clocks and the reference clock based on the data rate chosen. For supported transceivers, Intel^® recommends that you adjust the reference clock frequency in the Physical Layer tab of the RapidIO parameter editor only. However, you can adjust the system clock frequency in the Tcl constraints script or the generated Synopsys Design Constraint File (.sdc).

The Tcl script assumes that virtual pins and I/O standards are connected to Intel^® -provided pin names. For user-defined pin names, you must edit the script after generation to ensure that the assignments are made properly.

The add_rio_constraints command has the following additional options that you can use:

add_rio_constraints [-no_compile] 
[-ref_clk_name <name>] [-sys_clk_name <name>] [-phy_mgmt_clk_name <name>] 
[-patch_sdc] [-help]

If you want to instantiate multiple RapidIO IP cores, a few additional steps are required. The following sections outline these steps.

When your design targets an Arria^® V, Cyclone^® V, or Stratix^® V device, the transceivers are configured with the Custom PHY IP core. When your design contains multiple RapidIO IP cores, the Intel^® Quartus^® Prime Fitter handles the merge of multiple Custom PHY IP cores in the same transceiver block automatically. To merge multiple Custom PHY IP cores in the same transceiver block, the Fitter requires that the phy_mgmt_clk_reset input signal for all of the merged IP cores be driven by the same source.

If you have different RapidIO IP cores in different transceiver blocks on your device, you may choose to include multiple Transceiver Reconfiguration Controllers in your design. However, you must ensure that the Transceiver Reconfiguration Controllers that you add to your design have the correct number of interfaces to control dynamic reconfiguration of all your RapidIO IP core transceivers. The correct total number of reconfiguration interfaces is the sum of the reconfiguration interfaces for each RapidIO IP core; the number of reconfiguration interfaces for each RapidIO IP core is the number of channels plus one. You must ensure that the reconfig_togxb and reconfig_fromgxb signals of an individual RapidIO IP core connect to a single Transceiver Reconfiguration Controller.

For example, if your design includes one 4× RapidIO IP core and three 1× RapidIO IP cores, the Transceiver Reconfiguration Controllers in your design must include eleven dynamic reconfiguration interfaces: five for the 4× RapidIO IP core, and two for each of the 1× RapidIO IP cores. The dynamic reconfiguration interfaces connected to a single RapidIO IP core must belong to the same Transceiver Reconfiguration Controller. In most cases, your design has only a single Transceiver Reconfiguration Controller, which has eleven dynamic reconfiguration interfaces. If you choose to use two Transceiver Reconfiguration Controllers, for example, to accommodate placement and timing constraints for your design, each of the RapidIO IP cores must connect to a single Transceiver Reconfiguration Controller.

In the following example, the Transceiver Reconfiguration Controller 0 has seven reconfiguration interfaces, and Transceiver Reconfiguration Controller 1 has four reconfiguration interfaces. Each sub-block shown in a Transceiver Reconfiguration Controller block represents a single reconfiguration interface. The example shows only one possible configuration for this combination of RapidIO IP cores; subject to the constraints described, you may choose a different configuration.

To enable the Intel^® Quartus^® Prime software to place distinct RapidIO IP cores in the same Arria^® V, Cyclone^® V, or Stratix^® V transceiver block, you must ensure that the phy_mgmt_clk input to each RapidIO IP core is driven by the same programming interface clock.

RapidIO IP cores that target an Arria II GX, Arria II GZ, Cyclone IV GX, or Stratix IV GX device all instantiate an ALTGX transceiver megafunction to configure the device transceivers. When your design contains multiple IP cores that use the ALTGX megafunction, you must ensure that the cal_blk_clk and gxb_powerdown input signals are connected properly.

You must ensure that the cal_blk_clk input to each RapidIO IP core (or any other megafunction or user logic that uses the ALTGX megafunction) is driven by the same calibration clock source.

When you merge multiple RapidIO IP cores in a single transceiver block, the same signal must drive gxb_powerdown to each of the RapidIO IP core variations and other megafunctions, IP cores, and user logic that use the ALTGX megafunction.

To successfully combine multiple high-speed transceiver channels in the same transceiver block, they must have the same dynamic reconfiguration setting. If two IP cores implement dynamic reconfiguration in the same transceiver block of an Arria II GX, Arria II GZ, Cyclone IV GX, or Stratix IV GX device, the parameters or characteristics that you want to control with the dynamic reconfiguration megafunction instance must be identical.

To support the dynamic reconfiguration block, turn on Analog controls on the Reconfiguration Settings tab in the transceiver parameter editor. Arria II GX, Arria II GZ, Cyclone IV GX, and Stratix IV GX device transceivers require a dynamic reconfiguration block, to support offset cancellation.

When you instantiate multiple RapidIO IP core instances in your design, you must modify the Synopsys Design Constraints File (.sdc) to repeat the create_generated_clock statements for each IP core instance. The statements must include the full name of the variation in the clock names.

If you do not do this, the source and destination clocks each have multiple matches; the rxclk and clk_div_by_2 filters match the relevant clocks in all of the IP core instances.

You customize the RapidIO IP core by specifying parameters in the RapidIO parameter editor, which you access from the IP Catalog.

This chapter describes the parameters and how they affect the behavior of the IP core.

In the RapidIO parameter editor, you use the following pages from the Parameter Settings tab to parameterize the RapidIO IP core:

• Physical Layer
• Transport and Maintenance
• I/O and Doorbell
• Capability Registers

The Physical Layer tab defines the characteristics of the Physical layer based on these categories: Device Options, Data Settings, Receive Priority Retry Threshold, and Transceiver Settings ¹⁸.

Receive priority retry threshold values are numbers of 64-byte buffers.

The Transport and Maintenance tab lets you enable and configure the Transport layer and Logical layer Input/Output Maintenance modules.

The RapidIO interface complies with revision 2.1 of the RapidIO serial interface standard described in the RapidIO Trade Association specifications. The protocol is divided into a three-layer hierarchy: Physical layer, Transport layer, and Logical layer.

The Avalon^® -MM master and slave interfaces execute transfers between the RapidIO IP core and the system interconnect. The system interconnect allows you to use the Platform Designer (Standard) Platform Designer (Standard) system integration tool to connect any master peripheral to any slave peripheral, without detailed knowledge of either the master or slave interface. The RapidIO IP core implements both Avalon^® -MM master and Avalon^® -MM slave interfaces.

The RapidIO protocol uses big endian byte ordering, whereas Avalon^® -MM interfaces use little endian byte ordering.

No byte- or bit-order swaps occur between the Avalon^® -MM protocol and RapidIO protocol, only byte- and bit-number changes. For example, RapidIO Byte0 is Avalon^® -MM Byte7, and for all values of i from 0 to 63, bit i of the RapidIO 64-bit double word[0:63] of payload is bit (63-i) of the Avalon^® -MM 64-bit double word[63:0].

In variations of the RapidIO IP core that have 32-bit wide Avalon^® -MM interfaces, the order in which the two 32-bit words in a double word appear on the Avalon^® -MM interface in a burst transaction, is inverted from the order in which they appear inside a RapidIO packet. The RapidIO 32-bit word with wdptr=0 is the most significant half of the double word at RapidIO address N, and the 32-bit word with wdptr=1 is the least significant 32-bit word at RapidIO address N. Therefore, in a burst transaction on the Avalon^® -MM interface, the 32-bit word with wdptr=0 corresponds to the Avalon^® -MM 32-bit word at address N+4 in the Avalon^® -MM address space, and must follow the 32-bit word with wdptr=1 which corresponds to the Avalon^® -MM 32-bit word at address N in the Avalon^® -MM address space. Thus, when a burst of two or more 32-bit Avalon^® -MM words is transported in RapidIO packets, the order of the pair of 32-bit words is inverted so that the most significant word of each pair is transmitted or received first in the RapidIO packet.

The Avalon^® -ST interface provides a standard, flexible, and modular protocol for data transfers from a source interface to a sink interface. The Avalon^® -ST interface protocol allows you to easily connect components together by supporting a direct connection to the Transport layer. The Avalon^® -ST interface is either 32 or 64 bits wide depending on the RapidIO lane width. This interface is available to create custom Logical layer functions like message passing.

In addition, if you turn on Enable transceiver dynamic reconfiguration for your RapidIO Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX variations, the IP core includes a reconfig_clk_chN input clock for each RapidIO lane N . Each reconfig_clk_chN clocks the Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX Native PHY dynamic reconfiguration interface for RapidIO lane N.

The RapidIO IP core supports ±100 ppm reference clock difference and can handle a maximum difference of ±200 ppm between the rxclk and txclk clocks.

The RapidIO IP core provides the following clock outputs from the transceiver:

• Transceiver receiver clock (recovered clock) (rxgxbclk)
• Recovered data clock (rxclk). Recovered clock that drives the receiver modules in the Physical layer.
• Transceiver transmit-side clock (txclk). Main clock for the transmitter modules in the Physical layer.

RapidIO IP core 2x and 4x variations are implemented in the transceiver TX bonded mode. All channels of a 2x or 4x variation, on any supported device, must reside in a single transceiver block.

To support this requirement in Arria II GX, Arria II GZ, Cyclone IV GX, and Stratix IV GX variations, the starting channel number for a 4x variation must be a multiple of four.

When you generate a custom IP core for variations other than Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX, the < variation name >_constraints.tcl script contains the required assignments. When you run the script, the constraints are applied to your project.

The reference clock signal drives the transceiver and the Physical layer. By default, this clock is called clk in the generated IP core. Platform Designer (Standard) allows you to export the clk signal with a name of your choice.

The reference clock, clk, is the incoming reference clock for the transceiver’s PLL. The frequency of the input clock must match the value you specify for the Reference clock frequency parameter. The transceiver PLL converts the reference clock frequency to the internal clock speed that supports the RapidIO IP core baud rate.

The RapidIO parameter editor lets you select one of the supported frequencies. The selection allows you to use an existing clock in your system as the reference clock for the RapidIO IP core.

The above figure shows how the transceiver uses the reference clock in variations other than Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX. In Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX variations, clk is the reference clock only for the RX PLL. The reference clock for the TX PLL is an input signal to the TX PLL IP core that you connect to the RapidIO IP core.

The PLL generates the high-speed transmit clock and the input clocks to the receiver high-speed deserializer clock and recovery unit (CRU). The CRU generates the recovered clock (rxclk) that drives the receiver logic.

For more information about the supported frequencies for the reference clock in your RapidIO variation, refer to the relevant device handbook.

In variations that target a device for which the transceivers are configured with the ALTGX megafunction, and not with a Transceiver PHY IP core, the transceiver's calibration-block clock is called cal_blk_clk.

In Arria^® V, Cyclone^® V, and Stratix^® V devices, the transceiver has an additional clock, phy_mgmt_clk, which clocks the software interface to the transceiver. In Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX devices, the transceiver has an input clock bus tx_bonding_clocks_ch N. These clocks should be driven by the external TX transceiver PLL. Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX variations also have an option interface, the Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX Native PHY dynamic reconfiguration interface, which includes a clock signal for each transceiver channel.

In systems created with Platform Designer (Standard), the system interconnect manages clock domain crossing if some of the components of the system run on a different clock. For optimal throughput, run all the components in the datapath on the same clock.

In addition, if you turn on Enable transceiver dynamic reconfiguration for your RapidIO Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX variations, the IP core includes reconfig_reset_chN input clock to reset the Intel^® Arria^® 10 or Intel^® Cyclone^® 10 GX Native PHY dynamic reconfiguration interface for each RapidIO lane N.

All reset signals can be asserted asynchronously to any clock. However, most reset signals must be deasserted synchronously to a specific clock.

The reset_n input signal can be asserted asynchronously, but must last at least one Avalon^® system clock period and be deasserted synchronously to the rising edge of the Avalon^® system clock.

In systems generated by Platform Designer (Standard), this circuit is generated automatically. However, if your RapidIO IP core variation is not generated by Platform Designer (Standard), you must implement logic to ensure the minimal hold time and synchronous deassertion of the reset_n input signal to the RapidIO IP core.

All RapidIO IP core variations other than Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX include a dedicated reset control module to handle the specific requirements of the internal transceiver module. Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX RapidIO IP core variations do not include a reset controller.

The reset control module is named riophy_reset. This riophy_reset module is defined in the riophy_reset.v clear-text Verilog HDL source file, and is instantiated inside the top-level module found in the clear text < variation name >_riophy_xcvr.v Verilog HDL source file.

The riophy_reset module controls all of the RapidIO IP core's internal reset signals. In particular, it generates the recommended reset sequence for the transceiver. The reset sequence and requirements vary among device families. For details, refer to the relevant device handbook.

The assertion of reset_n causes the whole IP core to reset. In Arria V, Cyclone^® V, and Stratix^® V devices, the requirement that phy_mgmt_clk_reset be asserted with reset_n ensures that the PHY IP core resets with the RapidIO IP core. While the module is held in reset, the Avalon^® -MM waitrequest outputs are driven high and all other outputs are driven low. When the module comes out of the reset state, all buffers are empty.

In Arria^® V, Cyclone^® V, and Stratix^® V devices, phy_mgmt_clk_reset must be asserted with reset_n. However, each signal is deasserted synchronously with its corresponding clock.

In systems generated by Platform Designer (Standard), this circuit is generated automatically. However, if your Arria^® V, Cyclone^® V, or Stratix^® V RapidIO IP core variation is not generated by Platform Designer (Standard), you must implement logic to ensure that reset_n and phy_mgmt_clk_reset are driven from the same source, and that each meets the minimal hold time and synchronous deassertion requirements.

To implement the reset sequence correctly for your RapidIO IP core configured on Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX devices, you must connect the tx_analogreset, tx_digitalreset, rx_analogreset, and rx_digitalreset signals to Transceiver PHY Reset Controller IP core. User logic must drive the following signals from a single reset source:

• RapidIO IP core reset_n (active low) input signal.
• Transceiver PHY Reset Controller reset (active high) input signal.
• TX PLL mcgb_rst (active high) input signal. However, Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX device requirements take precedence. Depending on the TX PLL configuration, your design might need to drive TX PLL mcgb_rst with different constraints.

Consistent with normal operation, following the IP core reset sequence, the Initialization state machine transitions to the SILENT state.

If two communicating RapidIO IP cores are reset one after the other, one of the IP cores may enter the Input Error Stopped state because the other IP core is in the SILENT state while this one is already initialized. The initialized IP core enters the Input Error Stopped state and subsequently recovers.

Two null padding bytes are appended to the packet if the resulting packet size is not an integer multiple of four bytes.²¹

In variations of the RapidIO IP core that include the Transport layer, the Transport layer removes the CRC after the 80^th byte (if present), but does not remove the final CRC nor the padding bytes. Therefore, a packet sent to the Avalon^® -ST pass-through receiver interface by the Transport layer is two or four bytes longer than the equivalent packet received by the Transport layer from the Avalon^® -ST pass-through interface. When processing the received packets, the Logical layer modules must ignore the final CRC and padding bytes (if present). In variations of the RapidIO IP core that include only the Physical layer, the 80^th byte CRC of a received packet is not removed.

The receiver uses the CCITT polynomial x¹⁶ + x¹² + x⁵ + 1 to check the 16-bit CRCs that cover all packet header bits (except the first 6 bits) and all data payload, and flags CRC and packet size errors.

The low-level transmitter block creates and transmits outgoing multicast-event control symbols. Each time the multicast_event_tx input signal changes value, this block inserts a multicast-event control symbol in the outgoing bit stream as soon as possible.

In 1.25, 2.5, and 3.125 Gbaud variations, the internal transmitters are not turned off while the initialization state machine is in the SILENT state. Instead, while in SILENT state, the transmitters send a continuous stream of K28.5 characters, all of the same disparity. This behavior causes the receiving end to declare numerous disparity errors and to detect a loss of lane_sync as intended by the specification.

In 5.0 Gbaud variations, the internal transmitters are turned off while the initialization state machine is in the SILENT state. This behavior also causes the link partner to detect the need to reinitialize the RapidIO link.

The transmitter transceiver is an embedded megafunction in the Arria II GX, Arria II GZ, Cyclone IV GX, or Stratix IV GX device, or an embedded Custom PHY IP core in the Arria^® V, Cyclone^® V, or Stratix^® V device, or an embedded Intel^® Arria^® 10 or Intel^® Cyclone^® 10 GX Native PHY IP core in the Intel^® Arria^® 10 or Intel^® Cyclone^® 10 GX devices.

On the receiver side, this block keeps track of the sequence of ackIDs and determines which packets are acknowledged and which packets to retry or drop. On the transmitter side, it keeps track of the sequence of ackIDs, tells the transmit buffer control block which packet to send, and sets the outgoing packets’ ackID. It also tells the transmit buffer control block when a packet has been acknowledged—and can therefore be discarded from the buffers.

The Physical layer protocol and flow control engine ensures that a maximum of 31 unacknowledged packets are transmitted, and that the ackIDs are used and acknowledged in sequential order.

If the receiver cannot accept a packet due to buffer congestion, a packet-retry control symbol with the packet’s ackID is sent to the transmitter. The sender then sends a restart-from-retry control symbol and retransmits all packets starting from the specified ackID. The RapidIO IP core supports receiver-controlled flow control in both directions.

If the receiver or the protocol and flow control block detects that an incoming packet or control symbol is corrupted or a link protocol violation has occurred, the protocol and flow control block enters an error recovery process. Link protocol violations include acknowledgement time-outs based on the timers the protocol and flow control block sets for every outgoing packet. In the case of a corrupted incoming packet or control symbol, and some link protocol violations, the block instructs the transmitter to send a packet-not-accepted symbol to the sender. A link-request link-response control symbol pair is then exchanged between the link partners and the sender then retransmits all packets starting from the ackID specified in the link-response control symbol. The transmitter attempts the link-request link-response control symbol pair exchange as many times as specified by the value N that you provided for the Link-request attempts parameter in the RapidIO parameter editor. If the protocol and control block times out awaiting the response to the Nth link-request control symbol, it declares a fatal error.

The Physical layer can retransmit any unacknowledged packet because it keeps a copy of each transmitted packet until the packet is acknowledged with a packet-accepted control symbol.

When a time-out occurs for an outgoing packet, the protocol and flow control block treats it as an unexpected acknowledge control symbol, and starts the recovery process. If a packet is retransmitted, the time-out counter is reset.

The Physical layer passes data to the Transport layer through a Physical layer receive buffer.. The data passes between the buffer and the Transport layer on a bus that is 32 bits wide in 1x variations and 64 bits wide in 2x and 4x variations.

The Physical layer receiver block accepts packet data from the low-level interface receiver module and stores the data in its receive buffer. The receive buffer provides clock decoupling between the Physical layer rxclk clock domain and the Transport layer sysclk clock domain.

You can specify a value of 4, 8, 16, or 32 KBytes to configure the receive buffer size in devices other than Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX. RapidIO Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX variations have a receive buffer size of 32 KBytes. The receiver buffer is partitioned into 64-byte blocks that are allocated from a free queue and returned to the free queue when no longer needed. The IP core provides the current number of 64-byte blocks in the free queue in the arxwlevel output signal.

As many as five 64-byte blocks may be required to store a packet.

The default threshold values are:

• Priority 2 Threshold = 10
• Priority 1 Threshold = 15
• Priority 0 Threshold = 20

You can specify other threshold values by turning off Auto-configured from receiver buffer size on the Physical Layer page in the RapidIO parameter editor.

The RapidIO parameter editor enforces the following constraints to ensure the threshold values increase monotonically by at least the maximum size of a packet (five buffers), as required by the deadlock prevention rules:

• Priority 2 Threshold > 9
• Priority 1 Threshold > Priority 2 Threshold + 4
• Priority 0 Threshold > Priority 1 Threshold + 4
• Priority 0 Threshold < Number of available buffers

The Physical layer accepts packet data from the Transport layer and stores it in the transmit buffer for the RapidIO link low-level interface transmitter. The data passes from the Transport layer to the Physical layer on a bus that is 32 bits wide in 1x variations and 64 bits wide in 2x and 4x variations.

The transmit buffer implements the following features:

• Provides clock decoupling between the Transport layer sysclk clock domain and the Physical layer txclk clock domain.
• Implements the RapidIO specification requirements for packet priority handling and deadlock avoidance, by configuring individual priority transmit and retransmit queues.

The transmit buffer is the main memory in which the packets are stored before they are transmitted. You can specify a value of 4, 8, 16, or 32 KBytes to configure the total memory space available for the transmit buffer in devices other than Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX. RapidIO Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX devices have a total transmit buffer size of 32 KBytes.

The transmit buffer space is partitioned into 64-byte blocks that are allocated from a free queue and returned to the free queue when no longer needed. The 64-byte blocks are used on a first-come, first-served basis by the individual transmit and retransmit queues.

The IP core provides the current number of 64-byte blocks in the free queue in the atxwlevel output signal. The transmit buffer also has an output signal, atxovf, which indicates a transmit buffer overflow condition.

To meet the RapidIO specification requirements for packet priority handling and deadlock avoidance, the Physical layer transmit buffer implements four transmit queues and four retransmit queues, one for each priority level.

As the Transport layer writes packets to the Physical layer, the Physical layer adds them to the end of the appropriate priority transmit queue. The transmitter always transmits the packet at the head of the highest priority non-empty queue. After the packet is transmitted, the Physical layer moves the packet from the transmit queue to the corresponding priority retransmit queue.

When a packet-accepted control symbol is received for a non-acknowledged transmitted packet, the transmit buffer block removes the accepted packet from its retransmit queue.

If a packet-retry control symbol is received, all of the packets in the retransmit queues are returned to the head of the corresponding transmit queues. The transmitter sends a restart-from-retry symbol, and the transmission resumes with the highest priority packet available, possibly not the same packet that was originally transmitted and retried. The Transport layer might have written higher priority packets to the Physical layer since the retried packet was originally transmitted. In that case, the higher priority packets are chosen automatically to be transmitted before lower priority packets are retransmitted.

The Physical layer protocol and flow control engine ensures that a maximum of 31 unacknowledged packets are transmitted, and that the ackIDs are used and acknowledged in ascending order.

As packet data is written to the transmit buffer, it is stored in 64-byte blocks. To minimize the latency introduced by the RapidIO IP core, transmission of the packet starts as soon as the first 64-byte block is available (or the end of the packet is reached, for packets shorter than 64 bytes). Should the next 64-byte block not be available by the time the first one has been completely transmitted, status control symbols are inserted in the middle of the packet instead of idles as the true idle sequence can be inserted only between packets and cannot be embedded inside a packet. Embedding these status control symbols along with other symbols, such as packet-accepted symbols, causes the transmission of the packet to be stretched in time.

The RapidIO specification requires that compensation sequences be inserted every 5,000 code groups or columns, and that they be inserted only between packets. The RapidIO IP core checks whether the 5,000 code group quota is approaching before the transmission of every packet and inserts a compensation sequence when the number of code groups or columns remaining before the required compensation sequence insertion falls below a specified threshold.

The threshold is chosen to allow time for the transmission of a packet of maximum legal size—276 bytes—even if it is stretched by the insertion of a significant number of embedded symbols. The threshold assumes a maximum of 37 embedded symbols, or 148 bytes, which is the number of status control symbols that are theoretically embedded if the traffic in the other direction consists of minimum-sized packets.

Despite these precautions, in some cases—for example when using an extremely slow Avalon^® system clock—the transmission of a packet can be stretched beyond the point where a RapidIO link protocol compensation sequence must be inserted. In this case, the packet transmission is aborted with a stomp control symbol, the compensation sequence is inserted, and normal transmission resumes.

When the receive side receives a stomp control symbol in the midst of a packet, it provides an error indication to the Transport layer. Because the packet was prematurely terminated at transmission, no traffic is lost and no protocol violation occurs.

The Transport layer is a required module of the RapidIO IP core. The Transport layer is intended for use in an endpoint processing element and must be used with at least one Logical layer module or the Avalon^® -ST pass-through interface.

You can optionally turn on the following two Transport layer parameters:

• Enable Avalon^® -ST pass-through interface—If you turn on this parameter, the Transport layer routes all unrecognized packets to the Avalon^® -ST pass-through interface.
• Disable Destination ID checking by default—If you turn on this parameter, request packets are considered recognized even if the destination ID does not match the value programmed in the base device ID CSR-Offset: 0x60. This feature enables the RapidIO IP core to process multi-cast transactions correctly. This parameter is turned on in RapidIO Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX variations.

  You can also turn on and turn off destination ID checking in the PROMISCUOUS_MODE field of the Rx Transport Control register at offset 0x10600.

The Transport layer module is divided into receiver and transmitter submodules.

On the receive side, the Transport layer module receives packets from the Physical layer. Packets travel through the Rx buffer, and any errored packet is eliminated. The Transport layer module routes the packets to one of the Logical layer modules or to the Avalon^® -ST pass-through interface based on the packet's destination ID, format type (ftype), and target transaction ID (targetTID) header fields. The destination ID matches only if the transport type (tt) field matches.

Packets with a destination ID different from the content of the relevant Base Device ID CSR ID field are routed to the Avalon^® -ST pass-through interface, unless you disable destination ID checking and the packet is a request packet with a tt field that matches the device ID width setting of the IP core. If you disable destination ID checking, the packet is a request packet with a supported ftype, and the tt field matches the device ID width setting of the current RapidIO IP core, the packet is routed to the appropriate Logical layer.

• Packets with unsupported ftype are routed to the Avalon^® -ST pass-through interface. Request packets with a supported ftype and a tt value that matches the RapidIO IP core’s device ID width, but an unsupported ttype are routed to the Logical layer supporting the ftype. The Logical layer module then performs the following tasks:
  • Sends an ERROR response for request packets that require a response.
  • Records an unsupported_transaction error in the Error Management extension registers.
• Packets that would be routed to the Avalon^® -ST pass-through interface, in the case that the RapidIO IP core does not implement an Avalon^® -ST pass-through interface, are dropped. In this case, the Transport layer module asserts the rx_packet_dropped signal.
• ftype=13 response packets are routed based on the value of their target transaction ID (targetTID) field. Each Logical layer module is assigned a range of transaction IDs. If the transaction ID of a received response packet is not within one of the ranges assigned to one of the enabled Logical layer modules, the packet is routed to the pass-through interface.

Packets marked as errored by the Physical layer (for example, packets with a CRC error or packets that were stomped) are filtered out and dropped from the stream of packets sent to the Logical layer modules or pass-through interface. In these cases, the rx_packet_dropped output signal is not asserted.

To limit the required storage, a single pool of transaction IDs is shared between all destination IDs, although the RapidIO specification allows for independent pools for each Source-Destination pair. Further simplifying the routing of incoming ftype=13 response packets to the appropriate Logical layer module, the Input-Output Avalon^® -MM slave module and the Doorbell Logical layer module are each assigned an exclusive range of transaction IDs that no other Logical layer module can use for transmitted request packets that expect an ftype=13 response packet.

Response packets of ftype=13 with transaction IDs outside the 64–143 range are routed to the Avalon^® -ST pass-through interface. Transaction IDs in the 0-63 range should not be used if the Maintenance Logical layer Avalon^® -MM slave module is instantiated because their use might cause the uniqueness of transaction ID rule to be violated.

If the Input-Output Avalon^® -MM slave module or the Doorbell Logical layer module is not instantiated, response packets in the corresponding Transaction IDs ranges for these layers are routed to the Avalon^® -ST pass-through interface.

On the transmit side, the Transport layer module uses a round-robin scheduler to select the Logical layer module to transmit packets. The Transport layer polls the various Logical layer modules to determine whether a packet is available. When a packet is available, the Transport layer transmits the whole packet, and then continues polling the next logical modules.

In a variation with a user-defined Logical layer connected to the Avalon^® -ST pass-through interface, you can abort the transmission of an errored packet by asserting the Avalon^® -ST pass-through interface gen_tx_error signal and gen_tx_endofpacket.

The Concentrator module provides access to the Avalon^® -MM slave interface and the RapidIO IP core register set. The interface supports simple reads and writes with variable latency. Accesses are to 32-bit words addressed by a 17-bit wide byte address. When accessed, the lower 2 bits of the address are ignored and assumed to be 0, which aligns the transactions to 4-byte words. The interface supports an interrupt line, sys_mnt_s_irq. When enabled, the following interrupts assert the sys_mnt_s_irq signal:

• Received port-write
• I/O read out of bounds
• I/O write out of bounds
• Invalid write
• Invalid write burstcount

A local host can access these registers using one of the following methods:

• Platform Designer (Standard) interconnect
• Custom logic

A local host can access the RapidIO registers from a Platform Designer (Standard) system. In this figure, a Nios II processor is part of the Platform Designer (Standard) system and is configured as an Avalon^® -MM master that accesses the RapidIO IP core registers through the System Maintenance Avalon^® -MM slave. Alternatively, you can implement custom logic to access the RapidIO registers.

A remote host can access the RapidIO registers by sending MAINTENANCE transactions targeted to this local RapidIO IP core. The Maintenance module processes MAINTENANCE transactions. If the transaction is a read or write, the operation is presented on the Maintenance Avalon^® -MM master interface. This interface must be routed to the System Maintenance Avalon^® -MM slave interface. This routing can be done with a Platform Designer (Standard) system shown by the routing to the Concentrator's system Maintenance Avalon^® -MM slave in the previous figure. If you do not use a Platform Designer (Standard) system, you can create custom logic as shown below.

When you create your custom RapidIO IP core variation in the parameter editor, you have the two or four choices for this module.

The Maintenance module can be segmented into the following four major submodules:

• Maintenance register
• Maintenance slave processor
• Maintenance master processor
• Port-write processor

The following interfaces are supported:

• Avalon^® -MM slave interface—User-exposed interface
• Avalon^® -MM master interface—User-exposed interface
• Tx interface—Internal interface used to communicate with the Transport layer
• Rx interface—Internal interface used to communicate with the Transport layer
• Register interface—Internal interface used to communicate with the Concentrator Module
  Figure 19. Maintenance Module Block Diagram

The Maintenance Register module implements all of the control and status registers required by this module to perform its functions. These registers are accessible through the System Maintenance Avalon^® -MM interface.

The Avalon^® -MM slave interface allows you to initiate a MAINTENANCE read or write operation. The Avalon^® -MM slave interface supports the following Avalon^® transfers:

• Single slave write transfer with variable wait-states
• Pipelined read transfers with variable latency

Reads and writes on the Avalon^® -MM slave interface are converted to RapidIO maintenance reads and writes. The following fields of a MAINTENANCE type packet are assigned by the Maintenance module:

• prio
• tt
• ftype is assigned a value of 4'b1000
• dest_id
• src_id
• ttype is assigned a value of 4'b0000 for reads and a value of 4'b0001 for writes
• rdsize/wrsize field is fixed at 4'b1000, because only 4-byte reads and writes are supported
• source_tid
• hop_count
• config_offset is generated by using the values programmed in the Tx Maintenance Address Translation Window registers.
• wdptr

Each window is enabled if the window enable (WEN) bit of the Tx Maintenance Window n Mask register is set. Each window is defined by the following registers:

• A base register: Tx Maintenance Mapping Window n Base
• A mask register: Tx Maintenance Mapping Window n Mask
• An offset register: Tx Maintenance Mapping Window n Offset
• A control register: Tx Maintenance Mapping Window n Control

For each defined and enabled window, the Avalon^® -MM address's least significant bits are masked out by the window mask and the resulting address is compared to the window base. If the addresses match, config_offset is created based on the following equation:

If (mnt_s_address[23:1] & mask[25:3]) == base[25:3]
then config_offset = (offset[23:3] & mask[23:3])|
 (mnt_s_address[21:1] & ~mask[23:3])

where:

• mnt_s_address[23:0] is the Avalon^® -MM slave interface address
• config_offset[20:0] is the outgoing RapidIO register double-word offset
• base[31:0] is the base address register
• mask[31:0] is the mask register
• offset[23:0] is the window offset register

If the address matches multiple windows, the lowest number window register set is used.

The following fields are inserted from the control register of the mapping window that matches.

• prio
• dest_id
• hop_count

The tt value is determined by your selection of device ID width at the time you create this RapidIO IP core variation. The source_tid is generated internally and the wdptr is assigned the negation of mnt_s_address[0].

For a MAINTENANCE Avalon^® -MM slave write, the value on the mnt_s_writedata[31:0] bus is inserted in the payload field of the MAINTENANCE write packet.

The Avalon^® -MM master interface supports the following Avalon^® transfers:

• Single master write transfer
• Pipelined master read transfers
  Figure 22. Signal Relationships for Four Write Transfers on the Maintenance Avalon^® -MM Master Interface
  Figure 23. Timing of a Read Request on the Maintenance Avalon^® -MM Master Interface

When a MAINTENANCE packet is received from a remote device, it is first processed by the Physical layer. After the Physical layer processes the packet, it is sent to the Transport layer. The Maintenance module receives the packet on the Rx interface. The Maintenance module extracts the fields of the packet header and uses them to compose the read or write transfer on the Maintenance Avalon^® -MM master interface. The following packet header fields are extracted:

• ttype
• rdsize/wrsize
• wdptr
• config_offset
• payload

The Maintenance module only supports single 32-bit word transfers, that is, rdsize and wrsize = 4’b1000; other values cause an error response packet to be sent.

The wdptr and config_offset values are used to generate the Avalon^® -MM address. The following expression is used to derive the address:

mnt_m_address = {rx_base, config_offset, wdptr, 2'b00}

where rx_base is the value programmed in the Rx Maintenance Mapping register at location 0x10088.

The payload is presented on the mnt_m_writedata[31:0] bus.

The port-write processor is controlled through the use of the receive and transmit port-write registers.

The other fields of the MAINTENANCE port-write packet are assigned as follows. The ftype is assigned a value of 4'b1000 and the ttype field is assigned a value of 4'b0100. The wdptr and wrsize fields of the transmitted packet are calculated from the size of the payload to be sent as defined by the size field of the Tx Port Write Control register. The source_tid and config_offset are reserved and set to zero.

The payload is written to a Tx Port Write Buffer starting at address 0x10210. This buffer can store a maximum of 64 bytes. The port-write processor starts the packet composition and transmission process after the PACKET_READY bit in the Tx Port Write Control register is set. The composed Maintenance port-write packet is sent to the Transport layer for transmission.

The wrsize and the wdptr determine the value of the PAYLOAD_SIZE field in the Rx Port Write Status register. The payload is written to the Rx Port Write Buffer starting at address 0x10260. A maximum of 64 bytes can be written. While the payload is written to the buffer, the PORT_WRITE_BUSY bit of the Rx Port Write Status register remains asserted. After the payload is completely written to the buffer, the interrupt signal sys_mnt_s_irq is asserted by the Concentrator on behalf of the Port Write Processor. The interrupt is asserted only if the RX_PACKET_STORED bit of the Maintenance Interrupt Enable register is set.

The Maintenance Interrupt register (at 0x10080) and the Maintenance Interrupt Enable register (at 0x10084), determine the error handling and reporting for MAINTENANCE packets.

The following errors can also occur for MAINTENANCE packets:

• A MAINTENANCE read or MAINTENANCE write request time-out occurs and a PKT_RSP_TIMEOUT interrupt (bit 24 of the Logical/Transport Layer Error Detect CSR) is generated if a response packet is not received within the time specified by the Port Response Time-Out Control register.
• The IO_ERROR_RSP (bit 31 of the Logical/Transport Layer Error Detect CSR) is set when an ERROR response is received for a transmitted MAINTENANCE packet.

This section describes the following Input/Output Logical layer modules:

• Input/Output Avalon^® -MM Master Module
• Input/Output Avalon^® -MM Slave Module

To maintain full-duplex bandwidth, two independent Avalon^® -MM interfaces are used in the I/O master module—one for read transactions and one for write transactions.

The I/O Avalon^® -MM master module can process a mix of as many as seven NREAD or NWRITE_R requests simultaneously. If the Transport layer module receives an NREAD or NWRITE_R request packet while seven requests are already pending in the I/O Avalon^® -MM master module, the new packet remains in the Transport layer until one of the pending transactions completes.

Address mapping or translation windows are used to map windows of 34-bit RapidIO addresses into windows of 32-bit Avalon^® -MM addresses.

Your variation must have at least one translation window. Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX variations have 16 address translation windows. You can change the values of the window defining registers at any time. You should disable a window before changing its window defining registers.

A window is enabled if the window enable (WEN) bit of the I/O Master Mapping Window n Mask register is set.

The number of mapping windows is defined by the Number of receive address translation windows parameter, which supports up to 16 sets of registers. Each set of registers supports one address mapping window.

For each window that is defined and enabled, the least significant bits of the incoming RapidIO address are masked out by the window mask and the resulting address is compared to the window base. If the addresses match, the Avalon^® -MM address is made of the least significant bits of the RapidIO address and the window offset using the following equation:

Let rio_addr[33:0] be the 34-bit RapidIO address, and address[31:0] the local Avalon^® -MM address.

Let base[31:0], mask[31:0] and offset[31:0] be the three window-defining registers. The least significant three bits of these registers are always 3’b000.

Starting from window 0, for the first window in which 
((rio_addr & {xamm, mask}) == ({xamb, base} & {xamm, mask}), 

where xamm and xamb are the Extended Address MSB fields of the I/O Master Mapping Window n Mask and the I/O Master Mapping Window n Base registers, respectively, 

let address[31:3] = (offset[31:3] & mask[31:3]) |
 (rio_addr[31:3] & ~mask[31:3])

The value of address[2] is zero for variations with 64-bit wide datapath Avalon^® -MM interfaces.

The value of address[2] is determined by the values of wdptr and rdsize or wrsize for variations with 32-bit wide datapath Avalon^® -MM interfaces.

The value of address[1:0] is always zero.

For each received NREAD or NWRITE_R request packet that does not match any enabled window, an ERROR response packet is returned.

RapidIO Packet Data wdptr and Data Size Encoding in Avalon^® -MM Transactions

The RapidIO IP core converts RapidIO packets to Avalon^® -MM transactions. The RapidIO packets’ read size, write size, and word pointer fields are translated to the Avalon^® -MM burst count and byteenable values.

Below figures shows the timing dependencies. Both transaction requests are received on the RapidIO link and sent on to the Logical layer Avalon^® -MM master module. If the RapidIO link partner is also an Intel^® RapidIO IP core, the input/output avalon-MMslave module timing diagrams show the same transactions as they originate on the Avalon^® -MM interface of the RapidIO link partner’s Input/Output Avalon^® -MM slave module.

To maintain full-duplex bandwidth, two independent Avalon^® -MM interfaces are used in the I/O slave module—one for read transactions and one for write transactions.

When the read Avalon^® -MM slave creates a read request packet, the request is sent to both the Pending Reads buffer to wait for the corresponding response packet, and to the read request transmit buffer to be sent to the remote processing element through the Transport layer. When the read response is received, the packet’s payload is used to complete the read transaction on the read Avalon^® -MM slave.

For a read operation, one of the following responses occurs:

• The read was successful. After a response packet is received, the read response and data are passed from the Pending Reads buffer back through the read Avalon^® -MM slave interface.
• The remote processing element is busy and the request packet is resent.
• An error or time-out occurs, which causes io_s_rd_readerror to be asserted on the read Avalon^® -MM slave interface and some information to be captured in the Error Management Extension registers.

How the write request is handled depends on the type of write request sent. For example, unlike a read request, not all write requests send tracking information to the Pending Writes buffer. NWRITE and SWRITE requests do not send write tracking information to the Pending Writes buffer. Only write requests such as NWRITE_R, that require a response, are sent to both the Pending Writes and Transmit buffers. Write requests are sent through the Transport and Physical layers to the remote processing element.

An outbound request that requires a response—an NWRITE_R or an NREAD transaction—is assigned a time-out value that is the sum of the VALUE field of the Port Response Time-Out Control register and the current value of a free-running counter. When the counter reaches the time-out value, if the transaction has not yet received a response, the transaction times out.

If you turn off the I/O read and write order preservation option in the RapidIO parameter editor, if a read and a write request arrive simultaneously or one clock cycle apart on the Avalon^® -MM interfaces, the order of transaction completion is undefined. However, if you turn on the I/O read and write order preservation option, the read requests buffer and the write requests buffer shown in the figure are combined, to preserve the relative order of read and write requests that appear on the Avalon^® -MM interface. In Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX variations, the read and write request buffers are combined.

In addition, the NWRITE_RS_COMPLETED bit of the Input/Output Slave Interrupt Enable register controls a maskable interrupt in the Input/Output Slave Interrupt register that can be generated when the final pending NWRITE_R transaction completes.

You can use these registers to determine if a specific I/O write transaction has been issued or if a response has been received for any or all issued NWRITE_R requests.

A base register, a mask register, and an offset register define a window. The control register stores information used to prepare the packet header on the RapidIO side of the transaction, including the target device’s destination ID, the request packet's priority, and selects between the three available write request packet types: NWRITE, NWRITE_R and SWRITE.

You can change the values of the window-defining registers at any time, even after sending a request packet and before receiving its response packet. However, you should disable a window before changing its window-defining registers. A window is enabled if the window enable (WEN) bit of the Input/Output Slave Mapping Window n Mask register is set, where n is the number of the transmit address translation window.

The number of mapping windows is defined by the parameter Number of transmit address translation windows; up to 16 windows are supported. Each set of registers supports one external host or entity at a time. Your variation must have at least one translation window. Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX variations have 16 transmit address translation windows.

For each window that is enabled, the least significant bits of the Avalon^® -MM address are masked out by the window mask and the resulting address is compared to the window base. If the addresses match, the RapidIO address in the outgoing request packet is made of the least significant bits of the Avalon^® -MM address and the window offset using the following equation:

Let avalon_address[31:0] be the 32-bit Avalon^® -MM address, and rio_addr[33:0] be the RapidIO address, in which rio_addr[33:32] is the 2-bit wide xamsbs field, rio_addr[31:3] is the 29-bit wide address field in the packet, and rio_addr[2:0] is implicitly defined by wdptr and rdsize or wrsize.

Let base[31:0], mask[31:0], and offset[31:0] be the values defined by the three corresponding window-defining registers. The least significant 3 bits of base, mask, and offset are fixed at 3’b000 regardless of the content of the window-defining registers.

Let xamo be the Extended Address MSBits Offset field in the Input/Output Slave Window n Offset register (the two least significant bits of the register).

Starting with window 0, find the first window for which

(({address,Nb’0} & mask) == (base & mask))

where N is 2 in 1x variations and 3 in 2x and 4x variations.

Let 
rio_addr [33:3] = {xamo, (offset [31:3] & mask [31:3]) |
 ({avalon_address,Nb’0} [31:3]])}

If the address matches multiple windows, the lowest number window register set is used. The Avalon^® -MM slave interface’s burstcount and byteenable signals determine the values of wdptr and rdsize or wrsize.

The priority and DESTINATION_ID fields are inserted from the control register.

If the address does not match any window the following events occur:

• An interrupt bit, either WRITE_OUT_OF_BOUNDS or READ_OUT_OF_BOUNDS in the Input/Output Slave Interrupt register, is set.
• The interrupt signal sys_mnt_s_irq is asserted if enabled by the corresponding bit in the Input/Output Slave Interrupt Enable register.
• The COMPLETED_OR_CANCELLED_WRITES field of the Input/Output Slave RapidIO Write Requests register is incremented if the transaction is a write request.

An interrupt is cleared by writing 1 to the interrupt register’s corresponding bit location.

The two most significant bits of the Avalon^® -MM address are used to differentiate between the processing endpoints. Figures in the following sections show the address translation implemented for each window. Each figure shows the value for the destination ID of the control register for one window.

The RapidIO IP core converts Avalon^® -MM transactions to RapidIO packets. The Avalon^® -MM burst count, byteenable, and, in 32-bit variations, address bit 2 values are translated to the RapidIO packets' read size, write size, and word pointer fields.

The following table lists the allowed burst count and byteenable combinations for RapidIO IP core variations with a 64-bit Avalon^® -MM interface. Avalon^® -MM value combinations not listed flag interrupts in the RapidIO IP core.

The following figures show the timing dependencies on the Avalon^® -MM slave interface for an outgoing RapidIO NREAD request and the timing dependencies on the Avalon^® -MM slave interface for an outgoing NWRITE transaction, respectively. Both transaction requests originate on the Avalon^® -MM interface of the slave module. The timing diagrams in “Input/Output Avalon^® -MM Master Module Timing Diagrams” show the same transactions after they are transmitted on the RapidIO link and received by an Intel^® RapidIO IP core link partner, when they are sent out as Avalon^® -MM requests by an Input/Output Avalon^® -MM master module in the partner RapidIO IP core.

The Doorbell module provides support for Type 10 packet format (DOORBELL class) transactions, allowing users to send and receive short software-defined messages to and from other processing elements connected to the RapidIO interface.

The RapidIO block diagram shows how the Doorbell module is connected to the Transport layer module. In a typical application the Doorbell module’s Avalon^® -MM slave interface is connected to the system interconnect fabric, allowing an Avalon^® -MM master to communicate with RapidIO devices by sending and receiving DOORBELL messages.

When you configure the RapidIO IP core, you can enable or disable the DOORBELL operation feature, depending on your application requirements. If you do not need the DOORBELL feature, disabling it reduces device resource usage. If you enable the feature, a 32–bit Avalon^® -MM slave port is created that allows the RapidIO IP core to receive, generate, or both receive and generate RapidIO DOORBELL messages.

The Doorbell module contains the following logic blocks:

• Register and FIFO interface that allows an external Avalon^® -MM master to access the Doorbell module’s internal registers and FIFO buffers.
• Tx output FIFO that stores the outbound DOORBELL and response packets waiting for transmission to the Transport layer module.
• Acknowledge RAM that temporarily stores the transmitted DOORBELL packets pending responses to the packets from the target RapidIO device.
• Tx time-out logic that checks the expiration time for each outbound Tx DOORBELL packet that is sent.
• Rx control that processes DOORBELL packets received from the Transport layer module. Received packets include the following packet types:
  • Rx DOORBELL request.
  • Rx response DONE to a successfully transmitted DOORBELL packet.
  • Rx response RETRY to a transmitted DOORBELL message.
  • Rx response ERROR to a transmitted DOORBELL message.
• Rx FIFO that stores the received DOORBELL messages until they are read by an external Avalon^® -MM master device.
• Tx FIFO that stores DOORBELL messages that are waiting to be transmitted.
• Tx staging FIFO that stores DOORBELL messages until they can be passed to the Tx FIFO. The staging FIFO is present only if you select Prevent doorbell messages from passing write transactions in the RapidIO parameter editor. Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX variations have a staging FIFO and prevent DOORBELL messages from passing write transactions.
• Tx completion FIFO that stores the transmitted DOORBELL messages that have received responses. This FIFO also stores timed out Tx DOORBELL requests.
• Error Management module that reports detected errors, including the following errors:
  • Unexpected response (a response packet was received, but its TransactionID does not match any pending request that is waiting for a response).
  • Request time-out (an outbound DOORBELL request did not receive a response from the target device).

If the module has a Tx staging FIFO, each DOORBELL message from the Avalon^® -MM interface is kept in the Tx staging FIFO until all I/O write transactions that started on the write Avalon^® -MM slave interface before this DOORBELL message arrived on the Doorbell module Avalon^® -MM interface have been transmitted to the Transport layer. An I/O write transaction is considered to have started before a DOORBELL transaction if the io_s_wr_write and io_s_wr_chipselect signals are asserted while the io_s_wr_waitrequest signal is not asserted, on a cycle preceding the cycle on which the drbell_s_write and drbell_s_chipselect signals are asserted for writing to the Tx Doorbell register while the drbell_s_waitrequest signal is not asserted.

If you do not select Prevent doorbell messages from passing write transactions in the RapidIO parameter editor, the Doorbell Tx staging FIFO is not configured in the RapidIO IP core.

After a write to the Tx Doorbell register is detected, internal control logic generates and sends a Type 10 packet based on the information in the Tx Doorbell and Tx Doorbell Control registers. A copy of the outbound DOORBELL packet is stored in the Acknowledge RAM.

When the response to an outbound DOORBELL message is received, the corresponding copy of the outbound message is written to the Tx Doorbell Completion FIFO (if enabled), and an interrupt is generated (if enabled) on the Avalon^® -MM slave interface by asserting the drbell_s_irq signal of the Doorbell module. The ERROR_CODE field in the Tx Doorbell Completion Status register indicates successful or error completion.

The corresponding interrupt status bit is set each time a valid response packet is received, and resets itself when the Tx Completion FIFO is empty. Software optionally can clear the interrupt status bit by writing a 1 to this specific bit location of the Doorbell Interrupt Status register.

Upon detecting the interrupt, software can fetch the completed message and determine its status by reading the Tx Doorbell Completion register and Tx Doorbell Completion Status register, respectively.

An outbound DOORBELL message is assigned a time-out value based on the VALUE field of the Port Response Time-Out Control register and a free-running counter. When the counter reaches the time-out value, if the DOORBELL transaction has not yet received a response, the transaction times out.

An outbound message that times out before its response is received is treated in the same manner as an outbound message that receives an error response: if enabled, an interrupt is generated by the Error Management module by asserting the sys_mnt_s_irq signal, and the ERROR_CODE field in the Tx Doorbell Completion Status register is set to indicate the error.

If the interrupt is not enabled, the Avalon^® -MM master must periodically poll the Tx Doorbell Completion Status register to check for available completed messages before retrieving them from the Tx Completion FIFO.

DOORBELL request packets for which RETRY responses are received are resent by hardware automatically. No retry limit is imposed on outbound DOORBELL messages.

DOORBELL request packets received from the Transport layer module are stored in an internal buffer, and an interrupt is generated on the DOORBELL Avalon^® -MM slave interface, if the interrupt is enabled.

The corresponding interrupt status bit is set every time a DOORBELL request packet is received and resets itself when the Rx FIFO is empty. Software can clear the interrupt status bit by writing a 1 to this specific bit location of the Doorbell Interrupt Status register.

An interrupt is generated when a valid response packet is received and when a request packet is received. Therefore, when the interrupt is generated, you must check the Doorbell Interrupt Status register to determine the type of event that triggered the interrupt.

If the interrupt is not enabled, the external Avalon^® -MM master must periodically poll the Rx Doorbell Status register to check the number of available messages before retrieving them from the Rx doorbell buffer.

Appropriate Type 13 response packets are generated internally and sent for all the received DOORBELL messages. A response with DONE status is generated when the received DOORBELL packet can be processed immediately. A response with RETRY status is generated to defer processing the received message when the internal hardware is busy, for example when the Rx doorbell buffer is full.

The Avalon^® -ST pass-through interface is an optional interface that is generated when you select the Avalon^® -ST pass-through interface in the Transport and Maintenance page of the RapidIO parameter editor. If destination ID checking is enabled, all packets received by the Transport layer whose destination ID does not match this RapidIO IP core’s base device ID or whose ftype is not supported by this IP core’s variation are routed to the Rx Avalon^® -ST pass-through interface. If you disable destination ID checking, request packets are instead routed to the Rx Avalon^® -ST pass-through interface only if they have ftypes that are not supported by this IP core’s variation. After packets are routed to the Rx Avalon^® -ST pass-through interface, they can be further examined by a local processor or parsed and processed by a custom user function.

The following applications can use the Avalon^® -ST pass-through interface:

• User implementation of a RapidIO function not supported by this IP core (for example, data message passing)
• User implementation of a custom function not specified by the RapidIO protocol, but which may be useful for the system application

This section contains two examples, one receiving and the other transmitting a packet through the Avalon^® -ST pass-through interface. The RapidIO IP core variation in the receiving example uses 8-bit device ID, and the variation in the transmitting example uses 16-bit device ID.

Packet Routed Through Rx Port on Avalon^® -ST Pass-Through Interface

The following example of a packet routed to the receiver Avalon^® -ST pass-through interface is for a variation that only has the Maintenance module and the Avalon^® -ST pass-through interface enabled. A packet received on the RapidIO interface with an ftype that does not indicate a MAINTENANCE transaction is routed to the receiver port of the Avalon^® -ST pass-through interface.

In cycle 0, the user logic indicates to the RapidIO IP core that it is ready to receive a packet transfer by asserting gen_rx_ready. In cycle 1, the IP core asserts gen_rx_valid and gen_rx_startofpacket. During this cycle, gen_rx_size is valid and indicates that five cycles are required to transfer the packet.

Bits [31:0] of the gen_rx_data bus are ignored in cycle 5 as the gen_rx_empty signals indicates that 4 bytes are not used in the end-of-packet word. In the case of a RapidIO IP core variation with 16-bit device ID, the value of gen_rx_empty would be 2, and only bits [15:0] of the gen_rx_data bus would be ignored in cycle 5.

NREAD Example Using Tx Port on Avalon^® -ST Pass-Through Interface

The next example shows the response to an NREAD transaction in a RapidIO IP core variation with 16-bit device ID. The response is presented on the Tx port of the Avalon^® -ST pass-through interface. The transaction diagram below shows the packet presented on this interface. The values captured on a rising clock edge are those shown in the previous clock cycle, because values change after the rising clock edge.

The figure shows a response to a 32-byte NREAD request in a RapidIO IP core with 16-bit device ID. The following table shows the composition of the fields in the RapidIO packet header and the payload as they correspond to each clock cycle. The gen_tx_empty bits indicate a value of 0, because all bytes of the last word are read.