RapidIO II Intel FPGA IP User Guide

RSS

UG-01116 | 2020.09.28

Version Information

Updated for:
Intel® Quartus® Prime Design Suite 20.3

Product Discontinuance Notification

Attention:

The RapidIO II Intel FPGA IP is part of a product obsolescence and support discontinuation schedule.

For the schedule, refer to the Product Discontinuation Notice PDN2025.

For new designs, Intel recommends that you use other IPs with equivalent functions. To see a list of available IPs, refer to the Intel^® FPGA IP Portfolio web page.

1. About the RapidIO II Intel FPGA IP

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 II Intel^® FPGA IP complies with the RapidIO v2.2 specification and targets high-performance, multi-computing, high-bandwidth, and co-processing I/O applications.

Figure 1. Typical RapidIO Application

1.1. Features

The RapidIO II IP core has the following features:

Compliant with RapidIO Interconnect Specification, Revision 2.2, June 2011, available from the RapidIO Trade Association website.
Supports 8-bit or 16-bit device IDs.
Supports incoming and outgoing multi-cast events.
Provides a 128-bit wide Avalon^® Streaming ( Avalon^® -ST) pass-through interface for fully integrated implementation of custom user logic.
Physical layer features:
- 1x / 2x / 4x serial with integrated transceivers.
- Fallback to 1x from 4x and 2x modes.
- Fallback to 2x from 4x mode.
- All five standard serial data rates supported: 1.25, 2.5, 3.125, 5.0, and 6.25 Gbaud (gigabaud).
- Long control symbol.
- IDLE2 idle sequence
  - Extraction and insertion of command and status (CS) field.
  - Support for software control of local and link-partner transmitter emphasis.
  - Insertion of clock compensation sequences.
- Receive/transmit packet buffering, scrambling/descrambling, flow control, error detection and recovery, packet assembly, and packet delineation.
- Automatic freeing of resources used by acknowledged packets.
- Automatic retransmission of retried packets.
- Scheduling of transmission, based on priority.
- Software support for ackID synchronization.
- Virtual channel (VC) 0 support.
- Reliable traffic (RT) support.
- Critical request flow (CRF) support.
Transport layer features:
- Supports multiple Logical layer modules.
- Supports an Avalon^® -ST pass-through interface for custom implementation of capabilities such as data streaming and message passing.
- A round-robin, priority-supporting 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.
- Response Request Timeout checking.
- Capability registers (CARs), command and status registers (CSRs), and Error Management Extensions registers.
- 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 128-bit wide datapath and burst support.
- Doorbell module supporting 16 outstanding DOORBELL packets with time-out mechanism.
- Optional preservation of transaction order between outgoing DOORBELL messages and I/O write requests.
- Registers and interrupt indicate NWRITE_R transaction completion.
- Preservation of transaction order between outgoing I/O read requests and I/O write requests from Avalon^® -MM interfaces.
Cycle-accurate simulation models for use in Intel^® -supported VHDL and Verilog HDL simulators.
IEEE-encrypted HDL simulation models for improved simulation efficiency.
Support for Intel^® FPGA IP Evaluation Mode.

1.1.1. Supported Transactions

The RapidIO II IP core supports the following RapidIO transactions:

NREAD request and response
NWRITE request
NWRITE_R request and response
SWRITE request
MAINTENANCE read request and response
MAINTENANCE write request and response
DOORBELL request and response

1.2. Device Family Support

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

Advance support - The IP core is available for simulation and compilation for this device family. Timing models include initial engineering estimates of delays based on early post-layout information. The timing models are subject to change as silicon testing improves the correlation between the actual silicon and the timing models. You can use this IP core for system architecture and resource utilization studies, simulation, pinout, system latency assessments, basic timing assessments (pipeline budgeting), and I/O transfer strategy (data-path width, burst depth, I/O standards tradeoffs).
Preliminary support - The IP core is verified with preliminary timing models for this device family. The IP core meets all functional requirements, but might still be undergoing timing analysis for the device family. It can be used in production designs with caution.
Final support - The IP core is verified with final timing models for this device family. The IP core meets all functional and timing requirements for the device family and can be used in production designs.

Table 1. Device Family Support
Device Family	Support Level
Intel^® Cyclone^® 10 GX	Advance
Intel^® Stratix^® 10	Advance
Intel^® Arria^® 10	Final
Arria^® V GX, GT, SX, and ST	Final
Arria^® V GZ	Final
Cyclone^® V	Final
Stratix^® V	Final
Other device families	No support

1.3. IP Core Verification

Before releasing a publicly available version of the RapidIO II IP core, Intel^® runs a comprehensive verification suite in the current version of the Intel^® Quartus^® Prime software. These tests use standalone methods and the Platform Designer system integration tool to create the instance files. These files are tested in simulation and hardware to confirm functionality. Intel^® tests and verifies the RapidIO II IP core in hardware for different platforms and environments.

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

1.3.1. Simulation Testing

The test suite contains testbenches that use the Cadence Serial RapidIO Verification IP (VIP), the Cadence Compliance Management System (CMS) implementation of the RapidIO Trade Association interoperability checklist, and the RapidIO bus functional model (BFM) from the RapidIO Trade Association to verify the functionality of the IP core.

The test suite confirms 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 and code coverage metrics measure the quality of the random stimulus, and ensure that all important features are verified.

1.3.2. Hardware Testing

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

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

NREADs of various payload sizes
NWRITEs of various payload sizes
NWRITE_Rs of various payload sizes
SWRITEs of various payload sizes
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 and Link-response
Stomp
Restart-from-retry
Multicast-event

1.3.3. Interoperability Testing

Intel^® performs interoperability tests on the RapidIO II IP core, which certify that the RapidIO II 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)

Intel^® has performed interoperability tests with the IDT CPS-1848 and IDT CPS-1616 switches. Testing of additional devices is an on-going process.

1.4. Performance and Resource Utilization

This section shows IP core variation sizes in the different device families.

Minimal variation:
- Physical layer
- Transport layer
- Avalon^® -ST pass-through interface
Full-featured variation:
- Physical layer
- Transport layer
- Maintenance module
- Doorbell module
- Input/Output Avalon^® -MM master
- Input/Output Avalon^® -MM slave
- Error Management Registers block

All variations are configured with the following parameter settings:

Transceiver reference clock frequency of 156.25 MHz.
The maximum RapidIO II baud rate supported by the device.
Support 1x, 2x, and 4x modes of operation.

Table 2. RapidIO II IP Core FPGA Resource UtilizationThe listed results are obtained using the Intel^® Quartus^® Prime software for the following devices:

Intel^® Cyclone^® 10 GX (10CX220YU484I6G) - Intel^® Quartus^® Prime Pro Edition 18.0

Intel^® Stratix^® 10 L-Tile (1SG280LN3F43E3VG) - Intel^® Quartus^® Prime Pro Edition 17.1

Intel^® Stratix^® 10 H-Tile (1SG280HN3F43E3VG) - Intel^® Quartus^® Prime Pro Edition 17.1

Intel^® Arria^® 10 (10AX115U3F45E2LG) - Intel^® Quartus^® Prime Pro Edition 17.1

Arria^® V (5AGXFB7K4F40C4) - Intel^® Quartus^® Prime Standard Edition 17.0

Cyclone^® V (5CGXBC7C6F23C7) - Intel^® Quartus^® Prime Standard Edition 17.0

Stratix^® V (5SGXMA5N3F45C4) - Intel^® Quartus^® Prime Standard Edition 17.0

The numbers of ALMs, primary logic registers, and secondary logic registers are rounded up to the nearest 100.
Device	Parameters		ALMs	Registers		Memory Blocks (M10K or M20K)¹
Device	Variation	Baud Rate (Gbaud)	ALMs	Primary	Secondary	Memory Blocks (M10K or M20K)¹
Intel^® Cyclone^® 10 GX	Minimal	6.25	11400	10400	1300	28
Intel^® Cyclone^® 10 GX	Full-featured	6.25	24300	27800	3700	51
Intel^® Stratix^® 10 L-Tile	Minimal	6.25	11800	12800	700	28
Intel^® Stratix^® 10 L-Tile	Full-featured	6.25	27400	35000	3200	54
Intel^® Stratix^® 10 H-Tile	Minimal	6.25	12000	12900	600	28
Intel^® Stratix^® 10 H-Tile	Full-featured	6.25	34300	35000	3100	54
Intel^® Arria^® 10	Minimal	6.25	11200	10300	13000	28
Intel^® Arria^® 10	Full-featured	6.25	24400	28300	4000	53
Arria^® V	Minimal	6.25	11600	10700	1300	38
Arria^® V	Full-featured	6.25	21100	26200	2800	82
Cyclone^® V	Minimal	3.125	11000	11000	1300	38
Cyclone^® V	Full-featured	3.125	20000	25100	2600	84
Stratix^® V	Minimal	6.25	11100	11200	1100	28
Stratix^® V	Full-featured	6.25	20600	25500	2600	49

¹ M10K for Arria^® V and Cyclone^® V devices and M20K for Stratix^® V, Intel^® Arria^® 10, Intel^® Stratix^® 10 and Intel^® Cyclone^® 10 GX devices.

1.5. Device Speed Grades

Following are the recommended device family speed grades for the supported link widths and internal clock frequencies.

Table 3. Recommended Device Family and Speed GradesIn this table, the entry –n indicates that both the industrial speed grade In and the commercial speed grade Cn are supported for the device family and baud rate.
Device Family	Rate
	1.25 Gbaud	2.5 Gbaud	3.125 Gbaud	5.0 Gbaud	6.25 Gbaud
	f_MAX
	31.25 MHz	62.50 MHz	78.125 MHz	125 MHz	156.25 MHz
Intel^® Cyclone^® 10 GX	–5, –6	–5, –6	–5, –6	–5, –6	–5, –6
Intel^® Stratix^® 10	–1, –2, –3	–1, –2, –3	–1, –2, –3	–1, –2, –3	–1, –2
Intel^® Arria^® 10	–1, –2, –3	–1, –2, –3	–1, –2, –3	–1, –2, –3	–1, –2
Arria^® V	–4, –5, –6	–4, –5, –6	–4, –5, –6	–4, –5	–4, –5²
Arria^® V GZ	–3, –4	–3, –4	–3, –4	–3, –4	–3, –4
Cyclone^® V	–6, –7	–6, –7	–6, –7	–7³	–
Stratix^® V	–2, –3, –4	–2, –3, –4	–2, –3, –4	–2, –3, –4	–2, –3, –4

² This speed grade does not support the Arria^® V variations with Avalon^® -ST Pass-through Interfaces.

³ In the Cyclone^® V device family, only Cyclone^® V GT devices support the 5.0 GBaud rate.

1.6. Release Information

IP versions are the same as the Intel^® Quartus^® Prime Design Suite software versions up to v19.1. From Intel^® Quartus^® Prime Design Suite software version 19.2 or later, IP cores have a new IP versioning scheme.

The IP version (X.Y.Z) number may change from one Intel Quartus Prime software version to another. A change in:

X indicates a major revision of the IP. If you update your Intel Quartus Prime software, you must regenerate the IP.
Y indicates the IP includes new features. Regenerate your IP to include these new features.
Z indicates the IP includes minor changes. Regenerate your IP to include these changes.

Table 4. RapidIO II IP Core Release Information
Item	Description
IP Version	19.2.0
Intel^® Quartus^® Prime version	20.3
Release Date	2020.09.28
Ordering Code	IP-RAPIDIOII

Intel^® verifies that the current version of the Intel^® Quartus^® Prime software compiles the previous version of each IP core. Any exceptions to this verification are reported in the Intel^® FPGA IP Release Notes. Intel^® does not verify compilation with IP core versions older than the previous release.

2. Getting Started

You can customize the RapidIO II 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 II IP core.

2.1. Installing and Licensing Intel FPGA IP Cores

The Intel^® Quartus^® Prime software installation includes the Intel^® FPGA IP library. This library provides many useful IP cores for your production use without the need for an additional license. Some Intel^® FPGA IP cores require purchase of a separate license for production use. The Intel^® FPGA IP Evaluation Mode allows you to evaluate these licensed Intel^® FPGA IP cores in simulation and hardware, before deciding to purchase a full production IP core license. You only need to purchase a full production license for licensed Intel^® IP cores after you complete hardware testing and are ready to use the IP in production.

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

Figure 2. IP Core Installation Path

Table 5. IP Core Installation Locations
Location	Software	Platform
`<drive>`:\intelFPGA_pro\quartus\ip\altera	Intel^® Quartus^® Prime Pro Edition	Windows*
`<drive>`:\intelFPGA\quartus\ip\altera	Intel^® Quartus^® Prime Standard Edition	Windows
`<home directory>`:/intelFPGA_pro/quartus/ip/altera	Intel^® Quartus^® Prime Pro Edition	Linux*
`<home directory>`:/intelFPGA/quartus/ip/altera	Intel^® Quartus^® Prime Standard Edition	Linux

Note: The Intel^® Quartus^® Prime software does not support spaces in the installation path.

2.2. Intel FPGA IP Evaluation Mode

The free Intel^® FPGA IP Evaluation Mode allows you to evaluate licensed Intel^® FPGA IP cores in simulation and hardware before purchase. Intel^® FPGA IP Evaluation Mode supports the following evaluations without additional license:

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.

Figure 3. Intel^® FPGA IP Evaluation Mode Flow

Note: Refer to each IP core's user guide for parameterization steps and implementation details.

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.

2.3. Generating IP Cores

You can quickly configure a custom IP variation in the parameter editor.

Use the following steps to specify RapidIO II IP core options and parameters in the Intel^® Quartus^® Prime software parameter editor:

IP Parameter Editor

In the Intel^® Quartus^® Prime Pro Edition software, click File > New Project Wizard to create a new Intel^® Quartus^® Prime project, or File > Open Project to open an existing Intel^® Quartus^® Prime project. The wizard prompts you to specify a device. In the Intel^® Quartus^® Prime Standard Edition software, this step is not required.
In the IP Catalog (Tools > IP Catalog), locate and double-click RapidIO II (IDLE2 up to 6.25 Gbaud) Intel FPGA IP to customize. The New IP Variation window appears.
Specify a top-level name for your custom Intel^® FPGA IP variation. Do not include spaces in IP variation names or paths. The parameter editor saves the IP variation settings in a file with one of the following names:
- <your_ip> .ip (When you generate Intel^® Arria^® 10, Intel^® Stratix^® 10 and Intel^® Cyclone^® 10 GX variations in the Intel^® Quartus^® Prime Pro Edition software)
- <your_ip> .qsys (When you generate Intel^® Arria^® 10 variations in the Intel^® Quartus^® Prime Standard Edition software)
Click Create/OK. The parameter editor appears.
Specify the parameters and options for your IP variation in the parameter editor, including one or more of the following:
- Optionally select preset parameter values. Presets specify initial parameter values for specific applications.
- Specify parameters defining the IP core functionality, port configurations, and device-specific features.
- Specify options for processing the IP core files in other EDA tools.
Click Generate HDL. The Generation dialog box appears.
Specify output file generation options, and then click Generate. The software generates a testbench for your IP core when you create a simulation model. The synthesis and simulation files generate according to your specifications.

Note:
If you click Generate > Generate Testbench System in the IP Parameter Editor, and then click Generate, the Intel^® Quartus^® Prime software generates a testbench framework. However, the resulting testbench is composed of BFM stubs and does not exercise the RapidIO II IP core in any meaningful way. In addition, the testbench Qsys system that is generated does not connect correctly. To generate the IP core testbench, click Generate HDL, select Verilog or VHDL simulation model type for Create simulation model, and click Generate.
To generate an HDL instantiation template that you can copy and paste into your text editor, click Generate > Show Instantiation Template.
Click Finish. Click Yes if prompted to add files representing the IP variation to your project. Optionally turn on the option to Automatically add Intel^® Quartus^® Prime IP Files to all projects. Click Project > Add/Remove Files in Project to add IP files at any time.

Figure 4. Adding IP Files to Project

Note:
For Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX devices, the generated .qsys file must be added to your project to represent IP and Platform Designer systems. For devices released prior to Intel^® Arria^® 10 devices, the generated .qip and .sip files must be added to your project for IP and Platform Designer systems.
After generating and instantiating your IP variation, make appropriate pin assignments to connect ports.

Note: Some IP cores generate different HDL implementations according to the IP core parameters. The underlying RTL of these IP cores contains a unique hash code that prevents module name collisions between different variations of the IP core. This unique code remains consistent, given the same IP settings and software version during IP generation. This unique code can change if you edit the IP core's parameters or upgrade the IP core version. To avoid dependency on these unique codes in your simulation environment, refer to Generating a Combined Simulator Setup Script.

2.3.1. IP Core Generation Output ( Intel Quartus Prime Pro Edition)

The Intel^® Quartus^® Prime software generates the following output file structure for individual IP cores that are not part of a Platform Designer system.

Figure 5. Individual IP Core Generation Output ( Intel^® Quartus^® Prime Pro Edition)

Table 6. Output Files of Intel^® FPGA IP Generation
File Name	Description
<`your_ip`>.ip	Top-level IP variation file that contains the parameterization of an IP core in your project. If the IP variation is part of a Platform Designer system, the parameter editor also generates a .qsys file.
<`your_ip`>.cmp	The VHDL Component Declaration (.cmp) file is a text file that contains local generic and port definitions that you use in VHDL design files.
<`your_ip`>_generation.rpt	IP or Platform Designer generation log file. Displays a summary of the messages during IP generation.
<`your_ip`>.qgsimc (Platform Designer systems only)	Simulation caching file that compares the .qsys and .ip files with the current parameterization of the Platform Designer system and IP core. This comparison determines if Platform Designer can skip regeneration of the HDL.
<`your_ip`>.qgsynth (Platform Designer systems only)	Synthesis caching file that compares the .qsys and .ip files with the current parameterization of the Platform Designer system and IP core. This comparison determines if Platform Designer can skip regeneration of the HDL.
<`your_ip`>.qip	Contains all information to integrate and compile the IP component.
<`your_ip`>.csv	Contains information about the upgrade status of the IP component.
`<your_ip>`.bsf	A symbol representation of the IP variation for use in Block Diagram Files (.bdf).
<`your_ip`>.spd	Input file that `ip-make-simscript` requires to generate simulation scripts. The .spd file contains a list of files you generate for simulation, along with information about memories that you initialize.
<`your_ip`>.ppf	The Pin Planner File (.ppf) stores the port and node assignments for IP components you create for use with the Pin Planner.
<`your_ip`>_bb.v	Use the Verilog blackbox (_bb.v) file as an empty module declaration for use as a blackbox.
<`your_ip`>_inst.v or _inst.vhd	HDL example instantiation template. Copy and paste the contents of this file into your HDL file to instantiate the IP variation.
<`your_ip`>.regmap	If the IP contains register information, the Intel^® Quartus^® Prime software generates the .regmap file. The .regmap file describes the register map information of master and slave interfaces. This file complements the .sopcinfo file by providing more detailed register information about the system. This file enables register display views and user customizable statistics in System Console.
<`your_ip`>.svd	Allows HPS System Debug tools to view the register maps of peripherals that connect to HPS within a Platform Designer system. During synthesis, the Intel^® Quartus^® Prime software stores the .svd files for slave interface visible to the System Console masters in the .sof file in the debug session. System Console reads this section, which Platform Designer queries for register map information. For system slaves, Platform Designer accesses the registers by name.
<`your_ip`>.v <`your_ip`>.vhd	HDL files that instantiate each submodule or child IP core for synthesis or simulation.
mentor/	Contains a msim_setup.tcl script to set up and run a ModelSim* simulation.
aldec/	Contains a Riviera-PRO* script rivierapro_setup.tcl to setup and run a simulation.
/synopsys/vcs /synopsys/vcsmx	Contains a shell script vcs_setup.sh to set up and run a VCS* simulation. Contains a shell script vcsmx_setup.sh and synopsys_sim.setup file to set up and run a VCS* MX simulation.
/cadence	Contains a shell script ncsim_setup.sh and other setup files to set up and run an NCSim simulation.
/xcelium	Contains an Xcelium* Parallel simulator shell script xcelium_setup.sh and other setup files to set up and run a simulation.
/submodules	Contains HDL files for the IP core submodule.
<`IP submodule`>/	Platform Designer generates /synth and /sim sub-directories for each IP submodule directory that Platform Designer generates.

2.4. Generating IP Cores ( Intel Quartus Prime Standard Edition)

This topic describes parameterizing and generating an IP variation using a legacy parameter editor in the Intel^® Quartus^® Prime Standard Edition software. Some IP cores use a legacy version of the parameter editor for configuration and generation. Use the following steps to configure and generate an IP variation using a legacy parameter editor.

Legacy Parameter Editor

Note: The legacy parameter editor generates a different output file structure than the Intel^® Quartus^® Prime Pro Edition software.

In the IP Catalog (Tools > IP Catalog), locate and double-click the name of the IP core to customize. The parameter editor appears.
Specify a top-level name and output HDL file type for your IP variation. This name identifies the IP core variation files in your project. Click OK. Do not include spaces in IP variation names or paths.
Specify the parameters and options for your IP variation in the parameter editor. Refer to your IP core user guide for information about specific IP core parameters.
Click Finish or Generate (depending on the parameter editor version). The parameter editor generates the files for your IP variation according to your specifications. Click Exit if prompted when generation is complete. The parameter editor adds the top-level .qip file to the current project automatically.

Note: For devices released prior to Intel^® Arria^® 10 devices, the generated .qip and .sip files must be added to your project to represent IP and Platform Designer systems. To manually add an IP variation generated with legacy parameter editor to a project, click Project > Add/Remove Files in Project and add the IP variation .qip file.

Note: Some IP cores generate different HDL implementations according to the IP core parameters. The underlying RTL of these IP cores contains a unique code that prevents module name collisions between different variations of the IP core. This unique code remains consistent, given the same IP settings and software version during IP generation. This unique code can change if you edit the IP core's parameters or upgrade the IP core version. To avoid dependency on these unique codes in your simulation environment, refer to Generating a Combined Simulator Setup Script.

2.4.1. IP Core Generation Output ( Intel Quartus Prime Standard Edition)

The Intel^® Quartus^® Prime Standard Edition software generates one of the following output file structures for individual IP cores that use one of the legacy parameter editors.

Figure 6. IP Core Generated Files (Legacy Parameter Editors)

2.5. RapidIO II IP Core Testbench Files

The RapidIO II IP core testbench is generated when you create a simulation model of the IP core.

For Intel^® Arria^® 10, Intel^® Stratix^® 10 and Intel^® Cyclone^® 10 GX variations:

The testbench script appears in <your_ip>/sim/<vendor>.
The testbench files appear in <your_ip>/altera_rapidio2_<version>/sim/tb.
The IP core simulation files appear in <Qsys_system or your_ip>/altera_rapidio2_<version>/sim/<vendor>.

For all other device variations you generate from the Intel^® Quartus^® Prime IP Catalog:

The testbench script appears in <your_ip>_sim/<vendor>.
The testbench files appear in <your_ip>_sim/altera_rapidio2/tb.
The IP core simulation files appear in <your_ip>_sim/altera_rapidio2/<vendor>.

For all other device variations you generate from the Platform Designer IP Catalog in the Intel^® Quartus^® Prime software:

The testbench script appears in <Qsys_system or your_ip>/simulation/<vendor>.
The testbench files appear in <Qsys_system or your_ip>/simulation/submodules/tb.
The IP core simulation files appear in <Qsys_system or your_ip>/simulation/submodules/<vendor>.

The RapidIO II IP core does not generate an example design.

2.6. Simulating IP Cores

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 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.

Note: The Intel^® Quartus^® Prime Pro Edition software does not support NativeLink RTL simulation.

⁴ The Aldec Riviera-PRO simulator is not supported for this IP core.

2.6.1. Simulating the Testbench with the ModelSim Simulator

To simulate the RapidIO II IP core testbench using the Mentor Graphics ModelSim* simulator, perform the following steps:

Start the ModelSim* simulator.
In ModelSim*, change directory to the directory where the testbench simulation script is located:
- For Intel^® Arria^® 10, Intel^® Stratix^® 10, and Intel^® Cyclone^® 10 GX variations, change directory to <your_ip>/sim/mentor.
- For all other device variations you generate from the Intel^® Quartus^® Prime IP Catalog, change directory to <your_ip>_sim/mentor.
- For all other device variations you generate from the Platform Designer IP Catalog, change directory to <Qsys_system or your_ip>/simulation/mentor.
To set up the required libraries, compile the generated simulation model, and exercise the simulation model with the provided testbench, type one of the following sets of commands:
1. For V-series FPGA variations using the Intel^® Quartus^® Prime IP Catalog, type the following commands:
```
do msim_setup.tcl
set TOP_LEVEL_NAME <your_ip>.tb_rio
ld
run -all
```
  For example:
```
set TOP_LEVEL_NAME my_srio.tb_rio
```
  where "my_srio" is the IP variation.
2. For V-series FPGA variations using the Platform Designer IP Catalog, type the following commands:
```
do msim_setup.tcl
set TOP_LEVEL_NAME <instance_name>.tb_rio
ld
run -all
```
  For example:
```
set TOP_LEVEL_NAME rapidio2_0.tb_rio
```
  where "rapidio2_0" is the instance name.
3. For Intel^® Arria^® 10 variations using the Intel^® Quartus^® Prime Standard Edition software, type the following commands:
```
do msim_setup.tcl
set TOP_LEVEL_NAME <your_ip>_altera_rapidio2_<version>.tb_rio
ld
run -all
```
  For example:
```
set TOP_LEVEL_NAME my_srio_altera_rapidio2_171.tb_rio
```
  where "my_srio" is the IP variation.
4. For Intel^® Arria^® 10, Intel^® Stratix^® 10 and Intel^® Cyclone^® 10 GX variations using the Intel^® Quartus^® Prime Pro Edition software, type the following commands:
```
do msim_setup.tcl
set TOP_LEVEL_NAME altera_rapidio2_<version>.tb_rio
ld
run -all
```
  For example:
```
set TOP_LEVEL_NAME altera_rapidio2_171.tb_rio
```
Simulation of the testbench might take few minutes. The testbench displays a TESTBENCH_PASSED message after completion.

2.6.2. Simulating the Testbench with the VCS Simulator

To simulate the RapidIO II IP core testbench using the Synopsys VCS* simulator, perform the following steps:

Change directory to the directory where the testbench simulation script is located:
- For Intel^® Arria^® 10, Intel^® Stratix^® 10 and Intel^® Cyclone^® 10 GX variations, change directory to <your_ip>/sim/synopsys/vcs.
- For all other device variations you generate from the Intel^® Quartus^® Prime IP Catalog, change directory to <your_ip>_sim/synopsys/vcs.
- For all other device variations you generate from the Platform Designer IP Catalog, change directory to <Qsys_system or your_ip>/simulation/synopsys/vcs.

Type the following commands:

sh vcs_setup.sh TOP_LEVEL_NAME="tb_rio"
./simv

2.6.3. Simulating the Testbench with the NCSim Simulator

To simulate the RapidIO II IP core testbench using the Cadence NCSim*

simulator, perform the following steps:

Change directory to the directory where the testbench simulation script is located:
- For Intel^® Arria^® 10, Intel^® Stratix^® 10 and Intel^® Cyclone^® 10 GX variations, change directory to <your_ip>/sim/cadence.
- For all other device variations you generate from the Intel^® Quartus^® Prime IP Catalog, change directory to <your_ip>_sim/cadence.
- For all other device variations you generate from the Platform Designer IP Catalog, change directory to <Qsys_system or your_ip>/simulation/cadence.

Type the following command:

sh ncsim_setup.sh TOP_LEVEL_NAME="tb_rio" USER_DEFINED_SIM_OPTIONS="-input\ \"@run\ 2ms\;\ exit\""

2.6.4. Simulating the Testbench with the Xcelium Parallel Simulator

To simulate the RapidIO II IP core testbench using the Cadence Xcelium* parallel simulator, perform the following steps:

Change directory to the directory where the testbench simulation script is located:
- For Intel^® Arria^® 10, Intel^® Stratix^® 10 variations, change directory to <your_ip>/sim/cadence.
- For all other device variations you generate from the Intel^® Quartus^® Prime IP Catalog, change directory to <your_ip>_sim/xcelium.
- For all other device variations you generate from the Platform Designer IP Catalog, change directory to <Qsys_system or your_ip>/simulation/xcelium.

Type the following command:

sh xcelium_setup.sh TOP_LEVEL_NAME="tb_rio" USER_DEFINED_SIM_OPTIONS="-input\ \"@run\ 2ms\;\ exit\""

2.7. Integrating Your IP Core in Your Design

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 IP catalog and build your design in Platform Designer, you can perform these steps in Platform Designer. If you generate your IP core directly from the Intel^® Quartus^® Prime IP catalog, you must implement these steps manually in your design.

2.7.1. Dynamic Transceiver Reconfiguration Controller

RapidIO II IP core variations that target an Arria^® V, Arria^® V GZ, Cyclone^® V, Stratix^® V device require an external reconfiguration controller to function correctly in hardware. RapidIO II IP core variations that target an Intel^® Arria^® 10, Intel^® Stratix^® 10 or Intel^® Cyclone^® 10 GX device include a reconfiguration controller block and do not require an external reconfiguration controller. However, you need to control dynamic transceiver reconfiguration in Intel^® Arria^® 10, Intel^® Stratix^® 10 and Intel^® Cyclone^® 10 GX devices through dynamic reconfiguration interface if you turn on that interface in the RapidIO II parameter editor.

Keeping the reconfiguration controller external to the IP core in these devices provides the flexibility to share the reconfiguration controller among multiple IP cores and to accommodate FPGA transceiver layouts based on the usage model of your application. In Intel^® Arria^® 10 and Intel^® Stratix^® 10 devices, you can configure individual transceiver channels flexibly through an Avalon^® -MM transceiver reconfiguration interface.

Intel^® recommends that you implement the reconfiguration controller using the Transceiver Reconfiguration Controller. The Transceiver Reconfiguration Controller performs offset cancellation during bring-up of the transceiver channels.

The Transceiver Reconfiguration Controller is available in the IP catalog. You must add it to your design and connect it to the RapidIO II IP core reconfiguration signals.

In the Transceiver Reconfiguration Controller parameter editor, you select the features of the transceiver that can be dynamically reconfigured. However, you must ensure that the following two features are turned on:

Enable PLL calibration
Enable Analog controls

An informational message in the RapidIO II parameter editor tells you the number of reconfiguration interfaces you must configure in your dynamic reconfiguration block.

The Reconfiguration Controller communicates with the RapidIO II IP core on two buses:

reconfig_to_xcvr (output)
reconfig_from_xcvr (input)

Each of these buses connects to the bus of the same name in the RapidIO II IP core. You must also connect the following Reconfiguration Controller signals:

mgmt_clk_clk
mgmt_rst_reset
reconfig_busy

2.7.2. Transceiver PHY Reset Controller

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

In the Transceiver PHY Reset Controller parameter editor, you must perform the following for compatibility with the RapidIO II IP core:

Select the Use separate RX reset per channel option.

When you generate a RapidIO II IP core that target an Intel^® Arria^® 10, Intel^® Stratix^® 10, or Intel^® Cyclone^® 10 GX device, the Intel^® Quartus^® Prime software generates the HDL code for the Transceiver PHY Reset Controller in the following file: <your_ip>/altera_rapidio2_<version>/synth/<your_ip>_altera_rapidio2_<version>_<random_string>.v/.vhd ⁵

⁵ For Intel^® Arria^® 10, Intel^® Stratix^® 10 and Intel^® Cyclone^® 10 GX devices, please refer to <your_ip>_generation.rpt file to get the filename for Transceiver PHY Reset Controller HDL code, listed in the line: phy_reset_controller_wrapper_name: <PHY Reset Controller name>

2.7.3. Transceiver Settings

Intel^® recommends that you maintain the default Native PHY IP core settings generated for the RapidIO II IP core. If you edit the existing Native PHY IP core, the regenerated Native PHY IP core does not instantiate correctly in the top-level RapidIO II IP core. If you must modify transceiver settings, perform the modifications by editing the project Quartus Settings File (.qsf).

2.7.4. Adding Transceiver Analog Settings for Arria V GZ and Stratix V Variations

In general, Intel^® recommends that you maintain the default transceiver settings specified by the RapidIO II IP core. However, Arria^® V GZ or Stratix^® V variations require that you specify some analog transceiver settings.

After you generate your RapidIO II IP core in a Intel^® Quartus^® Prime project that targets an Arria^® V GZ or Stratix^® V device, perform the following steps:

In the Intel^® Quartus^® Prime software, on the Assignments tab, click Assignment Editor.
In the Assignment Editor, in the Assignment Name column, double click <<new>> and select Transceiver Analog Settings Protocol.
In the To column, type the name of the transceiver serial data input node in your IP core variation. This name is the variation-specific version of the rd signal.
In the Value column, click and select SRIO.
Repeat steps 2 to 4 to create an additional assignment, In step 3, instead of typing the name of the transceiver serial data input node, type the name of the transceiver serial data output put node. This name is the variation-specific version of the td signal.

2.7.5. External Transceiver PLL

RapidIO II IP cores that target an Intel^® Arria^® 10, Intel^® Stratix^® 10, or Intel^® Cyclone^® 10 GX device 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 II 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 Maximum baud rate parameter in the RapidIO II 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 II 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 II IP core, the Intel^® Quartus^® Prime software also generates the HDL code for an ATX PLL, in the following file:

<your_ip>/altera_rapidio2_<version>/synth/<your_ip>_altera_rapidio2_<version>_<random_string>.v/.vhd ⁶

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

Table 7. External Transceiver TX PLL Connections to RapidIO II IP CoreYou must connect the TX PLL IP core to the RapidIO II IP core according to the following rules.
Signal	Direction	Connection Requirements
`pll_refclk0`	Input	Drive the PLL pll_refclk0 input port and the RapidIO II IP core tx_pll_refclk signal from the same clock source. The minimum allowed frequency for the pll_refclk0 clock in the Intel^® Arria^® 10 ATX PLL is 100 MHz.
`tx_bonding_clocks [(6 x <` number of lanes `>)–1:0]`	Output	Connect `tx_bonding_clocks[6n+5:6n]` to the `tx_bonding_clocks_chN` input bus of transceiver channel N, for each transceiver channel N that connects to the RapidIO link. The transceiver channel input ports are RapidIO II IP core input ports.

⁶ For Intel^® Arria^® 10 and Intel^® Stratix^® 10 devices, please refer to <your_ip>_generation.rpt file to get the filename for ATX PLL HDL code, listed in the line: atx_pll_wrapper_name: <atx pll name>.

2.8. Compiling the Full Design and Programming the FPGA

You can use the Start Compilation command on the Processing menu in the Intel^® Quartus^® Prime software to compile your design. After successfully compiling your design, program the targeted Intel^® device with the Programmer and verify the design in hardware.

2.9. Instantiating Multiple RapidIO II IP Cores in V-series FPGA devices

If you want to instantiate multiple RapidIO II IP cores that target an Arria^® V, Arria^® V GZ, Cyclone^® V, or Stratix^® V device, a few additional steps are required. These steps are not relevant for variations that target any Intel^® Arria^® 10 or Intel^® Stratix^® 10 devices.

The Arria^® V, Arria^® V GZ, Cyclone^® V, and Stratix^® V transceivers are configured with the Native PHY IP core. When your design contains multiple RapidIO II IP cores, the Intel^® Quartus^® Prime Fitter handles the merge of multiple Native PHY IP cores in the same transceiver block automatically, if they meet the merging requirements.

If you have different RapidIO II 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 II IP core transceivers. The correct total number of reconfiguration interfaces is the sum of the reconfiguration interfaces for each RapidIO II IP core; the number of reconfiguration interfaces for each RapidIO II IP core is the number of channels plus one. You must ensure that the reconfig_togxb and reconfig_fromgxb signals of an individual RapidIO II IP core connect to a single Transceiver Reconfiguration Controller.

For example, if your design includes one ×4 RapidIO II IP core and three ×1 RapidIO II IP cores, the Transceiver Reconfiguration Controllers in your design must include eleven dynamic reconfiguration interfaces: five for the ×4 RapidIO II IP core, and two for each of the ×1 RapidIO II IP cores. The dynamic reconfiguration interfaces connected to a single RapidIO II 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 II IP cores must connect to a single Transceiver Reconfiguration Controller.

Figure 7. Example Connections Between Two Transceiver Reconfiguration Controllers and Four RapidIO II IP Cores

In the example, 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 II IP cores; subject to the constraints described, you may choose a different configuration.

3. Parameter Settings

You customize the RapidIO II IP core by specifying parameters in the RapidIO II parameter editor, which you access from the MegaWizard Plug-In Manager or the Platform Designer system integration tool in the Intel^® Quartus^® Prime software.

In the RapidIO II parameter editor, you use the following tabs to parameterize the RapidIO II IP core:

Physical Layer
Transport Layer
Logical Layer
Capability Registers
Command and Status Registers
Error Management Registers

3.1. Physical Layer Settings

The Physical layer includes RapidIO II specific logic configuration and transceiver configuration.

The RapidIO II IP core instantiates a Native PHY IP core to configure the transceivers. The RapidIO II IP core provides no parameters to modify this configuration directly. Intel^® recommends you do not modify the default transceiver settings configured in the Native PHY IP core instance generated with the RapidIO II IP core.

The Physical Layer tab defines the characteristics of the Physical layer based on these categories: Mode Selection, Data Settings, and Transceiver Settings ⁷.

⁷ Only available in Intel^® Arria^® 10, Intel^® Stratix^® 10 and Intel^® Cyclone^® 10 GX variations.

3.1.1. Mode Selection

Mode Selection comprise the Supported modes option.

The Supported modes parameter allows you to specify the 1x, 2x, and 4x modes of operation. All RapidIO II IP core variations support 1x mode. The RapidIO II IP core initially attempts link initialization in the maximum number of lanes that the variation supports. The IP core supports fallback to lower numbers of ports.

3.1.2. Data Settings

Data Settings set the Maximum baud rate and Reference clock frequency.

Maximum Baud Rate

Maximum baud rate defines the maximum supported baud rate. The RapidIO II IP core does not support automatic baud rate discovery.

Table 8. Baud rates supported by the RapidIO II IP core
Device Family	Mode
	1x, 2x					4x
	Baud Rate (MBaud)
	1250	2500	3125	5000	6250	1250	2500	3125	5000	6250
Intel^® Cyclone^® 10 GX	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Intel^® Stratix^® 10	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Intel^® Arria^® 10	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Arria^® V	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Cyclone^® V	Yes	Yes	Yes	Yes ⁸	No	Yes	Yes	Yes	Yes ⁸	No
Stratix^® V	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes

Reference clock frequency defines the frequency of the reference clock for your RapidIO II IP core internal transceiver. The RapidIO II parameter editor allows you to select any frequency supported by the transceiver.

⁸ In the Cyclone^® V device family, only Cyclone^® V GT devices support the 5.0 GBaud rate.

3.1.3. Transceiver Settings

Table 9. Transceiver SettingsIn the table below, all the parameters except VCCR_GXB, VCCT_GXB, and Transceiver Tile are only available when you turn on the **Enable transceiver dynamic reconfiguration** parameter.
Parameter	Value	Device Family	Software Support	Description
Transceiver Tile	L-Tile, H-Tile	Intel^® Stratix^® 10	Intel^® Quartus^® Prime Pro Edition	Specifies the transceiver tile on your target Intel^® Stratix^® 10 device. The Device settings of the Intel^® Quartus^® Prime Pro Edition project in which you generate the IP core determines the transceiver tile type. In Intel^® Quartus^® Prime Pro Edition 17.1, this parameter is grayed out. The correct tile is derived when you select a device for the project. The IP generates the correct tile type for your target Intel^® Stratix^® 10 device.
VCCR_GXB and VCCT_GXB supply voltage for the transceivers	1.0 V, 1.1 V	Intel^® Stratix^® 10	Intel^® Quartus^® Prime Pro Edition	This parameter specifies the `VCCR_GXB` and `VCCT_GXB` transceiver supply voltage. The default value is 1.0 V.
Enable transceiver dynamic reconfiguration	On/Off	Intel^® Arria^® 10, Intel^® Stratix^® 10, and Intel^® Cyclone^® 10 GX	Intel^® Quartus^® Prime Standard Edition, Intel^® Quartus^® Prime Pro Edition	This parameter specifies that the IP core instantiates Intel^® Arria^® 10 or Intel^® Stratix^® 10 Transceiver Native PHY with dynamic reconfiguration enabled. If you do not expect to use this interface, you can turn off this parameter to lower the number of IP core signals to route.
Enable transceiver Altera Debug Master Endpoint (ADME)	On/Off	Intel^® Arria^® 10, Intel^® Stratix^® 10 and Intel^® Cyclone^® 10 GX	Intel^® Quartus^® Prime Standard Edition, Intel^® Quartus^® Prime Pro Edition	When you turn on this option, an embedded Altera Debug Master Endpoint connects internally to the Avalon^® -MM slave interface for dynamic reconfiguration. The ADME can access the reconfiguration space of the transceiver. It uses JTAG via the System Console to run tests and debug functions.
Transceiver Share reconfiguration interface	On/Off	Intel^® Arria^® 10, Intel^® Stratix^® 10 and Intel^® Cyclone^® 10 GX	Intel^® Quartus^® Prime Standard Edition, Intel^® Quartus^® Prime Pro Edition	When you turn on this option, the Native PHY presents a single Avalon^® -MM slave interface for dynamic reconfiguration of all channels. In this configuration, the upper address bits (for Intel^® Arria^® 10 devices - [log₂<N> + 9:10] and for Intel^® Stratix^® 10 devices - [log₂<N> + 10:11]) of the reconfiguration address bus specify the selected channel and the lower address bits (for Intel^® Arria^® 10 devices - [9:0] and for Intel^® Stratix^® 10 devices - [10:0]) provide the register offset address within the reconfiguration space of the selected channel. This option is unavailable in 1x mode. This option is auto-enabled when you turn on the Enable transceiver Altera Debug Master Endpoint (ADME) option.
Enable Transceiver capability registers	On/Off	Intel^® Arria^® 10, Intel^® Stratix^® 10	Intel^® Quartus^® Prime Standard Edition, Intel^® Quartus^® Prime Pro Edition	Turn on this option to enable capability registers. These registers provide high-level information about the transceiver channel's /PLL's configuration.
Set user-defined IP identifier	User-specified	Intel^® Arria^® 10, Intel^® Stratix^® 10 and Intel^® Cyclone^® 10 GX	Intel^® Quartus^® Prime Standard Edition, Intel^® Quartus^® Prime Pro Edition	Sets a user-defined numeric identifier that can be read from the user_identifier offset when the capability registers are enabled.
Enable Transceiver control and status registers	On/Off	Intel^® Arria^® 10, Intel^® Stratix^® 10 and Intel^® Cyclone^® 10 GX	Intel^® Quartus^® Prime Standard Edition, Intel^® Quartus^® Prime Pro Edition	Turn on this option to enable soft registers for reading status signals and writing control signals on the PHY /PLL interface through the reconfiguration interface.
Enable Transceiver PRBS soft accumulators	On/Off	Intel^® Arria^® 10, Intel^® Stratix^® 10 and Intel^® Cyclone^® 10 GX	Intel^® Quartus^® Prime Standard Edition, Intel^® Quartus^® Prime Pro Edition	Turn on this option to enable soft logic to perform PRBS bit and error accumulation when using the hard PRBS generator and checker.

3.2. Transport Layer Settings

The Transport layer settings specify properties of the Transport layer in your RapidIO II IP core variation. These parameters determine whether the RapidIO II IP core uses 8-bit or 16-bit device IDs, whether the Transport layer has an Avalon^® -ST pass-through interface, and how the RapidIO II IP core handles a request packet with a supported ftype but a destination ID not assigned to this endpoint.

3.2.1. Enable 16-Bit Device ID Width

The Enable 16-bit device ID width setting specifies a device ID width of 8-bit or 16-bit. RapidIO packets contain destination ID and source ID fields, which have the specified width. If this IP core uses 16-bit device IDs, it supports large common transport systems.

The two parameter values do not cause symmetrical behavior. If you turn on this option, the IP core can still support user logic that processes packets with 8-bit device IDs. You can parameterize the IP core to route such packets to the Avalon^® -ST passthrough interface, where user logic might handle it. However, if you turn off this option, the RapidIO II IP core drops all incoming packets with a 16-bit device ID.

3.2.2. Enable Avalon -ST Pass-Through Interface

Turn on Enable Avalon^® -ST pass-through interface to include the Avalon^® -ST pass-through interface in your RapidIO II variation.

The Transport layer routes all unrecognized packets to the Avalon^® -ST pass-through interface. Unrecognized packets are those that contain Format Types (ftypes) for Logical layers not enabled in this IP core, or destination IDs not assigned to this endpoint. However, if you disable destination ID checking, the packet is a request packet with a supported ftype, and the Transport Type (tt) field of the packet matches the device ID width setting of this IP core, the packet is routed to the appropriate Logical layer.

Note: The destination ID can match this endpoint only if the tt field in the packet matches the device ID width setting of the endpoint.

Request packets with a supported ftype and correct tt field, but an unsupported ttype, are routed to the Logical layer supporting the ftype, which allows the following tasks:

An ERROR response can be sent to requests that require a response.
An unsupported_transaction error can be recorded in the Error Management extension registers.

Response packets are routed to a Logical layer module or the Avalon^® -ST pass-through port based on the value of the target transaction ID field.

3.2.3. Disable Destination ID Checking

Disable destination ID checking by default determines the default value of the option to route a request packet with a supported ftype but a destination ID not assigned to this endpoint.

You specify the initial value for the option in the RapidIO II parameter editor, and software can change it by modifying the value of the DIS_DEST_ID_CHK field of the Port 0 Control CSR. By default, this parameter is turned off.

3.3. Logical Layer Settings

The Logical layer settings specify properties of the following Logical layer modules:

Maintenance module
Doorbell module
I/O master module
I/O slave module

3.3.1. Maintenance Module Settings

The Maintenance module settings specify properties of the Maintenance Logical layer.

If you turn on Enable Maintenance module, a Maintenance module is configured in your RapidIO II IP core.

If the Maintenance module is enabled, the Maintenance address bus width parameter is available to determine the Maintenance slave interface address bus width. This parameter currently supports only a 24-bit address width.

This parameter controls the width of the Maintenance slave interface address bus only. The Maintenance master interface address bus is 32 bits wide. The Maintenance module supports RapidIO MAINTENANCE read and write operations and MAINTENANCE port-write operations.

3.3.2. Doorbell Module Settings

The Doorbell module settings specify properties of the Doorbell Logical layer module.

If you turn on Enable Doorbell support, a Doorbell module is configured in your RapidIO II IP core to support generation of outbound RapidIO DOORBELL messages and reception and processing of inbound DOORBELL messages.

If this parameter is turned off, received DOORBELL messages are routed to the Avalon- ST pass-through interface if it is enabled, or are silently dropped if the pass-through interface is not enabled.

If the Doorbell module and the I/O slave module are both enabled, the Prevent doorbell messages from passing write transactions parameter is available. This parameter controls support for preserving transaction order between DOORBELL messages and I/O write request transactions sent to the IP core by user logic.

3.3.3. I/O Master Module Settings

The I/O Master module settings specify properties of the I/O Logical layer Avalon-MM Master module.

If you turn on Enable I/O Logical layer Master module, an I/O Master module is configured in your RapidIO II IP core.

If the I/O Logical layer Master module is enabled, the Number of Rx address translation windows parameter is available. This parameter allows you to specify a value from 1 to 16 to define the number of receive address translation windows the I/O Master Logical layer supports.

3.3.4. I/O Slave Module Settings

The I/O Slave module settings specify properties of the I/O Logical layer Avalon-MM Slave module.

If you turn on Enable I/O Logical layer Slave module, an I/O Slave module is configured in your RapidIO II IP core. Turning on this parameter makes the following I/O Slave module parameters available in the parameter editor:

Number of Tx address translation windows allows you to specify a value from 1 to 16 to define the number of transmit address translation windows the I/O Slave Logical layer supports.
I/O Slave address bus width currently supports widths between 10 and 32 bits, inclusive.

3.4. Capability Registers Settings

The Capability Registers tab lets you set values for some of the capability registers (CARs), which exist in every RapidIO processing element and allow an external processing element to determine the endpoint’s capabilities through MAINTENANCE read operations. All CARs are 32 bits wide.

Note: The settings on the Capability Registers page do not cause any features to be enabled or disabled in the RapidIO II IP core. Instead, they set the values of certain bit fields in some CARs.

3.4.1. Device Identity CAR

The Device Identity CAR options identify the device and vendor IDs and set values in the Device Identity CAR.

Device ID sets the DeviceIdentity field of the Device Identity register. This option uniquely identifies the type of device from the vendor specified in the DeviceVendorIdentity field of the Device Identity register.
Vendor ID uniquely identifies the vendor and sets the DeviceVendorIdentity field in the Device Identity register. Set Vendor ID to the identifier value assigned by the RapidIO Trade Association to your company.

3.4.2. Device Information CAR

The Device Information CAR option identifies the revision ID and sets its value in the Device Information CAR.

Revision ID identifies the revision level of the device and sets the value of the DeviceRev field in the DeviceRev field of the Device Information register. This value is assigned and managed by the vendor specified in the VendorIdentity field of the Device Identity register.

3.4.3. Assembly Identity CAR

The Assembly Identity CAR options identify the vendor who manufactured the assembly or subsystem of the device, and sets these values in the Assembly Identity CAR.

Assembly ID corresponds to the AssyIdentity field of the Assembly Identity register, which uniquely identifies the type of assembly. This field is assigned and managed by the vendor specified in the AssyVendorIdentity field of the Assembly Identity register.
Assembly Vendor ID uniquely identifies the vendor who manufactured the assembly. This value corresponds to the AssyVendorIdentity field of the Assembly Identity register.

3.4.4. Assembly Information CAR

The Assembly Information CAR options identify the vendor who manufactured the assembly or subsystem of the device and the pointer to the first entry in the Extended Features list, and sets these values in the Assembly Information CAR.

Revision ID indicates the revision level of the assembly and sets the AssyRev field of the Assembly Information CAR. In the Platform Designer design flow, this parameter is labeled Assembly revision ID.

3.4.5. Processing Element Features CAR

The Processing Element Features CAR identifies the major features of the processing element.

Bridge Support, when turned on, sets the Bridge bit in the Processing Element Features CAR and indicates that this processing element can bridge to another interface such as PCI Express, a proprietary processor bus such as Avalon-MM, DRAM, or other interface.
Memory Access, when turned on, sets the Memory bit in the Processing Element Features CAR and indicates that the processing element has physically addressable local address space that can be accessed as an endpoint through non-maintenance operations. This local address space may be limited to local configuration registers, or can be on-chip SRAM, or another memory device.
Processor Present, when turned on, sets the Processor bit in the Processing Element Features CAR and indicates that the processing element physically contains a local processor such as the Nios^® II embedded processor or similar device that executes code. A device that bridges to an interface that connects to a processor should set the Bridge bit instead of the Processor bit.
Enable Flow Arbitration Support, when turned on, sets the Flow Arbitration Support bit in the Processing Element Features CAR and indicates that the processing element supports flow arbitration. The IP core routes Type 7 packets to the Avalon-ST pass-through interface, so user logic must implement flow control on the Avalon-ST pass-through interface.
Enable Standard Route Table Configuration Support, when turned on, sets the Standard route table configuration support bit in the Processing Element Features CAR and indicates that the processing element supports the standard route table configuration mechanism.
This property is relevant in switch processing elements only.

If you turn on Enable standard route table configuration support, user logic must implement the functionality and registers to support standard route table configuration. The RapidIO II IP core does not implement the Standard Route CSRs at offsets 0x70, 0x74, and 0x78.
Enable Extended Route Table Configuration Support
If you turn on Enable standard route table configuration support, the Enable extended route table configuration support parameter is available.

Enable extended route table configuration support, when turned on, sets the Extended route table configuration support bit in the Processing Element Features CAR and indicates that the processing element supports the extended route table configuration mechanism.

This property is relevant in switch processing elements only.

If you turn on Enable extended route table configuration support, user logic must implement the functionality and registers to support extended route table configuration. The RapidIO II IP core does not implement the Standard Route CSRs at offsets 0x70, 0x74, and 0x78.
Enable Flow Control Support, when turned on, sets the Flow Control Support bit in the Processing Element Features CAR and indicates that the processing element supports flow control.
Enable Switch Support, when turned on, sets the Switch bit in the Processing Element Features CAR and indicates that the processing element can bridge to another external RapidIO interface. A processing element that only bridges to a local endpoint is not considered a switch port.

3.4.6. Switch Port Information CAR

If you turn on Enable switch support, the following parameters are available:

Number of Ports specifies the total number of ports on the processing element. This value sets the PortTotal field of the Switch Port Information CAR.
Port Number sets the PortNumber field of the Switch Port Information CAR. This value is the number of the port from which the MAINTENANCE read operation accesses this register.

3.4.7. Switch Route Table Destination ID Limit CAR

Switch Route Table Destination ID Limit sets the Max_destID field of the Switch Route Table Destination ID Limit CAR.

3.4.8. Data Streaming Information CAR

Maximum PDU sets the MaxPDU field of the Data Streaming Information CAR.
Number of Segmentation Contexts sets the SegSupport field of the Data Streaming Information CAR.

3.4.9. Source Operations CAR

The Source operations CAR override parameter supports user input to the values of all of the fields of the Source Operations CAR. You can use this parameter to specify that your RapidIO II IP core variation handles some specific functionality through the Avalon-ST pass-through port.

The 32-bit default value of the Source Operations CAR is determined by the functionality you enable in the RapidIO II IP core with other settings in the parameter editor. For example, if you turn on Enable Maintenance module, the PORT_WRITE field is set by default to the value of 1’b1. However, the actual reset value of the Source Operations CAR is the result of the bitwise exclusive-or operation applied to the default values and the value you specify for the Source operations CAR override parameter.

For example, by default, the Data Message field of this CAR is turned off. However, you can set the value of the Source operations CAR override parameter to 32’h00000800 to override the default value of the Data Message field, to indicate that user logic attached to the Avalon-ST pass-through interface supports data message operations. The RapidIO II IP core supports reporting of data-message related errors through the standard Error Management Extensions registers.

3.4.10. Destination Operations CAR

The Destination operations CAR override parameter supports user input to the values of all of the fields of the Destination Operations CAR. You can use this parameter to specify that your RapidIO II IP core variation handles some specific functionality through the Avalon-ST pass-through port.

The 32-bit default value of the Destination Operations CAR is determined by the functionality you enable in the RapidIO II IP core with other settings in the parameter editor. For example, if you turn on Enable Maintenance module, the PORT_WRITE field is set by default to the value of 1’b1. However, the actual reset value of the Destination Operations CAR is the result of the bitwise exclusive-or operation applied to the default values and the value you specify for the Destination operations CAR override parameter.

For example, by default, the Data Message field of this CAR is turned off. However, you can set the value of the Destination operations CAR override parameter to 32’h00000800 to override the default value of the Data Message field, to indicate that user logic attached to the Avalon-ST pass-through interface supports data message operations that the RapidIO II IP core receives on the RapidIO link. The RapidIO II IP core supports reporting of data-message related errors through the standard Error Management Extensions registers.

3.5. Command and Status Registers Settings

The Command and Status Registers tab lets you set the reset values for some of the command and status registers (CSRs), which exist in every RapidIO processing element. All CSRs are 32 bits wide.

3.5.1. Data Streaming Logical Layer Control CSR

Supported Traffic Management Types Reset Value sets the reset value of the TM_TYPE_SUPPORT field of the Data Streaming Logical Layer Control CSR.
Traffic Management Mode Reset Value sets the reset value of the TM_MODE field of the Data Streaming Logical Layer Control CSR.
Maximum Transmission Unit Reset Value sets the reset value of the MTU field of the Data Streaming Logical Layer Control CSR.

3.5.2. Port General Control CSR

Host Reset Value sets the reset value of the HOST field of the Port General Control CSR.
Master Enable Reset Value sets the reset value of the ENA field of the Port General Control CSR.
Discovered Reset Value sets the reset value of the DISCOVER field of the Port General Control CSR.

3.5.3. Port 0 Control CSR

Flow Control Participant Reset Value sets the reset value of the Flow Control Participant field of the Port 0 Control CSR.
Enumeration Boundary Reset Value sets the reset value of the Enumeration Boundary field of the Port 0 Control CSR.
Flow Arbitration Participant Reset Value sets the reset value of the Flow Arbitration Participant field of the Port 0 Control CSR.

3.5.4. Lane n Status 0 CSR

Transmitter Type Reset Value sets the value of the Transmitter Type field and the reset value of the Transmitter Mode field of the Lane n Status 0 CSR.
Receiver Type Reset Value sets the value of the Receiver Type field of the Lane n Status 0 CSR.

3.5.5. Extended Features Pointer CSR

The Extended features pointer points to the final entry in the extended features list. This parameter supports the addition of custom user-defined registers to your RapidIO II IP core. This parameter sets the value of one of the following two register fields:

If you do not instantiate the Error Management Extension registers, this parameter determines the value of the EF_PTR field of the LP-Serial Lane Extended Features Block Header register at offset 0x200.
If you instantiate the Error Management Extension registers in your RapidIO II IP core variation, this parameter determines the value of the EF_PTR field of the Error Management Extensions Block Header register at offset 0x300.

Note: This parameter does not affect the Assembly Information CAR. The ExtendedFeaturesPtr in the Assembly Information CAR is set to the value of 0x100, which is the offset for the LP-Serial Extended Features block

3.6. Error Management Registers Settings

The Error Management Registers tab lists a single parameter, Enable error management extension registers.

If you turn on Enable error management extension registers, your RapidIO II IP core instantiates the Error Management Extensions register block defined in the RapidIO Interconnect Specification Part 8: Error Management Extensions Specification.

The RapidIO II IP core instantiates these registers at register block offset 0x300. If you do not instantiate these registers, you can specify user-defined registers at offset 0x300.

4. Functional Description

4.1. Interfaces

The Intel RapidIO II IP core supports the following data interfaces:

Avalon Memory Mapped (Avalon-MM) Master and Slave Interfaces
Avalon Streaming (Avalon-ST) Interface
RapidIO Interface

4.1.1. Avalon -MM Master and Slave Interfaces

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

Avalon^® -MM Interface Byte Ordering

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 64-bit 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].

Table 10. Byte Ordering
Protocol	Byte Lane (Binary)
Protocol	1000_0000	0100_0000	0010_0000	0001_0000	0000_1000	0000_0100	0000_0010	0000_0001
RapidIO Protocol (Big Endian)	Byte0 [0:7]	Byte1 [0:7]	Byte2 [0:7]	Byte3 [0:7]	Byte4 [0:7]	Byte5 [0:7]	Byte6 [0:7]	Byte7 [0:7]
	32-Bit Word[0:31] wdptr = 0				32-Bit Word[0:31] wdptr = 1
	Double Word[0:63] RapidIO Byte Address N = {29'hn, 3'b000}
Avalon^® - MM Protocol (Little Endian)	Byte7 [7:0]	Byte6 [7:0]	Byte5 [7:0]	Byte4 [7:0]	Byte3 [7:0]	Byte2 [7:0]	Byte1 [7:0]	Byte0 [7:0]
	Address = N+7	Address = N+6	Address = N+5	Address = N+4	Address = N+3	Address = N+2	Address = N+1	Address = N
	32-Bit Word[31:0] Avalon^® -MM Byte Address = N+4				32-Bit Word[31:0] Avalon^® -MM Byte Address = N
	64-bit Double Word0[63:0] Avalon^® -MM Byte Address = N

In variations of the RapidIO II IP core that have 128-bit wide Avalon^® -MM interfaces, the least significant half of the Avalon^® -MM 128-bit word corresponds to the 8-byte double word at RapidIO address N, and the most significant half of the Avalon^® -MM 128-bit word corresponds to the 8-byte double word at RapidIO address N+8. If two 8-byte double words appear in the RapidIO packet in the order dw0, followed by dw1, they appear on the 128-bit Avalon^® -MM interface as the 128-bit word {dw1, dw0}.

Table 11. Double-Word Ordering in a 128-Bit Avalon^® -MM Interface
Protocol	Avalon^® -MM Interface
RapidIO Protocol (Big Endian)	Second Transmitted Double Word[0:63] RapidIO Byte Address N + 8	First Transmitted Double Word[0:63]⁹ RapidIO Byte Address N = {29'hn, 3'b000}
Avalon^® -MM Protocol (Little Endian)	64-Bit Double Word[63:0] Avalon^® -MM Byte Address = N+8	64-Bit Double Word[63:0] Avalon^® -MM Byte Address = N

⁹ Bit 0 of the RapidIO double word is transmitted first on the RapidIO link.

4.1.2. Avalon-ST Interface

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 128 bits wide. This interface is available to create custom Logical layer functions like message passing.

4.1.3. RapidIO Interface

The RapidIO interface complies with revision 2.2 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.

4.2. Clocking and Reset Structure

All RapidIO II IP core variations have the following clock inputs:

Avalon^® system clock (sys_clk)
Reference clock for the transceiver Tx PLL and Rx PLL (tx_pll_refclk). In Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX variations, this clock port drives only the Rx PLL
Transceiver channel clocks (tx_bonding_clocks_chN). The RapidIO II IP core provides the following two clock outputs from the transceiver
Recovered data clock (rx_clkout)
Transceiver transmit-side clock (tx_clkout)

In addition, if you turn on Enable transceiver dynamic reconfiguration in the RapidIO II parameter editor, the IP core includes a reconfig_clk_chN input clock to clock the Intel^® Arria^® 10, Intel^® Stratix^® 10 or Intel^® Cyclone^® 10 GX Native PHY dynamic reconfiguration interface for each lane N.

The RapidIO II IP core can accommodate a difference of ±200 ppm between the tx_clkout and rx_clkout clocks.

4.2.1. Avalon System Clock

The Avalon system clock, sys_clk, is an input to the RapidIO II IP core that drives the Transport and Logical layer modules and most of the Physical layer module.

Note: You must drive the sys_clk clock from the same source from which you drive the tx_pll_refclk input clock.

4.2.2. Reference Clock

The reference clock, tx_pll_refclk, is the incoming reference clock for the transceiver’s PLL. You specify the reference clock frequency in the RapidIO II parameter editor when you create the RapidIO II IP core instance.

The ability to program the frequency of the input reference clock allows you to use an existing clock in your system as the reference clock for the RapidIO II IP core. This reference clock can have any of a set of frequencies that the PLL in the transceiver can convert to the required internal clock speed for the RapidIO II IP core baud rate. The choices available to you for this frequency are determined by the baud rate and target device family.

Note: You must drive the tx_pll_refclk clock from the same source from which you drive the sys_clk input clock and the TX PLL pll_refclk0 input clock. This source must be within ±100PPM of its nominal value, to ensure the difference between any two devices in the RapidIO II system is within ±200PPM.

4.2.3. Recovered Data Clock

The clock and data recovery block (CDR) in the transceiver recovers this clock, rx_clkout, from the incoming RapidIO data. The RapidIO II IP core provides this output clock as a convenience. You can use it to source a system-wide clock with a 0 ppm frequency difference from the clock used to transmit the incoming data.

4.2.4. Clock Rate Relationships in the RapidIO II IP Core

The RapidIO v2.2 specification specifies baud rates of 1.25, 2.5, 3.125, 5.0, and 6.25 Gbaud.

Table 12. Clock Frequencies in the RapidIO II IP CoreFollowing are the clock rates in the different RapidIO II IP core variations, showing the relationship between baud rate, default transceiver reference clock frequency, and Avalon system clock frequency.
Baud Rate (Gbaud)	Default reference clock frequency (MHz)¹⁰	Avalon system clock Frequency (MHz)¹¹
1.25	156.25	31.25
2.5	156.25	62.5
3.125	156.25	78.125
5.0	156.25	125.0
6.25	156.25	156.25

¹⁰ The reference clock is called tx_pll_refclk by default.

¹¹ The Avalon system clock is called sys_clk by default. It runs at 1/40 the frequency of the maximum baud rate you configure in the RapidIO II parameter editor, irrespective of the baud rate you program in software. You must drive sys_clk and the reference clock from the same clock source.

4.2.5. Clock Domains in Your Platform Designer System

In systems created with Platform Designer, 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.

4.2.6. Reset for RapidIO II IP Cores

All RapidIO II IP core variations have the following signals related to reset:

rst_n — resets the RapidIO II IP core
tx_ready, tx_analogreset, tx_digitalreset, tx_digitalreset_stat ¹², tx_analogreset_stat ¹² — reset the transmit side of the transceiver
rx_ready, rx_analogreset, rx_digitalreset, rx_digitalrest_stat ¹², rx_analogreset_stat ¹² — reset the receive side of the transceiver
pll_powerdown — reset one or more TX PLLs in the transceiver. This signal is available in Arria^® V, Arria^® V GZ, Cyclone^® V, and Stratix^® V variations only.

In addition, if you turn on Enable transceiver dynamic reconfiguration in the RapidIO II parameter editor, the IP core includes reconfig_reset_chN input signals. For each N, the reconfig_reset_chN signal resets the Intel^® Arria^® 10, Intel^® Stratix^® 10 or Intel^® Cyclone^® 10 GX Native PHY dynamic reconfiguration interface for the transceiver channel that implements RapidIO lane N.

The reset sequence and requirements vary among device families. To implement the reset sequence correctly for your RapidIO II IP core, you must connect the tx_ready, tx_analogreset, tx_digitalreset, rx_ready, rx_analogreset, rx_digitalreset , tx_digitalreset_stat, tx_analogreset_stat , rx_digitalreset_stat, rx_analogreset_stat, and pll_powerdown reset signals to the Transceiver PHY Reset Controller IP core. User logic must drive the following signals from a single reset source:

RapidIO II IP core rst_n (active low) input signal.
Transceiver PHY Reset Controller IP core reset (active high) input signal.
TX PLL pll_powerdown (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 external TX PLL configuration, your design might need to drive pll_powerdown and TX PLL mcgb_rst with different constraints.

User logic must connect the remaining input reset signals of the RapidIO II IP core to the corresponding output signals of the Transceiver PHY Reset Controller IP core.

The rst_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.

Figure 8. Circuit to Ensure Synchronous Deassertion of rst_n

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

The assertion of rst_n causes the whole RapidIO II IP core to reset. The requirement that the reset controller reset input signal and the TX PLL pll_powerdown and mcgb_rst input signals be asserted with rst_n ensures that the PHY IP core resets with the RapidIO II IP core.

User logic must assert the Transceiver PHY Reset Controller IP core reset signal with rst_n. However, each signal is deasserted synchronously with its corresponding clock.

Figure 9. Circuit to Ensure Synchronous Assertion of reset with rst_nIn this figure, clock is the Transceiver PHY Reset Controller IP core input clock. You can extend this logic as appropriate to include any additional reset signals.

In systems generated by Platform Designer, this circuit is generated automatically. However, if your RapidIO II IP core variation is not generated by Platform Designer, you must implement logic to ensure that rst_n and reset are driven from the same source, and that each meets the minimal hold time and synchronous deassertion requirements.

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.

Note: You must de-assert all IP reset signals and allow link initialization to access the Command and Status Register (CSR) block.

Consistent with normal operation, following the reset sequence, the Initialization state machine transitions to the SILENT state. In this state, the transmitters are turned off.

If two communicating RapidIO II 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.

¹² Only for Intel^® Stratix^® 10 devices.

4.3. Logical Layer Interfaces

This section describes the features of the Logical layer module interfaces and how your system can interact with these interfaces to communicate with a RapidIO link partner.

The Logical layer consists of the following optional modules:

I/O slave and master modules that initiate and terminate NREAD, NWRITE, SWRITE, and NWRITE_R transactions.
Maintenance module that initiates and terminates MAINTENANCE transactions.
Doorbell module that transacts RapidIO DOORBELL messages.
Avalon-ST pass-through interface for implementing your own custom Logical layer logic.

In addition, the Logical layer provides an Avalon-MM slave interface called the Register Access interface which provides access to all of the RapidIO II IP core registers except the Doorbell Logical layer registers. This interface is present in all RapidIO II IP core variations.

Figure 10. Functional Block Diagram with all of the Logical Layer Modules

4.3.1. Register Access Interface

All RapidIO II IP core variations include a Register Access interface. This Avalon-MM slave interface provides access to all of the registers in the RapidIO II IP core except the Doorbell Logical layer registers.

Note: The Doorbell Logical layer registers are available only in RapidIO II IP core variations that instantiate a Doorbell Logical layer module, and you must access them through the Doorbell module's Avalon-MM slave interface.

4.3.1.1. Non-Doorbell Register Access Operations

The RapidIO II IP core registers are 32 bits wide and are accessible only on a 32-bit (4-byte) basis. The addressing for the registers therefore increments by units of 4.

The Register Access interface supports simple reads and writes with variable latency. The interface provides access to 32-bit words addressed by a 22-bit wide word address, corresponding to a 24-bit wide byte address. This address space provides access to the entire RapidIO configuration space, including any user-defined registers.

A local host can access the RapidIO II IP core registers through the Register Access Avalon-MM slave interface.

If your RapidIO II IP core variation includes a Maintenance module, a remote host can access the RapidIO II IP core registers by sending MAINTENANCE transactions targeted to this local RapidIO II IP core. If the transaction is a read or write to an address in the IP core register address range, the RapidIO II IP core routes the transaction to the appropriate register internally. If the transaction is a read or write to an address outside the address ranges of the Logical layer modules instantiated in the RapidIO II IP core, the IP core routes the transaction to user logic through the Maintenance master interface.

4.3.1.2. Register Access Interface Signals

Table 13. Register Access Avalon-MM Slave Interface Signals
Signal	Direction	Description
`ext_mnt_waitrequest`	Output	Register Access slave wait request. The RapidIO II IP core uses this signal to stall the requestor on the interconnect.
`ext_mnt_read`	Input	Register Access slave read request.
`ext_mnt_write`	Input	Register Access slave write request.
`ext_mnt_address[21:0]`	Input	Register Access slave address bus. The address is a word address, not a byte address.
`ext_mnt_writedata[31:0]`	Input	Register Access slave write data bus.
`ext_mnt_readdata[31:0]`	Output	Register Access slave read data bus.
`ext_mnt_readdatavalid`	Output	Register Access slave read data valid signal supports variable-latency, pipelined read transfers on this interface.
`ext_mnt_readresponse`	Output	Register Access read error, which indicates that the read transfer did not complete successfully. This signal is valid only when the `ext_mnt_readdatavalid` signal is asserted.
`std_reg_mnt_irq`	Output	Standard registers interrupt request. This interrupt signal is associated with the error conditions registered in the Command and Status Registers (CSRs) and the Error Management Extensions registers.
`io_m_mnt_irq`	Output	I/O Logical Layer Avalon-MM Master module interrupt signal. This interrupt is associated with the conditions registered in the `Input/Output Master Interrupt` register at offset 0x103DC.
`io_s_mnt_irq`	Output	I/O Logical Layer Avalon-MM Slave module interrupt signal. This interrupt signal is associated with the conditions registered in the `Input/Output Slave Interrupt` register at offset 0x10500.
`mnt_mnt_s_irq`	Output	Maintenance slave interrupt signal. This interrupt signal is associated with the conditions registered in the `Maintenance Interrupt` register at offset 0x10080.

The interface supports the following interrupt lines:

std_reg_mnt_irq — when enabled, the interrupts registered in the CSRs and Error Management registers assert the std_reg_mnt_irq signal.
io_m_mnt_irq — this interrupt signal reports interrupt conditions related to the I/O Avalon-MM master interface. When enabled, the interrupts registered in the Input/Output Master Interrupt register at offset 0x103DC assert the io_m_mnt_irq signal.
io_s_mnt_irq — this interrupt signal reports interrupt conditions related to the I/O Avalon-MM slave interface. When enabled, the interrupts registered in the Input/Output Slave Interrupt register at offset 0x10500 assert the io_s_mnt_irq signal.
mnt_mnt_s_irq — this interrupt signal reports interrupt conditions related to the Maintenance interface slave port. When enabled, the interrupts registered in the Maintenance Interrupt register at offset 0x10080 assert the mnt_mnt_s_irq signal.

4.3.2. Input/Output Logical Layer Modules

4.3.2.1. Input/Output Avalon-MM Master Module

The Input/Output (I/O) Avalon-MM master Logical layer module is an optional component of the I/O Logical layer. This module receives RapidIO read and write request packets from a remote endpoint through the Transport layer module.

The I/O Avalon-MM master module translates the request packets into Avalon-MM transactions, and creates and returns RapidIO response packets to the source of the request through the Transport layer.

Note: The I/O Avalon-MM master module is referred to as a master module because it is an Avalon-MM interface master.

The I/O Avalon-MM master module can process a mix of NREAD and NWRITE_R requests simultaneously. The I/O Avalon-MM master module can process up to eight pending NREAD requests. If the Transport layer module receives an NREAD request packet while eight 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.

Figure 11. I/O Master Block Diagram

4.3.2.1.1. Input/Output Avalon-MM Master Interface Signals

Table 14. Input/Output Avalon-MM Master Interface Signals
Signal	Direction	Description
`iom_rd_wr_waitrequest`	Input	I/O Logical Layer Avalon-MM Master module wait request.
`iom_rd_wr_write`	Output	I/O Logical Layer Avalon-MM Master module write request.
`iom_rd_wr_read`	Output	I/O Logical Layer Avalon-MM Master module read request.
`iom_rd_wr_address[31:0]`	Output	I/O Logical Layer Avalon-MM Master module address bus.
`iom_rd_wr_writedata[127:0]`	Output	I/O Logical Layer Avalon-MM Master module write data bus.
`iom_rd_wr_byteenable[15:0]`	Output	I/O Logical Layer Avalon-MM Master module byte enable.
`iom_rd_wr_burstcount[4:0]`	Output	I/O Logical Layer Avalon-MM Master module burst count.
`iom_rd_wr_readresponse`	Input	I/O Logical Layer Avalon-MM Master module read error response.
`iom_rd_wr_readdata[127:0]`	Input	I/O Logical Layer Avalon-MM Master module read data bus.
`iom_rd_wr_readdatavalid`	Input	I/O Logical Layer Avalon-MM Master module read data valid.

The I/O Avalon-MM Master module supports an interrupt line, io_m_mnt_irq, on the Register Access interface. When enabled, the following interrupts assert the io_m_mnt_irq signal:

Address out of bounds

4.3.2.1.2. Defining the Input/Output Avalon-MM Master Address Mapping Windows

When you specify the value for Number of Rx address translation windows in the RapidIO II parameter editor, you determine the number of address translation windows available for translating incoming RapidIO read and write transactions to Avalon-MM requests on the I/O Logical layer Master port.

You must program the Input/Output Master Mapping Window registers to support the address ranges you wish to distinguish. You can disable an address translation window that is available in your configuration, but the maximum number of windows you can program is the number you specify in the RapidIO II parameter editor with the Number of Rx address translation windows value.

The RapidIO II IP core includes one set of Input/Output Master Mapping Window registers for each translation window. The following registers define address translation window n:

A base register: Input/Output Master Mapping Window n Base
A mask register: Input/Output Master Mapping Window n Mask
An offset register: Input/Output Master Mapping Window n Offset

You can change the values of the window defining registers at any time. You should disable a window before changing its window defining registers.

To enable a window, set the window enable (WEN) bit of the window’s Input/Output Master Mapping Window n Mask register to the value of 1. To disable it, set the WEN bit to the value of zero.

For each defined and enabled window, the RapidIO II IP core masks out the RapidIO address's least significant bits with the window mask and compares the resulting address to the window base.

The matching window is the lowest numbered window for which the following equation holds:

(rio_addr[33:4] & {xamm[1:0], mask[31:4]}) == ({xamb[1:0], base[31:4]} & {xamm[1:0], mask[31:4]})

where:

rio_addr[33:0] is the 34-bit RapidIO address composed of {xamsbs[1:0],address[28:0],3b’000} for RapidIO header fields xamsbs and address.
mask[31:0] is composed of {Mask register[31:4], 4b’0000}.
base[31:0] is composed of {Base register[31:4], 4b’0000}.
xamm[1:0] is the XAMM field of the I/O Master Mapping Window n Mask register.
xamb[1:0] is the XAMB field of the I/O Master Mapping Window n Base register.

The RapidIO II IP core determines the Avalon-MM address from the least significant bits of the RapidIO address and the matching window offset using the following equation:

Avalon-MM address[31:4] = (offset[31:4] & mask[31:4]) | (rio_addr[31:4] & ~mask[31:4])

where:

offset[31:0] is the offset register. The least significant four bits of this register are always 4’b0000.
The definitions of all other terms in the equation appear in the definition of the matching window.

The value of the Avalon-MM address[3:0] is always zero, because the address is a byte address and the I/O Logical layer master interface has a 128-bit wide datapath.

If the address does not match any window the I/O Logical layer Master module performs the following actions:

Sets the Illegal Transaction Decode Error bit in the Error Management Extension registers.
Sets the ADDRESS_OUT_OF_BOUNDS interrupt bit in the Input/Output Master Interrupt register.
Asserts the interrupt signal io_m_mnt_irq if this interrupt is enabled by the corresponding bit in the Input/Output Master Interrupt Enable register.
For a received NREAD or NWRITE_R request packet that does not match any enabled window, returns a RapidIO ERROR response packet.

User logic can clear an interrupt by writing 1 to the interrupt register’s corresponding bit location.

Figure 12. I/O Master Window Translation

4.3.2.1.3. RapidIO Packet Data Word Pointer and Size Encoding in Avalon -MM Transactions

The RapidIO II IP core converts RapidIO packets to Avalon^® -MM transactions. The RapidIO packet's read size, write size, and word pointer fields, and the least significant bit of the address field, are translated to the Avalon^® -MM burst count and byteenable values.

Table 15. Avalon^® -MM I/O Master Read Transaction Burstcount and Byteenable
RapidIO Field Values			Avalon^® -MM Signal Values
rdsize (4'bxxxx)	wdptr (1'bx)	address[0] (1'bx)	Burstcount	Byteenable (16'bxxxxxxxxxxxxxxxx)
0000	0	0	1	0000_0000_1000_0000
	0	1	1	1000_0000_0000_0000
	1	0	1	0000_0000_0000_1000
	1	1	1	0000_1000_0000_0000
0001	0	0	1	0000_0000_0100_0000
	0	1	1	0100_0000_0000_0000
	1	0	1	0000_0000_0000_0100
	1	1	1	0000_0100_0000_0000
0010	0	0	1	0000_0000_0010_0000
	0	1	1	0010_0000_0000_0000
	1	0	1	0000_0000_0000_0010
	1	1	1	0000_0010_0000_0000
0011	0	0	1	0000_0000_0001_0000
	0	1	1	0001_0000_0000_0000
	1	0	1	0000_0000_0000_0001
	1	1	1	0000_0001_0000_0000
0100	0	0	1	0000_0000_1100_0000
	0	1	1	1100_0000_0000_0000
	1	0	1	0000_0000_0000_1100
	1	1	1	0000_1100_0000_0000
0101 ¹³	0	0	1	0000_0000_1110_0000
	0	1	1	1110_0000_0000_0000
	1	0	1	0000_0000_0000_0111
	1	1	1	0000_0111_0000_0000
0110	0	0	1	0000_0000_0011_0000
	0	1	1	0011_0000_0000_0000
	1	0	1	0000_0000_0000_0011
	1	1	1	0000_0011_0000_0000
0111¹³	0	0	1	0000_0000_1111_1000
	0	1	1	1111_1000_0000_0000
	1	0	1	0000_0000_0001_1111
	1	1	1	0001_1111_0000_0000
1000	0	0	1	0000_0000_1111_0000
	0	1	1	1111_0000_0000_0000
	1	0	1	0000_0000_0000_1111
	1	1	1	0000_1111_0000_0000
1001¹³	0	0	1	0000_0000_1111_1100
	0	1	1	1111_1100_0000_0000
	1	0	1	0000_0000_0011_1111
	1	1	1	0011_1111_0000_0000
1010¹³	0	0	1	0000_0000_1111_1110
	0	1	1	0000_0000_0111_1111
	1	0	1	1111_1110_0000_0000
	1	1	1	0111_1111_0000_0000
1011	0	0	1	0000_0000_1111_1111
	0	1	1	1111_1111_0000_0000
	1	0	1	1111_1111_1111_1111
	1	1	Reserved¹⁴
1100 ¹⁵	0	0	2	1111_1111_1111_1111
1100 ¹⁵	1	0	4	1111_1111_1111_1111
1101¹⁵	0	0	6	1111_1111_1111_1111
1101¹⁵	1	0	8	1111_1111_1111_1111
1110¹⁵	0	0	10	1111_1111_1111_1111
1110¹⁵	1	0	12	1111_1111_1111_1111
1111¹⁵	0	0	14	1111_1111_1111_1111
1111¹⁵	1	0	16	1111_1111_1111_1111

Table 16. Avalon^® -MM I/O Master Write Transaction Burstcount and Byteenable IFor `wrsize` value less than 4’b1100:
RapidIO Field Values			Avalon^® -MM Signal Values
wrsize (4'bxxxx)	wdptr (1'bx)	address[0] (1'bx)	Burstcount	Byteenable (16'bxxxx_xxxx_xxxx_xxxx)
0000	0	0	1	0000_0000_1000_0000
	0	1	1	1000_0000_0000_0000
	1	0	1	0000_0000_0000_1000
	1	1	1	0000_1000_0000_0000
0001	0	0	1	0000_0000_0100_0000
	0	1	1	0100_0000_0000_0000
	1	0	1	0000_0000_0000_0100
	1	1	1	0000_0100_0000_0000
0010	0	0	1	0000_0000_0010_0000
	0	1	1	0010_0000_0000_0000
	1	0	1	0000_0000_0000_0010
	1	1	1	0000_0010_0000_0000
0011	0	0	1	0000_0000_0001_0000
	0	1	1	0001_0000_0000_0000
	1	0	1	0000_0000_0000_0001
	1	1	1	0000_0001_0000_0000
0100	0	0	1	0000_0000_1100_0000
	0	1	1	1100_0000_0000_0000
	1	0	1	0000_0000_0000_1100
	1	1	1	0000_1100_0000_0000
0101 ¹⁶	0	0	1	0000_0000_1110_0000
	0	1	1	0000_0000_0000_0111
	1	0	1	1110_0000_0000_0000
	1	1	1	0000_0111_0000_0000
0110	0	0	1	0000_0000_0011_0000
	0	1	1	0000_0000_0000_0011
	1	0	1	0011_0000_0000_0000
	1	1	1	0000_0011_0000_0000
0111¹⁶	0	0	1	0000_0000_1111_1000
	0	1	1	0000_0000_0001_1111
	1	0	1	1111_1000_0000_0000
	1	1	1	0001_1111_0000_0000
1000	0	0	1	0000_0000_1111_0000
	0	1	1	1111_0000_0000_0000
	1	0	1	0000_0000_0000_1111
	1	1	1	0000_1111_0000_0000
1001¹⁶	0	0	1	0000_0000_1111_1100
	0	1	1	0000_0000_0011_1111
	1	0	1	1111_1100_0000_0000
	1	1	1	0011_1111_0000_0000
1010¹⁶	0	0	1	0000_0000_1111_1110
	0	1	1	0000_0000_0111_1111
	1	0	1	1111_1110_0000_0000
	1	1	1	0111_1111_0000_0000
1011	0	0	1	0000_0000_1111_1111
	0	1	1	1111_1111_0000_0000
	1	0	1	1111_1111_1111_1111
	1	1	2	First clock cycle: 1111_1111_0000_0000 Second clock cycle: 0000_0000_1111_1111

Table 17. Avalon^® -MM I/O Master Write Transaction Burstcount and Byteenable IIFor `wrsize` value greater than 4’b1011:
RapidIO Values			Avalon^® -MM Signal Values
RapidIO Field Values		Payload Size is Multiple of 16 Bytes¹⁷	Burstcount	Byteenable (16'hXXXX)
wrsize (4'bxxxx)	address[0] (1'bx)	Payload Size is Multiple of 16 Bytes¹⁷	Burstcount	First Cycle	Intermediate Cycles	Final Cycle
1100–1111	0	Yes	Payload size in bytes / 16	FFFF	FFFF	FFFF
	1	Yes	Payload size in bytes / 16 plus 1	FF00	FFFF	00FF
	0	No	¹⁸	FFFF	FFFF	00FF
	1	No	¹⁸	FF00	FFFF	FFFF

¹³ The RapidIO link partner should avoid read requests with this rdsize value, because the resulting byteenable value is not allowed by the Avalon^® -MM specification. However, if the RapidIO II IP core receives a read request with this rdsize value, the IP core issues these transactions on the I/O Logical layer Avalon^® -MM master interface with the illegal byteenable values, to support systems in which user logic handles these byteenable values.

¹⁴ This combination of wdptr and rdsize values is reserved. If the RapidIO II IP core receives this combination, it sets the Unsupported Transaction bit (UNSUPPORT_TRAN) in the Logical/Transport Layer Error Detect CSR and returns an ERROR response.

¹⁵ If rdsize has a value greater than 4’b1011, and address[0] has the value of 1, the RapidIO II IP core sets the Unsupported Transaction bit (UNSUPPORT_TRAN) in the Logical/Transport Layer Error Detect CSR and returns an ERROR response.

¹⁶ The RapidIO link partner should avoid this combination of wdptr and wrsize values, because the resulting byteenable value presented on the Avalon^® -MM master interface is not allowed by the Avalon^® -MM specification.

¹⁷ If the packet payload is larger than the maximum size allowed for the packet wrsize and wdptr values, the RapidIO II IP core records an Illegal transaction decode error in the Error Management Extension registers and, for NWRITE_R request packets, returns an ERROR response.

¹⁸ If the payload size is not a multiple of 16 bytes, and address[0] has the value of zero, the value of burstcount is the number of 8-byte words in the packet payload, divided by two, and rounded up.

4.3.2.1.4. Input/Output Avalon-MM Master Module Timing Diagrams

The RapidIO II IP core receives both transaction requests on the RapidIO link and sends them to the Logical layer Avalon-MM master module. Timing diagrams shows the timing dependencies on the Avalon-MM master interface for an incoming RapidIO NREAD and NWRITE transaction.

Figure 13. NREAD Transaction on the Input/Output Avalon-MM Master Interface

Figure 14. NWRITE Transaction on the Input/Output Avalon-MM Master Interface

4.3.2.2. Input/Output Avalon-MM Slave Module

The Input/Output (I/O) Avalon-MM slave Logical layer module is an optional component of the I/O Logical layer. The I/O Avalon-MM slave Logical layer module receives Avalon-MM transactions from user logic and converts these transactions to RapidIO read and write request packets. The module sends the RapidIO packets to the Transport layer, to be sent on the RapidIO link. For each RapidIO read or write request, the target remote RapidIO processing element implements the actual read or write transaction and sends back a response if required. Avalon-MM read transactions complete when the RapidIO II IP core receives and processes the corresponding response packet.

Note:

The I/O Avalon-MM slave module is referred to as a slave module because it is an Avalon-MM interface slave.
The maximum number of outstanding transactions (I/O Requests) the RapidIO II IP core supports on this interface is 16 (8 NREAD requests + 8 NWRITE_R requests).

Figure 15. Input/Output Avalon-MM Slave Logical Layer Block Diagram

4.3.2.2.1. Input/Output Avalon-MM Slave Interface Signals

Table 18. Input/Output Avalon-MM Slave Interface Signals
Signal	Direction	Description
`ios_rd_wr_waitrequest`	Output	I/O Logical Layer Avalon-MM Slave module wait request.
`ios_rd_wr_write`	Input	I/O Logical Layer Avalon-MM Slave module write request.
`ios_rd_wr_read`	Input	I/O Logical Layer Avalon-MM Slave module read request.
`ios_rd_wr_address[N:0]` for N == 9, 10,..., or 31	Input	I/O Logical Layer Avalon-MM Slave module address bus. The address is a quad-word address, addresses a 16-byte (128-bit) quad-word, not a byte address. You can determine the width of the `ios_rd_wr_address` bus in the RapidIO II parameter editor.
`ios_rd_wr_writedata[127:0]`	Input	I/O Logical Layer Avalon-MM Slave module write data bus.
`ios_rd_wr_byteenable[15:0]`	Input	I/O Logical Layer Avalon-MM Slave module byte enable.
`ios_rd_wr_burstcount[4:0]`	Input	I/O Logical Layer Avalon-MM Slave module burst count.
`ios_rd_wr_readresponse`	Output	I/O Logical Layer Avalon-MM Slave module read error response. I/O Logical Layer Avalon-MM Slave module read error. Indicates that the burst read transfer did not complete successfully.
`ios_rd_wr_readdata[127:0]`	Output	I/O Logical Layer Avalon-MM Slave module read data bus.
`ios_rd_wr_readdatavalid`	Output	I/O Logical Layer Avalon-MM Slave module read data valid.

The I/O Avalon-MM Slave module supports an interrupt line, io_s_mnt_irq, on the Register Access interface. When enabled, the following interrupts assert the io_s_mnt_irq signal:

Read out of bounds
Write out of bounds
Invalid write
Invalid read or write burstcount
Invalid read or write byteenable value

4.3.2.2.2. Initiating Read and Write Transactions

To initiate a read or write transaction on the RapidIO link, your system sends a read or write request to the I/O Logical layer Slave module Avalon-MM interface.

IP Core Actions

In response to incoming Avalon-MM read requests to the I/O Logical layer Slave module, the RapidIO II IP core generates read request packets on the RapidIO link, by performing the following tasks:

For each incoming Avalon-MM read request, composes the RapidIO read request packet.
For each incoming Avalon-MM write request, composes the RapidIO write request packet
Maintains status related to the composed packet to track responses:
- Sends read request information to the Pending Reads buffer to wait for the corresponding response packet.
- Sends NWRITE_R request information to the Pending Writes buffer to wait for the corresponding response packet.
- Does not send SWRITE and NWRITE request information to the Pending Writes buffer, because these transactions do not require a response to the user on the I/O Logical layer Avalon-MM slave interface.
Presents the composed packet to the Transport layer for transmission on the RapidIO link.
For each read response from the Transport layer, removes the original request entry from the Pending Reads buffer and uses the packet’s payload to complete the read transaction, by sending the read data on the Avalon-MM slave interface.
For each write response from the Transport layer, removes the original request entry from the Pending Writes buffer.

Note: At any time, the I/O Logical layer Slave module can maintain a maximum of eight outstanding read requests and a maximum of eight outstanding write requests. The module asserts the ios_rd_wr_waitrequest signal to throttle incoming requests above the limit.

The RapidIO II IP core performs the following actions in response to each read request transaction the I/O Logical layer Slave module processes:

If the IP core receives a read response packet on the RapidIO link, the read operation was successful. After the I/O Logical layer Slave module receives the response packet from the Transport layer, it passes the read response and data from the Pending Reads buffer back through the Avalon-MM slave interface.
If the remote processing element is busy, the RapidIO II IP core resends the request packet.
If an error or time-out occurs, the I/O Logical layer Slave module asserts the ios_rd_wr_readresponse signal on the Avalon-MM slave interface and captures some information in the Error Management Extension registers.

The RapidIO II IP core assigns a time-out value to each outbound request that requires a response—each NWRITE_R or NREAD transaction. The time-out value 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.

Tracking I/O Write Transactions

The following three registers are available to software to track the status of I/O write transactions:

The Input/Output Slave Avalon-MM Write Transactions register holds a count of the write transactions that have been initiated on the write Avalon-MM slave interface.
The Input/Output Slave RapidIO Write Requests register holds a count of the RapidIO write request packets that have been transferred to the Transport layer.
The Input/Output Slave Pending NWRITE_R Transactions register holds a count of the NWRITE_R requests that have been issued but have not yet completed.

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.

4.3.2.2.3. Defining the Input/Output Avalon-MM Slave Address Mapping Windows

When you specify the value for Number of Tx address translation windows in the RapidIO II parameter editor, you determine the number of address translation windows available for translating incoming Avalon-MM read and write transactions to RapidIO read and write requests.

You must program the Input/Output Slave Mapping Window registers to support the address ranges you wish to distinguish. You can disable an address translation window that is available in your configuration, but the maximum number of windows you can program is the number you specify in the RapidIO II parameter editor with the Number of Tx address translation windows value.

The RapidIO II IP core includes one set of Input/Output Slave Mapping Window registers for each translation window. The following registers define address translation window n:

A base register: Input/Output Slave Mapping Window n Base
A mask register: Input/Output Slave Mapping Window n Mask
An offset register: Input/Output Slave Mapping Window n Offset
A control register: Input/Output Slave Mapping Window n Control

The control register stores information the RapidIO II IP core uses to prepare the RapidIO packet header, including the target device’s destination ID, the request packet's priority, and to select 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.

To enable a window, set the window enable (WEN) bit of the window’s Input/Output Slave Mapping Window n Mask register to the value of 1. To disable it, set the WEN bit to the value of zero.

For each defined and enabled window, the RapidIO II IP core masks out the RapidIO address's least significant bits with the window mask and compares the resulting address to the window base.

The matching window is the lowest numbered window n for which the following equation holds:

(ios_rd_wr_addr[31:4] & mask[31:4]) == (base[31:4] & mask[31:4])

where:

ios_rd_wr_addr[31:0] is the I/O Logical layer Avalon-MM slave address bus. If the field has fewer than 32 bits, the IP core pads the actual bus value with leading zeroes for the matching comparison.
mask[31:4] is the MASK field of the Input/Output Slave Mapping Window n Mask register.
base[31:4] is the BASE field of the Input/Output Slave Mapping Window n Base register.

The RapidIO II IP core determines the value for the RapidIO packet header xamsbs and address fields from the least significant bits of the Avalon-MM ios_rd_wr_address signal and the matching window offset using the following equation:

rio_addr [33:4] = {xamo, ((offset [31:4] & mask [31:4]) | ios_rd_wr_address[31:4])}

where:

rio_addr[33:0] is the 34-bit RapidIO address composed of {xamsbs[1:0],address[28:0],3b’000} for RapidIO header fields xamsbs and address.
xamo[1:0] is the XAMO field of the Input/Output Slave Mapping Window n Offset register.
offset[31:4] is the OFFSET field of the Input/Output Slave Mapping Window n Offset register.
The definitions of all other terms in the equation appear in the definition of the matching window.

If the address does not match any window the I/O Logical layer Slave module performs the following actions:

Sets the WRITE_OUT_OF_BOUNDS or READ_OUT_OF_BOUNDS interrupt bit in the Input/Output Slave Interrupt register.
Asserts the interrupt signal io_s_mnt_irq if this interrupt is enabled by the corresponding bit in the Input/Output Slave Interrupt Enable register.
Increments the COMPLETED_OR_CANCELLED_WRITES field of the Input/Output Slave RapidIO Write Requests register if the transaction is a write request.

User logic can clear an interrupt by writing 1 to the interrupt register’s corresponding bit location.

The Avalon-MM slave interface burstcount and byteenable signals determine the values of the RapidIO packet header fields wdptr and rdsize or wrsize.

The RapidIO II IP core copies the values you program in the PRIORITY and DESTINATION_ID fields of the control register for the matching window, to the RapidIO packet header fields prio and destinationID, respectively.

4.3.2.2.4. Input/Output Slave Translation Window Example

This section contains an example illustrating the use of I/O slave translation windows.

Figure 16. Input/Output Slave Window Translation

In this example, a RapidIO II IP core with 8-bit device ID communicates with three other processing endpoints through three I/O slave translation windows. For this example, the XAMO bits are set to 2'b00 for all three windows. The offset value differs for each window, which results in the segmentation of the RapidIO address space that is shown below:

Figure 17. Input/Output Slave Translation Window Address Mapping

In the example, the two most significant bits of the Avalon-MM address are used to differentiate between the processing endpoints.

Translation Window 0

An Avalon-MM address in which the two most significant bits have the value 2'b01 matches window 0. The RapidIO transaction corresponding to the Avalon-MM operation has a destination ID value of 0x55. This value corresponds to processing endpoint 0.

Figure 18. Translation Window 0

Translation Window 1

An Avalon-MM address in which the two most significant bits have a value of 2'b10 matches window 1. The RapidIO transaction corresponding to the Avalon-MM operation has a destination ID value of 0xAA. This value corresponds to processing endpoint 1.

Figure 19. Translation Window 1

Translation Window 2

An Avalon-MM address in which the two most significant bits have a value of 2'b11 matches window 2. The RapidIO transaction corresponding to the Avalon-MM operation has a destination ID value of 0xCC. This value corresponds to processing endpoint 2.

Figure 20. Translation Window 2

4.3.2.3. Avalon -MM Burstcount and Byteenable Encoding in RapidIO Packets

The RapidIO II IP core converts Avalon^® -MM transactions to RapidIO packets. The IP translates the Avalon^® -MM burst count, byteenable, and address bit 3 values to the RapidIO packet read size, write size, and word pointer fields.

Table 19. I/O Logical Layer Slave Read or Write Request Size EncodingFollowing are the allowed Avalon^® -MM ios_rd_wr_byteenable values if ios_rd_wr_burstcount has the value of 1, and the corresponding encoding in the packet header fields of a RapidIO read or write request packet.
Avalon^® -MM Signal Values¹⁹		RapidIO Header Field Values
burstcount (5'dx, 128-bit units)	byteenable (16'bxxxx_xxxx_xxxx_xxxx)	wdptr (1'bx)	rdsize or wrsize (4'bxxxx)	address[0] (rio_addr[3])
1	0000_0000_0000_0001	1	0011	0
1	0000_0000_0000_0010	1	0010	0
1	0000_0000_0000_0100	1	0001	0
1	0000_0000_0000_1000	1	0000	0
1	0000_0000_0001_0000	0	0011	0
1	0000_0000_0010_0000	0	0010	0
1	0000_0000_0100_0000	0	0001	0
1	0000_0000_1000_0000	0	0000	0
1	0000_0001_0000_0000	1	0011	1
1	0000_0010_0000_0000	1	0010	1
1	0000_0100_0000_0000	1	0001	1
1	0000_1000_0000_0000	1	0000	1
1	0001_0000_0000_0000	0	0011	1
1	0010_0000_0000_0000	0	0010	1
1	0100_0000_0000_0000	0	0001	1
1	1000_0000_0000_0000	0	0000	1
1	0000_0000_0000_0011	1	0110	0
1	0000_0000_0000_1100	1	0100	0
1	0000_0000_0011_0000	0	0110	0
1	0000_0000_1100_0000	0	0100	0
1	0000_0011_0000_0000	1	0110	1
1	0000_1100_0000_0000	1	0100	1
1	0011_0000_0000_0000	0	0110	1
1	1100_0000_0000_0000	0	0100	1
1	0000_0000_0000_1111	1	1000	0
1	0000_0000_1111_0000	0	1000	0
1	0000_1111_0000_0000	1	1000	1
1	1111_0000_0000_0000	0	1000	1
1	0000_0000_1111_1111	0	1011	0
1	1111_1111_0000_0000	0	1011	1
1	1111_1111_1111_1111	1	1011	0

Table 20. I/O Logical Layer Slave Read Request Size EncodingFor read requests, if `ios_rd_wr_burstcount` has a value greater than 1, the only valid value for `ios_rd_wr_byteenable` is the value of 16’xFFFF. Following are the encoding in the packet header fields of a RapidIO read or write request packet when ios_rd_wr_burstcount has a value greater than 1.
Avalon^® -MM Signal Values²⁰		RapidIO Header Field Values
burstcount (5'dx, 128-bit units) ²¹	byteenable (16'hxxxx)	wdptr (1'bx)	rdsize (4'bxxxx)²¹	address[0] (rio_addr[3])
2	FFFF	0	1100	0
3	FFFF	1	1100	0
4	FFFF	1	1100	0
5	FFFF	0	1101	0
6	FFFF	0	1101	0
7	FFFF	1	1101	0
8	FFFF	1	1101	0
9	FFFF	0	1110	0
10	FFFF	0	1110	0
11	FFFF	1	1110	0
12	FFFF	1	1110	0
13	FFFF	0	1111	0
14	FFFF	0	1111	0
15	FFFF	1	1111	0
16	FFFF	1	1111	0

Table 21. I/O Logical Layer Slave Write Request Size EncodingFor write requests, if `ios_rd_wr_burstcount` has a value greater than 1, the value of `ios_rd_wr_byteenable` can be different in the first, intermediate, and final clock cycles of the same request. In all intermediate clock cycles (when `ios_rd_wr_burstcount` has a value greater than 2), `ios_rd_wr_byteenable` must have the value of 16’xFFFF. Following are the allowed Avalon^® -MM `ios_rd_wr_burstcount` and initial and final clock cycle `ios_rd_wr_byteenable` value combinations if the value of `ios_rd_wr_burstcount` is greater than 1, and their encoding in the packet header fields of a RapidIO write request packet.
Avalon^® -MM Signal Values²²			RapidIO Header Field Values
burstcount (Decimal, 128-bit units)	byteenable (16'hxxxx)		wdptr (1'bx)	wrsize (4'bxxxx)	address[0] (rio_addr[3])
burstcount (Decimal, 128-bit units)	Initial	Final	wdptr (1'bx)	wrsize (4'bxxxx)	address[0] (rio_addr[3])
2	FF00	00FF	1	1011	1
	FF00	FFFF	0	1100	1
	FFFF	00FF	0	1100	0
	FFFF	FFFF	0	1100	0
3	FF00	00FF	0	1100	1
	FF00	FFFF	1	1100	1
	FFFF	00FF	1	1100	0
	FFFF	FFFF	1	1100	0
4	FF00	00FF	1	1100	1
	FF00	FFFF	1	1100	1
	FFFF	00FF	1	1100	0
	FFFF	FFFF	1	1100	0
5	FF00	00FF	1	1100	1
	FF00	FFFF	1	1101	1
	FFFF	00FF	1	1101	0
	FFFF	FFFF	1	1101	0
6	FF00	00FF	1	1101	1
	FF00	FFFF	1	1101	1
	FFFF	00FF	1	1101	0
	FFFF	FFFF	1	1101	0
7	FF00	00FF	1	1101	1
	FF00	FFFF	1	1101	1
	FFFF	00FF	1	1101	0
	FFFF	FFFF	1	1101	0
8	FF00	00FF	1	1101	1
	FF00	FFFF	1	1101	1
	FFFF	00FF	1	1101	0
	FFFF	FFFF	1	1101	0
9	FF00	00FF	1	1101	1
	FF00	FFFF	1	1111	1
	FFFF	00FF	1	1111	0
	FFFF	FFFF	1	1111	0
10, 11, ..., 16	FF00	00FF	1	1111	1
	FF00	FFFF	1	1111	1
	FFFF	00FF	1	1111	0
	FFFF	FFFF	1	1111	0
17	FF00	00FF	1	1111	1

¹⁹ For read transfers, the I/O Logical layer slave module does not handle byteenable values and byteenable-burstcount combinations that the Avalon^® -MM interface does not allow. In case of an invalid combination, the RapidIO II IP core asserts the ios_rd_wr_readresponse signal when it asserts the ios_rd_wr_readdatavalid signal, and sets the INVALID_READ_BYTEENABLE bit of the I/O Slave Interrupt register if this interrupt is enabled in theI/O Slave Interrupt Enable register.

²⁰ The I/O Logical layer slave module does not handle byteenable values and byteenable-burstcount combinations that the Avalon^® -MM interface does not allow. In case of an invalid byteenable or burstcount value, the RapidIO II IP core asserts the ios_rd_wr_readresponse signal when it asserts the ios_rd_wr_readdatavalid signal, and sets the INVALID_READ_BYTEENABLE bit or the INVALID_READ_BURSTCOUNT bit (or both) of theI/O Slave Interrupt register if this interrupt is enabled in the I/O Slave Interrupt Enable register.

²¹ For read transfers, the read size of the request packet is rounded up to the next supported size, but only the number of words corresponding to the requested read burst size is returned.

²² The I/O Logical layer slave module does not handle byteenable values and byteenable-burstcount combinations that the Avalon^® -MM interface does not allow. In case of an invalid byteenable or burstcount value, the RapidIO II IP core sets the INVALID_WRITE_BYTEENABLE bit or the INVALID_WRITE_BURSTCOUNT bit (or both) of the I/O Slave Interrupt register if this interrupt is enabled in the I/O Slave Interrupt Enable register.

4.3.2.4. Input/Output Avalon -MM Slave Module Timing Diagrams

Both transaction requests are initiated by local user logic and appear on the Avalon^® -MM interface of the slave module. Timing diagrams shows the timing dependencies on the Avalon^® -MM slave interface for an outgoing RapidIO NREAD request and NWRITE transaction.

Figure 21. NREAD Transaction on the Input/Output Avalon^® -MM Slave Interface

Figure 22. NWRITE Transaction on the Input/Output Avalon^® -MM Slave Interface

4.3.3. Maintenance Module

The Maintenance module is an optional component of the I/O Logical layer. The Maintenance module processes MAINTENANCE transactions, including the following transactions:

Type 8 – MAINTENANCE read and write requests and responses
Type 8 – Port-write packets

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

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

The data bus on the Maintenance Avalon-MM interface is 32 bits wide.

The Avalon-MM master interface allows you to respond to a MAINTENANCE read or write operation on the RapidIO link. The Avalon-MM master interface supports the following Avalon transfers:

Single master write transfer
Pipelined master read transfers

Note: MAINTENANCE read and write operations that target the address range for the RapidIO II IP core registers do not appear on the Avalon-MM master interface. Instead, the RapidIO II IP core routes them internally to implement the register read and write operations.

MAINTENANCE port-write transactions do not appear on the Maintenance Avalon-MM interface.

4.3.3.1. Maintenance Interface Transactions

The Maintenance slave module accepts read and write transactions from the Avalon-MM interconnect, converts them to RapidIO MAINTENANCE request packets, and sends them to the Transport layer of the RapidIO II IP core, to be sent to the Physical layer and transmitted on the RapidIO link. The Maintenance slave module uses the valid MAINTENANCE response packets that it receives on the RapidIO link to complete the read transactions on the Maintenance slave interface.

The Maintenance master module executes register read and write transactions in response to MAINTENANCE requests that the RapidIO II IP core receives on the RapidIO link, and sends the appropriate MAINTENANCE response packets.

4.3.3.2. Maintenance Interface Signals

Table 22. Maintenance Avalon-MM Slave Interface Signals
Signal	Direction	Description
`mnt_s_waitrequest`	Output	Maintenance slave wait request.
`mnt_s_read`	Input	Maintenance slave read request.
`mnt_s_write`	Input	Maintenance slave write request.
`mnt_s_address[23:0]`	Input	Maintenance slave address bus. The address is a word address, not a byte address.
`mnt_s_writedata[31:0]`	Input	Maintenance slave write data bus.
`mnt_s_readdata[31:0]`	Output	Maintenance slave read data bus.
`mnt_s_readdatavalid`	Output	Maintenance slave read data valid.
`mnt_s_readerror`	Output	Maintenance slave read error, which indicates that the read transfer did not complete successfully. This signal is valid only when the `mnt_s_readdatavalid` signal is asserted.

The Maintenance module supports an interrupt line, mnt_mnt_s_irq, on the Register Access interface. When enabled, the following interrupts assert the mnt_mnt_s_irq signal:

Received port-write.
Various error conditions, including a MAINTENANCE read request or MAINTENANCE write request that targets an out-of-bounds address.

Table 23. Maintenance Avalon-MM Master Interface Signals
Signal	Direction	Description
`usr_mnt_waitrequest`	Input	Maintenance master wait request.
`usr_mnt_read`	Output	Maintenance master read request.
`usr_mnt_write`	Output	Maintenance master write request.
`usr_mnt_address[31:0]`	Output	Maintenance master address bus.
`usr_mnt_writedata[31:0]`	Output	Maintenance master write data bus.
`usr_mnt_readdata[31:0]`	Input	Maintenance master read data bus.
`usr_mnt_readdatavalid`	Input	Maintenance master read data valid.

4.3.3.3. Initiating MAINTENANCE Read and Write Transactions

To initiate a MAINTENANCE read or write transaction on the RapidIO link, your system executes a read or write transfer on the Maintenance Avalon-MM slave interface.

4.3.3.3.1. IP Core Actions

In response to incoming Avalon-MM requests to the Maintenance module slave interface, the RapidIO II IP core Maintenance module generates MAINTENANCE requests on the RapidIO link, by performing the following tasks:

For each incoming Avalon-MM read request, composes the RapidIO MAINTENANCE read request packet.
For each incoming Avalon-MM write request, composes the RapidIO MAINTENANCE write request packet.
Maintains status related to the composed MAINTENANCE packet to track responses.
Presents the composed MAINTENANCE packet to the Transport layer for transmission on the RapidIO link.

Note: At any time, the Maintenance module can maintain a maximum of 64 outstanding MAINTENANCE requests that can be MAINTENANCE reads, MAINTENANCE writes, or port-write requests. The Maintenance module slave port asserts the mnt_s_waitrequest signal to throttle incoming requests above the limit.

4.3.3.4. Defining the Maintenance Address Translation Windows

Two address translation windows available for interpreting incoming Avalon-MM requests to the Maintenance module slave interface.

You must program the Tx Maintenance Window registers to support the address ranges you wish to distinguish. The RapidIO II IP core Maintenance module populates the following RapidIO Type 8 Request packet fields with values you program for the relevant address translation window:

prio
destinationID
hop_count

You can disable an address translation window that is available in your configuration.

The RapidIO II IP core includes one set of Tx Maintenance Mapping Window registers for each translation window. The following registers define address translation window n:

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

To enable a window, set the window enable (WEN) bit of the window’s Tx Maintenance Window n Mask register to the value of 1. To disable it, set the WEN bit to the value of zero.

For each defined and enabled window, the RapidIO II IP core masks out the Avalon-MM address's least significant bits with the window mask and compares the resulting address to the window base. If the address matches multiple windows, the IP core uses the lowest number matching window.

After determining the appropriate matching window, the RapidIO II IP core creates the 21-bit config_offset value in the converted MAINTENANCE transaction 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 signal, which holds bits [25:2] of the 26-bit byte address
mask[31:0] is the mask register
base[31:0] is the base address register
offset[23:0] is the OFFSET field of the window offset register

4.3.3.5. Responding to MAINTENANCE Read and Write Requests

To respond to a MAINTENANCE read or write request packet it receives on the RapidIO link, the RapidIO II IP core sends a read or write request to the Maintenance module master interface.

4.3.3.5.1. IP Core Actions

In response to incoming MAINTENANCE requests on the RapidIO link that do not target the RapidIO II IP core internal register set, the RapidIO II IP core Maintenance module generates Avalon-MM requests on the Maintenance module master interface, by performing the following tasks:

For a MAINTENANCE read, converts the received request packet to an Avalon read request and presents it across the Maintenance Avalon-MM master interface.
For a MAINTENANCE write, converts the received request packet to an Avalon write transfer and presents it across the Maintenance Avalon-MM master interface.
For each Avalon read request the IP core presents on the Maintenance Avalon-MM master interface, the Maintenance module accepts the data response, generates a Type 8 Response packet, and presents the response packet to the Transport layer for transmission on the RapidIO link.

The Maintenance module only supports single 32-bit word transfers, that is, rdsize and wrsize = 4’b1000. If the RapidIO II IP core receives a MAINTENANCE request on the RapidIO link with a different value in this field, the IP core sends an error response packet on the RapidIO link, and no transfer occurs.

The RapidIO II IP core uses the wdptr and config_offset values in the incoming RapidIO request packet to generate the Avalon-MM address in the transaction it presents on the Maintenance module master interface, using the following formula:

usr_mnt_address = {8’h00, config_offset, ~wdptr, 2'b00}

The IP core presents the data in the RapidIO transaction payload field on the usr_mnt_writedata[31:0] bus.

4.3.3.6. Handling Port-Write Transactions

The RapidIO II IP core supports RapidIO MAINTENANCE port-write transactions. However, these transactions do not appear on the Maintenance Avalon-MM interface.

Your system controls the transmission of port-write transactions on the RapidIO link by programming RapidIO II IP core transmit port-write registers using the Register Access interface. When the RapidIO II IP core receives a MAINTENANCE port-write request packet on the RapidIO link, it processes the transaction according to the values you program in the receive port-write registers, and if you have enabled this interrupt signal, asserts the mnt_mnt_s_irq signal to inform the system that the IP core has received a port-write transaction.

4.3.3.6.1. IP Core Actions

The port-write processor in the Maintenance module performs the following tasks:

Composes the RapidIO MAINTENANCE port-write request packet.
Presents the port-write request packet to the Transport layer for transmission.
Processes port-write request packets received across the RapidIO link from a remote device.
Alerts the user of a received port-write using the mnt_mnt_s_irq signal.

4.3.3.6.2. Port-Write Transmission

To send a RapidIO MAINTENANCE port-write packet to a remote device, you must program the transmit port-write control and data registers. You access these registers using the Register Access Avalon-MM slave interface. You must program the values for the following header fields in the corresponding fields in the Tx Port Write Control register:

DESTINATION_ID
priority
wrsize

The RapidIO II IP core assigns the following values to the fields of the MAINTENANCE port-write packet:

Assigns ftype the value of 4'b1000
Assigns ttype the value of 4'b0100
Calculates the values for the wdptr and wrsize fields of the transmitted packet from the size of the payload to be sent, as defined by the size field of the Tx Port Write Control register
Assigns the value of 0 to the Reserved source_tid and config_offset fields

The IP core creates the packet’s payload from the contents of the Tx Port Write Buffer sequence of registers starting at register address 0x10210. This buffer can store a maximum of 64 bytes. The IP core starts the packet composition and transmission process after you set the PACKET_READY bit in the Tx Port Write Control register. The RapidIO II IP core composes the MAINTENANCE port-write packet and transmits it on the RapidIO link.

4.3.3.6.3. Port-Write Reception

When the RapidIO II IP core Maintenance module receives a MAINTENANCE port-write request packet (ftype has the value of 4’b1000 and ttype has the value of 4’b0100) from the Transport layer, it extracts information from the packet header and uses the information to write to registers Rx Port Write Control through Rx Port Write Buffer. The Maintenance module extracts information from the following fields:

wrsize and wdptr — the values in the wrsize and wdptr packet fields determine the value of the PAYLOAD_SIZE field in the Rx Port Write Status register.
payload — the Maintenance module copies the value of the payload packet field to the Rx Port Write Buffer starting at register address 0x10260. This buffer holds a maximum of 64 bytes.

While the IP core is writing the payload to the buffer, it holds the PORT_WRITE_BUSY bit of the Rx Port Write Status register asserted. After the payload is completely written to the buffer, if you have set the RX_PACKET_STORED bit of the Maintenance Interrupt Enable register, the IP core asserts the interrupt signal mnt_mnt_s_irq on the Register Access interface to alert your system of the port-write request.

4.3.3.7. Maintenance Interface Transaction Examples

Following are the examples of communication on the RapidIO II IP core Maintenance interface:

User Sending MAINTENANCE Write Requests
User Receiving MAINTENANCE Write Requests
User Sending MAINTENANCE Read Requests and Receiving Responses
User Receiving MAINTENANCE Read Requests and Sending Responses

4.3.3.7.1. User Sending MAINTENANCE Write Requests

Table 24. Maintenance Interface Usage Example: Sending MAINTENANCE Write Request
User Operation	Device ID Width	Payload Size
Send `MAINTENANCE` write request	8-bit	32-bit

To write to a register in a remote endpoint using a MAINTENANCE write request, you must perform the following actions:

Set up the registers.
Perform a write transfer on the Maintenance Avalon-MM slave interface.

Figure 23. Write Transfers on the Maintenance Avalon-MM Slave InterfaceIt shows the behavior of the signals for four write transfers on the Maintenance Avalon-MM slave interface.

In the first active clock cycle of the example, user logic specifies the active transaction to be a write request by asserting the mnt_s_write signal while specifying the write data on the mnt_s_writedata signal and the target address for the write data on the mnt_s_address signal. However, the RapidIO II IP core throttles the incoming transaction by asserting the mnt_s_writerequest signal until it is ready to receive the write transaction.

In the example, the IP core throttles the incoming transaction for five clock cycles, because it requires six clock cycles to process each write transaction. The user logic maintains the values on the mnt_s_write, mnt_s_writedata, and mnt_s_address signals until one clock cycle after the IP core deasserts the mnt_s_waitrequest signal, as required by the Avalon-MM specification. In the following clock cycle, user logic sends the next write request, which the IP core also throttles for five clock cycles. The process repeats for an additional two write requests.

Table 25. Maintenance Write Request Transmit Example: RapidIO Packet Fields
Field	Value	Comment
`ackID`	6'h00	Value is written by the Physical layer before the packet is transmitted on the RapidIO link.
`VC`	0	The RapidIO II IP core supports only VC0.
`CRF`	0	This bit sets packet priority together with `prio` if CRF is supported. This bit is reserved if VC=0 and CRF is not supported.
`prio[1:0]`	2'b00	The IP core assigns to this field the value programmed in the `PRIORITY` field of the `Tx Maintenance Mapping Window n Control` register for the matching address translation window n.
`tt[1:0]`	2'b00	The value of 0 indicates 8-bit device IDs.
`ftype[3:0]`	4'b1000	The value of 8 indicates a Maintenance Class packet.
`destinationID[7:0]`		The IP core assigns to this field the value programmed in the `DESTINATION_ID` field of the Tx `Maintenance Mapping Window n Control` register for the matching address translation window `n`.
`sourceID[7:0]`		The IP core assigns to this field the value programmed in the `Base_deviceID` field of the `Base Device ID` register (offset 0x60).
`ttype[3:0]`	4'b0001	The value of 1 indicates a `MAINTENANCE` write request.
`wrsize[3:0]`	4'b1000	The `size` and `wdptr` values encode the maximum size of the payload field. In `MAINTENANCE` transactions, the value of `wrsize` is always 4’b1000, which decodes to a value of 4 bytes.
`srcTID[7:0]`		The RapidIO II IP core generates the source transaction ID value internally to track the transaction response. The value depends on the current state of the RapidIO II IP core when it prepares the RapidIO packet.
`config_offset[20:0]`		Depends on the value on the `mnt_s_address` bus, and the values programmed in the `Tx Maintenance Address Translation Window` registers.
`wdptr`		The IP core assigns to this field the negation of `mnt_s_address[0]`.
`hop_count`		The IP core assigns to this field the value programmed in the `HOP_COUNT` field of the `Tx Maintenance Mapping Window n Control` register for the matching address translation window `n`.
`payload[63:0]`		The IP core assigns the value of `mnt_s_writedata[31:0]` to the appropriate half of this field.

4.3.3.7.2. User Receiving MAINTENANCE Write Requests

Table 26. Maintenance Interface Usage Example: Receiving MAINTENANCE Write Request
User Operation	Device ID Width	Payload Size
Receive `MAINTENANCE` write request	8-bit	32-bit

The RapidIO II IP core generates write transfers on the Maintenance Avalon-MM master interface in response to Type 8 MAINTENANCE Write request packets on the RapidIO link with the following properties:

ttype has the value of 4'b0001, indicating a MAINTENANCE Write request
config_offset has a value that indicates an address outside the range of the RapidIO II IP core internal register set

Figure 24. Write Transfers on the Maintenance Avalon-MM Master InterfaceIt shows the signal relationships when the RapidIO II IP core presents a sequence of four write transfers on the Maintenance Avalon-MM master interface.

In the first active clock cycle, the RapidIO II IP core indicates the start of a write transfer by asserting the usr_mnt_write signal. Simultaneously, the IP core presents the target address on the usr_mnt_address bus and the data on the usr_mnt_writedata bus.

In this example, user logic does not assert the usr_mnt_waitrequest signal. However, when user logic asserts the usr_mnt_waitrequest signal during a write transfer, the IP core maintains the address and data values on the buses until at least one clock cycle after user logic deasserts the usr_mnt_waitrequest signal. User logic can use the usr_mnt_waitrequest signal to throttle requests on this interface until it is ready to process them.

4.3.3.7.3. User Sending MAINTENANCE Read Requests and Receiving Responses

Table 27. Maintenance Interface Usage Example: Sending MAINTENANCE Read Request and Receiving Response
User Operation	Device ID Width	Payload Size
Send `MAINTENANCE` read request	16-bit	0
Receive `MAINTENANCE` read response	16-bit	32-bit

Figure 25. Read Transfers on the Maintenance Avalon-MM Slave InterfaceIt shows the behavior of the signals for two read transfers on the Maintenance Avalon-MM slave interface.

In the first active clock cycle of the example, user logic specifies that the active transaction is a read request, by asserting the mnt_s_read signal while specifying the source address for the read data on the mnt_s_address signal. However, the RapidIO II IP core throttles the incoming transaction by asserting the mnt_s_writerequest signal until it is ready to receive the read transaction. In the example, the IP core throttles the incoming transaction for four clock cycles. The user logic maintains the values on the mnt_s_read and mnt_s_address signals until one clock cycle after the IP core deasserts the mnt_s_waitrequest signal. In the following clock cycle, user logic sends the next read request, which the IP core also throttles for four clock cycles.

The RapidIO II IP core presents the read responses it receives on the RapidIO link as read data responses on the Maintenance Avalon-MM slave interface. The IP core presents the read data responses in the same order it receives the original read requests, by asserting the mnt_s_readdatavalid signal while presenting the data on the mnt_s_data bus.

Table 28. Maintenance Read Request Transmit Example: RapidIO Packet Fields
Field	Value	Comment
`ackID`	6'h00	Value is written by the Physical layer before the packet is transmitted on the RapidIO link.
`VC`	0	The RapidIO II IP core supports only VC0.
`CRF`	0	This bit sets packet priority together with `prio` if CRF is supported. This bit is reserved if VC=0 and CRF is not supported.
`prio[1:0]`		The IP core assigns to this field the value programmed in the `PRIORITY` field of the `Tx Maintenance Mapping Window n Control` register for the matching address translation window n.
`tt[1:0]`	2'b01	The value of 1 indicates 16-bit device IDs.
`ftype[3:0]`	4'b1000	The value of 8 indicates a Maintenance Class packet.
`destinationID[15:0]`		The IP core assigns to this field based on the values programmed in the `LARGE_DESTINATION_ID` and `DESTINATION_ID` fields of the`Tx Maintenance Mapping Window n Control register` for the matching address translation window `n`.
`sourceID[15:0]`		The IP core assigns to this field the value programmed in the `Large_base_deviceID` field of the `Base Device ID` register (offset 0x60).
`ttype[3:0]`	4'b0000	The value of 0 indicates a `MAINTENANCE` read request.
`rdsize[3:0]`	4'b1000	The `size` and `wdptr` values encode the maximum size of the payload field. In `MAINTENANCE` transactions, the value of `rdsize` is always 4’b1000, which decodes to a value of 4 bytes.
`srcTID[7:0]`		The RapidIO II IP core generates the source transaction ID value internally to track the transaction response. The value depends on the current state of the RapidIO II IP core when it prepares the RapidIO packet.
`config_offset[20:0]`		Depends on the value on the `mnt_s_address` bus, and the values programmed in the `Tx Maintenance Address Translation Window` registers.
`wdptr`		The IP core assigns to this field the negation of `mnt_s_address[0]`.
`hop_count`		The IP core assigns to this field the value programmed in the `HOP_COUNT` field of the `Tx Maintenance Mapping Window n Control` register for the matching address translation window `n`.

4.3.3.7.4. User Receiving MAINTENANCE Read Requests and Sending Responses

Table 29. Maintenance Interface Usage Example: Receiving MAINTENANCE Read Request and Sending Response
User Operation	Device ID Width	Payload Size
Receive `MAINTENANCE` read request	16-bit	0
Send `MAINTENANCE` read response	16-bit	32-bit

The RapidIO II IP core generates read requests on the Maintenance Avalon-MM master interface when it receives Type 8 MAINTENANCE Read packets on the RapidIO link with the following properties:

ttype has the value of 4'b0000, indicating a MAINTENANCE Read request
config_offset has a value that indicates an address outside the range of the RapidIO II IP core internal register set

Figure 26. Read Transfers on the Maintenance Avalon-MM Master InterfaceIt shows the signal relationships for an example sequence of three read requests that the RapidIO II IP core presents on the Maintenance Avalon-MM master interface, and the data responses from user logic.

In the first active clock cycle, the RapidIO II IP core indicates the start of a read request by asserting the usr_mnt_read signal. Simultaneously, the IP core presents the target address on the usr_mnt_address bus.

User logic presents the read responses on the Maintenance Avalon-MM master interface by asserting theusr_mnt_readdatavalid signal while presenting the data on the usr_mnt_data bus.

4.3.3.8. Maintenance Packet Error Handling

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.

4.3.4. Doorbell Module

The Doorbell module is an optional component of the I/O Logical layer. 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.

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 II 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 II IP core to receive and generate RapidIO DOORBELL messages.

Figure 27. Doorbell Module Block Diagram

This module includes a 32–bit Avalon-MM slave interface to user logic. 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 II parameter editor.
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).

4.3.4.1. Preserving Transaction Order

If you select Prevent doorbell messages from passing write transactions in the RapidIO II parameter editor, each DOORBELL message from the Avalon-MM interface is potentially delayed in a Tx staging FIFO. After 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, the IP core releases the message from the FIFO. An I/O write transaction is considered to have started before a DOORBELL transaction if the ios_rd_wr_write signal is asserted while the ios_rd_wr_waitrequest signal is not asserted, on a cycle preceding the cycle on which the drbell_s_write signal is 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 II parameter editor, the Doorbell Tx staging FIFO is not configured in the RapidIO II IP core.

4.3.4.2. Doorbell Module Interface Signals

Table 30. Doorbell Module Interface Signals
Signal	Direction	Description
`drbell_s_waitrequest`	Output	Doorbell module wait request.
`drbell_s_write`	Input	Doorbell module write request.
`drbell_s_read`	Input	Doorbell module read request.
`drbell_s_address[3:0]`	Input	Doorbell module address bus. The address is a word address, not a byte address.
`drbell_s_writedata[31:0]`	Input	Doorbell module write data bus.
`drbell_s_readdata[31:0]`	Output	Doorbell module read data bus.
`drbell_s_irq`	Output	Doorbell module interrupt.

4.3.4.3. Generating a Doorbell Message

To generate a DOORBELL request packet on the RapidIO serial interface, follow these steps, using the set of Doorbell Message Registers:

Optionally enable interrupts by writing the value 1 to the appropriate bit of the Doorbell Interrupt Enable register.
Optionally enable confirmation of successful outbound messages by writing 1 to the COMPLETED bit of the Tx Doorbell Status Control register.
Set up the PRIORITY field of the Tx Doorbell Control register.
Write the Tx Doorbell register to set up the DESTINATION_ID and Information fields of the generated DOORBELL packet format.

Note: Before writing to the Tx Doorbell register you must be certain that the Doorbell module has available space to accept the write data. Ensuring sufficient space exists avoids a waitrequest signal assertion due to a full FIFO. When the waitrequest signal is asserted, you cannot perform other transactions on the DOORBELL Avalon-MM slave port until the current transaction is completed. You can determine the combined fill level of the staging FIFO and the Tx FIFO by reading the Tx Doorbell Status register. The total number of Doorbell messages stored in the staging FIFO and the Tx FIFO, together, is limited to 16 by the assertion of the drbell_s_waitrequest signal.

4.3.4.4. Response to a DOORBELL Request

After the IP core detects a write to the Tx Doorbell register, 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 IP core receives a response to an outbound DOORBELL message, the IP core writes the corresponding copy of the outbound message to the Tx Doorbell Completion FIFO (if enabled), and generates an interrupt (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 IP core sets the corresponding interrupt status bit each time it receives a valid response packet. The interrupt bit 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 the IP core receives its response is treated in the same manner as an outbound message that receives an error response: if the TX_CPL field of the Doorbell Interrupt Enable register is set, the Doorbell module generates an interrupt by asserting the drbell_s_irq signal, and setting the ERROR_CODE field in the Tx Doorbell Completion Status register 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.

4.3.4.5. Receiving a Doorbell Message

When the Doorbell module receives a DOORBELL request packet from the Transport layer module, the module stores the request in an internal buffer and generates an interrupt on the DOORBELL Avalon-MM slave interface—asserts the drbell_s_irq signal—if this 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.

The RapidIO II IP core generates an interrupt when it receives a valid response packet and when it receives a request packet. Therefore, when user logic receives an interrupt (the drbell_s_irq signal is asserted), you must check the Doorbell Interrupt Status register to determine the type of event that triggered the interrupt.

If the interrupt is not enabled, user logic must periodically poll the Rx Doorbell Status register to check the number of available messages before retrieving them from the Rx doorbell buffer.

The Doorbell module generates and sends appropriate Type 13 response packets for all the DOORBELL messages it receives. The module generates a response with the following status, depending on its ability to process the message:

With DONE status if the received DOORBELL packet can be processed immediately.
With RETRY status to defer processing the received message when the internal hardware is busy, for example when the Rx doorbell buffer is full.

4.3.5. Avalon-ST Pass-Through Interface

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 II parameter editor.

The Avalon-ST pass-through interface supports the following applications:

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.

After packets appear on your RapidIO II IP core Rx Avalon-ST pass-through interface, your application can route them to a local processor or custom user function to process them according to your design requirements.

4.3.5.1. Transaction ID Ranges

To limit the required storage, the RapidIO II IP core shares a single pool of transaction IDs among all destination IDs, although the RapidIO specification allows for independent pools for each Source-Destination pair.

To simplify the routing of incoming ftype=13 response packets, the IP core assigns an exclusive range of transaction IDs to each of the instantiated Logical layer modules. This set of assignments simplifies response routing, but places a constraint on your design. If you implement custom logic that communicates to the RapidIO II IP core through the Avalon-ST pass-through interface, you must ensure your logic does not use a transaction ID assigned to another instantiated Logical layer module for transmitting request packets that expect an ftype=13 response packet. If you use such a transaction ID, the response routes away from the Avalon-ST pass-through interface and your custom module never receives the response.

Table 31. Transaction ID Ranges and Assignments
Range	Assignments
0-63	This range of Transaction IDs is used for `ftype=8` responses by the Maintenance Logical layer Avalon-MM slave module.
64-127	`ftype=13` responses in this range are reserved for exclusive use by the Input-Output Logical layer Avalon-MM slave module.
128-143	`ftype=13` responses in this range are reserved for exclusive use by the Doorbell Logical layer module.
144-255	This range of Transaction IDs is currently unused and is available for use by Logical layer modules connected to the pass-through interface.

The RapidIO II IP core Transport layer routes response packets of ftype=13 with transaction IDs outside the 64–143 range to the Avalon-ST pass-through interface. Your system should not use transaction IDs in the 0-63 range 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, the RapidIO II IP core Transport layer routes the response packets in the corresponding Transaction IDs ranges for these layers to the Avalon-ST pass-through interface.

4.3.5.2. Pass-Through Interface Signals

The Avalon^® -ST pass-through interface includes the following ports:

Transmit interface — this sink interface accepts incoming streaming data that the IP core sends to the RapidIO link.
Receive data interface — this source interface streams out the payload of packets the IP core receives from the RapidIO link.
Receive header interface — this source interface streams out packet header information the IP core receives from the RapidIO link.

Pass-Through Transmit Side Signals

The Avalon^® -ST pass-through interface transmit side signals receive incoming streaming data from user logic; the IP core transmits this data on the RapidIO link. The RapidIO II IP core samples data on this interface only when both gen_tx_ready and gen_tx_valid are asserted.

The incoming streaming data is assumed to contain well-formed RapidIO packets, with the following exceptions:

The streaming data includes placeholder bits for the ackID field of the RapidIO packet, but does not include the ackID value, which is assigned by the IP core.
The streaming data does not include the RapidIO packet CRC bits and padding bytes.

The Avalon^® -ST pass-through interface does not check the integrity of the streaming data, but rather passes the bits on directly to the Transport layer. The RapidIO II IP core fills in the ackID bits and adds the CRC bits and padding bytes before transmitting each packet on the RapidIO link.

Table 32. Avalon^® -ST Pass-Through Interface Transmit Side ( Avalon^® -ST Sink) Signals
Signal Name	Type	Function
`gen_tx_ready`	Output	Indicates that the IP core is ready to receive data on the current clock cycle. Asserted by the Avalon^® -ST sink to mark ready cycles, which are the cycles in which transfers can take place. If ready is asserted on cycle N, the cycle (N+`READY_LATENCY`) is a ready cycle. In the RapidIO II IP core, `READY_LATENCY` is equal to 0. This signal may alternate between 0 and 1 when the Avalon^® -ST pass-through transmitter interface is idle.
`gen_tx_valid`	Input	Used to qualify all the other transmit side input signals of the Avalon^® -ST pass-through interface. On every ready cycle in which `gen_tx_valid` is high, data is sampled by the IP core. You must assert `gen_tx_valid` continuously during transmission of a packet, from the assertion of `gen_tx_startofpacket` to the deassertion of `gen_tx_endofpacket`.
`gen_tx_startofpacket`	Input	Marks the active cycle containing the start of the packet. The user logic asserts `gen_tx_startofpacket` and `gen_tx_valid` to indicate that a packet is available for the IP core to sample.
`gen_tx_endofpacket`	Input	Marks the active cycle containing the end of the packet.
`gen_tx_data[127:0]`	Input	A 128-bit wide data bus. Carries the bulk of the information transferred from the source to the sink. The RapidIO II IP core fills in the RapidIO packet `ackID` field and adds the CRC bits and padding bytes, but otherwise copies the bits from `gen_tx_data` to the RapidIO packet without modifying them. Therefore, you must pack the appropriate RapidIO packet fields in the correct RapidIO packet format in the most significant bits of the gen_tx_data bus, `gen_tx_data[127:N]`. The total width (127 – N + 1) of the header fields depends on the transaction and the device ID width.
`gen_tx_empty[3:0]`	Input	This bus identifies the number of empty bytes on the final data transfer of the packet, which occurs during the clock cycle when `gen_tx_endofpacket` is asserted. The number of empty bytes must always be even.
gen_tx_packet_size[8:0]²³	Input	Indicates the number of valid bytes in the packet being transferred. The IP core samples this signal only while `gen_tx_startofpacket` is asserted. User logic must ensure this signal is correct while `gen_tx_startofpacket` is asserted.

The required format of the TX header information on the gen_tx_data bus for both device ID widths derives directly from the RapidIO specification. You must include the header information in the clock cycle in which you assert gen_tx_startofpacket.

Note: The ackID field is filled by the IP core, and the eight-bit device ID fields are not extended with zeroes, in contrast to the destinationID and source ID fields in gen_rx_hd_data.

Table 33. RapidIO Header Information Format on gen_tx_data Bus
Field	gen_tx_data Bits
Field	Device ID Width 8	Device ID Width 16
`ackID[5:0]`	[127:122]	[127:122]
`VC`	[121]	[121]
`CRF`	[120]	[120]
`prio[1:0]`	[119:118]	[119:118]
`tt[1:0]`	[117:116]	[117:116]
`ftype[3:0]`	[115:112]	[115:112]
`destinationID[<deviceIDwidth>–1:0]`	[111:104]	[111:96]
`sourceID[<deviceIDwidth>–1:0]`	[103:96]	[95:80]
`specific_header`	[95:...]	[79:...]

Table 34. specific_header Format on gen_tx_data Bus
ftype	Field	gen_tx_data Bits
ftype	Field	Device ID Width 8	Device ID Width 16
2, 5	`ttype[3:0]`	[95:92]	[79:76]
	`size[3:0]`	[91:88]	[75:72]
	`transactionID[7:0]`	[87:80]	[71:64]
	`address[28:0]`	[79:51]	[63:35]
	`wdptr`	[50]	[34]
	`xamsbs[1:0]`	[49:48]	[33:32]
6	`address[28:0]`	[95:67]	[79:51]
	`Reserved`	[66]	[50]
	`xamsbs[1:0]`	[65:64]	[49:48]
7	`XON/XOFF`	[95]	[79]
	`FAM[2:0]`	[94:92]	[78:76]
	`Reserved[3:0]`	[91:88]	[75:72]
	`flowID[6:0]`	[87:81]	[71:65]
	`soc`	[80]	[64]
8²⁴	`ttype[3:0]`	[95:92]	[79:76]
	`size[3:0]`	[91:88]	[75:72]
	`transactionID[7:0]`	[87:80]	[71:64]
	`hop_count[7:0]`	[79:72]	[63:56]
	`config_offset[20:0]`	[71:51]	[55:35]
	`wdptr`	[50]	[34]
	`Reserved[1:0]`	[49:48]	[33:32]
9 single segment and start	`cos[7:0]`	[95:88]	[79:72]
	`S`	[87]	[71]
	`E`	[86]	[70]
	`Reserved[2:0]`	[85:83]	[69:67]
	`xh`	[82]	[66]
	`O`	[81]	[65]
	`P`	[80]	[64]
	`streamID[15:0]`	[79:64]	[63:48]
9 continuation	`cos[7:0]`	[95:88]	[79:72]
	`S`	[87]	[71]
	`E`	[86]	[70]
	`Reserved[2:0]`	[85:83]	[69:67]
	`xh`	[82]	[66]
	`O`	[81]	[65]
	`P`	[80]	[64]
9 end	`cos[7:0]`	[95:88]	[79:72]
	`S`	[87]	[71]
	`E`	[86]	[70]
	`Reserved[2:0]`	[85:83]
	`xh`	[82][69:67]	[66]
	`O`	[69:67[81]	[65]
	`P`	[80]	[64]
	`length[15:0]`	[79:64]	[63:48]
9 extended packet	`cos[7:0]`	[95:88]	[79:72]
	`Reserved[1:0]`	[87:86]	[71:70]
	`xtype[2:0]`	[85:83]	[69:67]
	`xh`	[82]	[66]
	`Reserved[1:0]`	[81:80]	[65:64]
	`streamID[15:0]`	[79:64]	[63:48]
	`TM_OP[3:0]`	[63:60]	[47:44]
	`Reserved`	[59]	[43]
	`wildcard[2:0]`	[58:56]	[42:40]
	`mask[7:0]`	[55:48]	[39:32]
	`parameter1[7:0]`	[47:40]	[31:24]
	`parameter2[7:0]`	[39:32]	[23:16]
10	`Reserved[7:0]`	[95:88]	[79:72]
	`transactionID[7:0]`	[87:80]	[71:64]
	`info[15:0]`	[79:64]	[63:48]
11	`msglen[3:0]`	[95:92]	[79:76]
	`ssize[3:0]`	[91:88]	[75:72]
	`letter[1:0]`	[87:86]	[71:70]
	`mbox[1:0]`	[85:84]	[69:68]
	`msgseg[3:0]` or `xmbox[3:0]`	[83:80]	[67:64]
13	`ttype[3:0]`	[95:92]	[79:76]
	`size[3:0]`	[91:88]	[75:72]
	`transactionID[7:0]`	[87:80]	[71:64]

Table 35. Avalon^® -ST Pass-Through Interface Receive Side ( Avalon^® -ST Source) Data SignalsFollowing are the Avalon^® -ST pass-through interface receive side payload data signals. The application should sample payload data only when both `gen_rx_pd_ready` and `gen_rx_pd_valid` are asserted.
Signal Name	Type	Function
`gen_rx_pd_ready`	Input	Indicates to the IP core that the user’s custom logic is ready to receive data on the current cycle. Asserted by the sink to mark ready cycles, which are cycles in which transfers can occur. If ready is asserted on cycle N, the cycle (N+`READY_LATENCY`) is a ready cycle. The RapidIO II IP core is designed for `READY_LATENCY` equal to 0.
`gen_rx_pd_valid`	Output	Used to qualify all the other output signals of the receive side pass-through interface. On every rising edge of the clock during which `gen_rx_pd_valid` is high, `gen_rx_pd_data` can be sampled.
`gen_rx_pd_startofpacket`	Output	Marks the active cycle containing the start of the packet.
`gen_rx_pd_endofpacket`	Output	Marks the active cycle containing the end of the packet.
`gen_rx_pd_data[127:0]`	Output	A 128-bit wide data bus for data payload.
`gen_rx_pd_empty[3:0]`	Output	This bus identifies the number of empty two-byte segments on the 128-bit wide `gen_rx_pd_data` bus on the final data transfer of the packet, which occurs during the clock cycle when `gen_tx_endofpacket` is asserted. This signal is 4 bits wide.

Table 36. Avalon^® -ST Pass-Through Interface Receive Side ( Avalon^® -ST Source) Header SignalsFollowing are the Avalon^® -ST pass-through interface receive side header signals. The application should sample header data only when both `gen_rx_hd_ready` and `gen_rx_hd_valid` are asserted.
Signal Name	Type	Function
`gen_rx_hd_ready`	Input	Indicates to the IP core that the user’s custom logic is ready to receive packet header bits on the current clock cycle. Asserted by the sink to mark ready cycles, which are cycles in which transfers can occur. If ready is asserted on cycle N, the cycle (N+`READY_LATENCY`) is a ready cycle. The RapidIO II IP core is designed for `READY_LATENCY` equal to 0.
`gen_rx_hd_valid`	Output	Used to qualify the receive side pass-through interface output header bus. On every rising edge of the clock during which `gen_rx_hd_valid` is high, `gen_rx_hd_data` can be sampled.
`gen_rx_hd_data[114:0]`	Output	A 115-bit wide bus for packet header bits. Data on this bus is valid only when `gen_rx_hd_valid` is high.

Table 37. RapidIO Header Fields in gen_rx_hd_data Bus
Field	gen_rx_hd_data Bits	Comment
`pd_size[8:0]`	[114:106]	Size of payload data, in bytes.
`VC`	[105]	Value = 0. The RapidIO II IP core supports only VC0.
`CRF`	[104]	This bit sets packet priority together with `prio` if CRF is supported. This bit is reserved if VC=0 and CRF is not supported.
`prio[1:0]`	[103:102]	Specifies packet priority.
`tt[1:0]`	[101:100]	Transport type. The value of 0 indicates 8-bit device IDs and value of 1 indicates 16-bit device IDs.
`ftype[3:0]`	[99:96]	Format type. Represented as a 4-bit value.
`destinationID[15:0]`	[95:80]	For packets with an 8-bit device ID, bits [95:88] (bits [15:8] of the destinationID) are set to 8’h00.
`sourceID[15:0]`	[79:64]	When `ftype[3:0]` has the value of 7, this field is used as the `tgtDestinationID` field. For packets with an 8-bit device ID, bits [79:72] (bits [15:8] of the sourceID) are set to 8’h00.
`specific_header[63:0]`	[63:0]	Fields depend on the format type specified in `ftype`.

Table 38. specific_header Fields on gen_rx_hd_data Bus
ftype	Field	specific_header Bits
2, 5	`ttype[3:0]`	[63:60]
	`size[3:0]`	[59:56]
	`transactionID[7:0]`	[55:48]
	`address[28:0]`	[47:19]
	`wdptr`	[18]
	`xamsbs[1:0]`	[17:16]
	`Reserved[15:0]`	[15:0]
6	`address[28:0]`	[63:35]
	`Reserved`	[34]
	`xamsbs[1:0]`	[33:32]
	`Reserved[31:0]`	[31:0]
7	`XON/XOFF`	[63]
	`FAM[2:0]`	[62:60]
	`Reserved[3:0]`	[59:56]
	`flowID[6:0]`	[55:49]
	`soc`	[48]
	`Reserved[47:0]`	[47:0]
8	`ttype[3:0]`	[63:60]
	`status[3:0]` or `size[3:0]`	[59:56]
	`transactionID[7:0]`	[55:48]
	`hop_count[7:0]`	[47:40]
	`config_offset[20:0]`	[39:19]
	`wdptr`	[18]
	`Reserved[17:0]`	[17:0]
9	`cos[7:0]`	[63:56]
	`S`	[55]
	`E`	[54]
	`xtype[2:0]`	[53:51]
	`xh`	[50]
	`O`	[49]
	`P`	[48]
	`streamID[15:0]`	[47:32]
	`TM_OP[3:0]`	[31:28]
	`reserve`	[27]
	`wildcard[2:0]`	[26:24]
	`mask[7:0]`	[23:16]
	`parameter1[7:0]`	[15:8]
	`parameter2[7:0]`	[7:0]
10	`ttype[3:0]`	[63:60]
	`status[3:0]`	[59:56]
	`transactionID[7:0]`	[55:48]
	`info_msb[7:0]`	[47:40]
	`info_lsb[7:0]`	[39:32]
	`crc[15:0]`	[31:16]
	`Reserved[15:0]`	[15:0]
11	`msglen[3:0]`	[63:60]
	`ssize[3:0]`	[59:56]
	`letter[1:0]`	[55:54]
	`mbox[1:0]`	[53:52]
	`msgseg[3:0]` or `xmbox[3:0]`	[51:48]
	`Reserved[47:0]`	[47:0]
13	`ttype[3:0]`	[63:60]
	`status[3:0]`	[59:56]
	`transactionID[7:0]` or `target_info[7:0]`	[55:48]
	`Reserved[47:0]`	[47:0]

²³ This signal is not defined in the Avalon^® Interface Specifications. However, it refers to data being transferred on the Avalon^® -ST sink interface.

²⁴ In MAINTENANCE response packets, which have ftype value 8, replace the config_offset and wdptr fields with additional reserved bits.

4.3.5.3. Pass-Through Interface Usage Examples

Following are the examples of communication on the RapidIO II IP core Avalon-ST pass-through interface:

User Sending Write Request
User Receiving Write Request
User Sending Read Request and Receiving Read Response
User Receiving Read Request and Sending Read Response
User Sending Streaming Write Request
User Receiving Streaming Write Request

4.3.5.3.1. User Sending Write Request

Table 39. Avalon-ST Pass-Through Interface Usage Example: Sending Write Request
User Operation	Operation Type	RapidIO Transaction	Priority	Device ID Width	Payload Size (Bytes)
Send write request	Tx	NWRITE	0	8	40

In the first clock cycle of the example, the IP core asserts gen_tx_ready to indicate it is ready to sample data. In the same cycle, user logic asserts gen_tx_valid. Because both gen_tx_ready and gen_tx_valid are asserted, this clock cycle is an Avalon-ST ready cycle. The user logic provides valid data on gen_tx_data for the IP core to sample, and asserts gen_tx_startofpacket to indicate the current value of gen_tx_data is the initial piece of the current packet (the start of packet). On gen_tx_packet_size, user logic reports the full length of the packet is 0x32, which is decimal 50, because the packet comprises 10 bytes of header and 40 bytes of payload data.

Figure 28. Avalon-ST Pass-Through Interface NWRITE Transmit Example

The user logic provides the 40-byte payload and 10-byte header on the same bus, gen_tx_data[127:0]. Transferring these 50 bytes of information requires four clock cycles. During all of these cycles, the IP core holds gen_tx_ready high and user logic holds gen_tx_valid high, indicating the cycles are all Avalon-ST ready cycles. In the second and third cycles, user logic holds gen_tx_startofpacket and gen_tx_endofpacket low, because the information on gen_tx_data is neither start of packet nor end of packet data. In the fourth clock cycle, user logic asserts gen_tx_endofpacket and sets gen_tx_empty to the value of 0xE to indicate that only two of the bytes of data available on gen_tx_data in the current clock cycle are valid. The initial ten bytes of the packet contain header information.

Table 40. NWRITE Request Transmit Example: RapidIO Header Fields on the gen_tx_data Bus
Field	gen_tx_data Bits	Value	Comment
`ackID`	[127:122]	6'h00	Value is a don’t care, because it is overwritten by the Physical layer `ackID` value before the packet is transmitted on the RapidIO link.
`VC`	[121]	0	The RapidIO II IP core supports only VC0.
`CRF`	[120]	0	This bit sets packet priority together with `prio` if CRF is supported. This bit is reserved if VC=0 and CRF is not supported.
`prio[1:0]`	[119:118]	2'b00	Specifies packet priority.
`tt[1:0]`	[117:116]	2'b00	The value of 0 indicates 8-bit device IDs.
`ftype[3:0]`	[115:112]	4'b0101	The value of 5 indicates a Write Class packet.
`destinationId[7:0]`	[111:104]	8'hDD	Indicates the ID of the target.
`sourceId[7:0]`	[103:96]	8'hAA	Indicates the ID of the source.
`ttype[3:0]`	[95:92]	4'b0100	The value of 4 indicates an `NWRITE` transaction.
`size[3:0]`	[91:88]	4'b1100	The `size` and `wdptr` values encode the maximum size of the payload field.
`transactionID[7:0]`	[87:80]	8'h00	Not used for NWRITE transactions.
`address[28:0]`	[79:51]	{28’hFEDCBA9, 1’b0}
`wdptr`	[50]	1	The `size` and `wdptr` values encode the maximum size of the payload field.
`xamsbs[1:0]`	[49:48]	2’b00	Specifies most significant bits of extended address. Further extends the address specified by the address fields by 2 bits.

4.3.5.3.2. User Receiving Write Request

Table 41. Avalon-ST Pass-Through Interface Usage Example: Receive NWRITE Request
User Operation	Operation Type	RapidIO Transaction	Priority	Device ID Width	Payload Size (Bytes)
Receive write request	Rx	NWRITE	0	8	40

In the first clock cycle of the example, user logic asserts gen_rx_hd_ready and gen_rx_pd_ready, and the IP core asserts gen_rx_hd_valid and gen_rx_pd_valid, indicating it is providing valid data on gen_rx_hd_data and gen_rx_pd_data, respectively. The assertion of both the ready signal and the valid signal on each of the header and payload-data Avalon-ST interfaces makes the current cycle an Avalon-ST ready cycle for both header and data.

Figure 29. Avalon-ST Pass-Through Interface NWRITE Receive Example

The IP core asserts gen_rx_pd_startofpacket to indicate the current cycle is the first valid data cycle of the packet. In this clock cycle, the IP core also makes the header and the first 128 bits of payload data available on gen_rx_hd_data and gen_rx_pd_data, respectively. The 40-byte payload requires 3 clock cycles. In the third clock cycle of data transfer, the IP core asserts gen_rx_pd_endofpacket to indicate this is the final clock cycle of data transfer, and specifies in gen_rx_pd_empty that in the current clock cycle, the four least significant two-byte segments (the least significant eight bytes) of gen_rx_pd_data are not valid. Following the clock cycles in which valid data is available on gen_rx_pd_data, the IP core deasserts gen_rx_pd_valid.

Table 42. NWRITE Request Receive Example: RapidIO Header Fields in gen_rx_hd_data Bus
Field	gen_rx_hd_data Bits	Value	Comment
`pd_size[8:0]`	[114:106]	9’h028	Payload data size is 0x28 (decimal 40).
`VC`	[105]	0	The RapidIO II IP core supports only VC0.
`CRF`	[104]	0	This bit sets packet priority together with `prio` if CRF is supported. This bit is reserved if VC=0 and CRF is not supported.
`prio[1:0]`	[103:102]	2'b00	Specifies packet priority.
`tt[1:0]`	[101:100]	2'b00	The value of 0 indicates 8-bit device IDs.
`ftype[3:0]`	[99:96]	4'b0101	The value of 5 indicates a Write Class packet.
`destinationId[15:0]`	[95:80]	16’h00DD	For variations with an 8-bit device ID, bits [95:88] (bits [15:8] of the destinationID) are set to 8’h00.
`sourceId[15:0]`	[79:64]	16'h00AA	For variations with an 8-bit device ID, bits [79:72] (bits [15:8] of the sourceID) are set to 8’h00.
`ttype[3:0]`	[63:60]	4'b0100	The value of 4 indicates an `NWRITE` transaction.
`size[3:0]`	[59:56]	4'b1100	The `size` and `wdptr` values encode the maximum size of the payload field. In this example, they decode to a value of 64 bytes.
`transactionID[7:0]`	[55:48]	8'h00	Not used for NWRITE transactions.
`address[28:0]`	[47:19]	{28’hFEDCBA9, 1’b0}
`wdptr`	[18]	1	The `size` and `wdptr` values encode the maximum size of the payload field.
`xamsbs[1:0]`	[17:16]	2’b00	Specifies most significant bits of extended address. Further extends the address specified by the address fields by 2 bits.
`Reserved[15:0]`	[15:0]	16’h0000

4.3.5.3.3. User Sending Read Request and Receiving Read Response

Table 43. Avalon^® -ST Pass-Through Interface Usage Example: Sending Read Request and Receiving Response
User Operation	Operation Type	RapidIO Transaction	Priority	Device ID Width	Payload Size (Bytes)
Send read request	Tx	NREAD	1	16	32
Receive read response	Rx	Response with payload	2	16	32

The behavior of the signals on the Avalon^® -ST pass-through interface for this example transaction sequence is described in

NREAD Request Transaction
NREAD Response Transaction

NREAD Request Transaction

In the first clock cycle of the example, the IP core asserts gen_tx_ready to indicate it is ready to sample data. In the same cycle, user logic asserts gen_tx_valid. Because both gen_tx_ready and gen_tx_valid are asserted, this clock cycle is an Avalon^® -ST ready cycle. The user logic provides valid data on gen_tx_data for the IP core to sample, and asserts gen_tx_startofpacket to indicate the current value of gen_tx_data is the initial piece of the current packet (the start of packet). On gen_tx_packet_size, user logic reports the full length of the packet is 0xC, which is decimal 12, because the packet comprises 12 bytes of header.

Figure 30. Avalon^® -ST Pass-Through Interface NREAD Request Send and Response Receive Example

The NREAD request transaction contains no payload data. The NREAD request requires a single clock cycle. During this clock cycle, user logic asserts gen_tx_endofpacket and reports on gen_tx_empty that the number of empty bytes is 4. The initial 12 bytes of the NREAD request packet contain header information.

Table 44. NREAD Request Transmit Example: RapidIO Header Fields on the gen_tx_data Bus
Field	gen_tx_data Bits	Value	Comment
`ackID`	[127:122]	6'h00	Value is a don’t care, because it is overwritten by the Physical layer `ackID` value before the packet is transmitted on the RapidIO link.
`VC`	[121]	0	The RapidIO II IP core supports only VC0.
`CRF`	[120]	0	This bit sets packet priority together with `prio` when CRF is supported. This bit is reserved when VC=0 and CRF is not supported.
`prio[1:0]`	[119:118]	2'b01	Specifies packet priority.
`tt[1:0]`	[117:116]	2'b01	The value of 1 indicates 16-bit device IDs.
`ftype[3:0]`	[115:112]	4'b0010	The value of 2 indicates a Request Class packet.
`destinationId[15:0]`	[111:96]	16'hDDDD	The value indicates the ID of the target.
`sourceId[15:0]`	[95:80]	16'hAAAA	The value indicates the ID of the source.
`ttype[3:0]`	[79:76]	4'b0100	The value of 4 indicates an `NREAD` transaction.
`size[3:0]`	[75:72]	4'b1100	The `size` and `wdptr` values encode the maximum size of the payload field. In this example, they decode to a value of 32 bytes.
`transactionID[7:0]`	[71:64]	8'hBB	Not used for NWRITE transactions.
`address[28:0]`	[63:35]	{28’h7654321, 1’b0}
`wdptr`	[34]	1	The `size` and `wdptr` values encode the maximum size of the payload field.
`xamsbs[1:0]`	[33:32]	2’b00	Specifies extended address most significant bits. Further extends the address specified by the address fields by 2 bits.

NREAD Response Transaction

In the first clock cycle of the NREAD response on the Avalon^® -ST pass-through interface, user logic asserts gen_rx_hd_ready and gen_rx_pd_ready, and the IP core asserts gen_rx_hd_valid and gen_rx_pd_valid, indicating it is providing valid data on gen_rx_hd_data and gen_rx_pd_data, respectively. The assertion of both the ready signal and the valid signal on each of the header and payload-data Avalon^® -ST interfaces makes the current cycle an Avalon^® -ST ready cycle for both header and data.

Figure 31. Avalon^® -ST Pass-Through Interface NREAD Request Send and Response Receive Example

The IP core asserts gen_rx_pd_startofpacket to indicate the current cycle is the first valid data cycle of the packet. In this clock cycle, the IP core also makes the header and the first 128 bits of payload data available on gen_rx_hd_data and gen_rx_pd_data, respectively. The 32-byte payload requires two clock cycles. In the second clock cycle of data transfer, the IP core asserts gen_rx_pd_endofpacket to indicate this is the final clock cycle of data transfer, and specifies in gen_rx_pd_empty that in the current clock cycle, all of the bytes of gen_rx_pd_data are valid. Following the clock cycles in which valid data is available on gen_rx_pd_data, the IP core deasserts gen_rx_pd_valid.

Table 45. NREAD Response Receive Example: RapidIO Header Fields in gen_rx_hd_data Bus
Field	gen_rx_hd_data Bits	Value	Comment
`pd_size[8:0]`	[114:106]	9’h020	Payload data size is 0x20 (decimal 32).
`VC`	[105]	0	The RapidIO II IP core supports only VC0.
`CRF`	[104]	0	This bit sets packet priority together with `prio` when CRF is supported. This bit is reserved when VC=0 and CRF is not supported.
`prio[1:0]`	[103:102]	2'b10	Priority of the response packet. Value must be higher than the priority value of the request packet. In this example, the response packet has a priority value of 2’b10 and the original request has a priority value of 2’b01.
`tt[1:0]`	[101:100]	2'b01	Indicates 16-bit device IDs..
`ftype[3:0]`	[99:96]	4'b1101	The value of 4’hD (decimal 13) indicates a Response Class packet..
`destinationId[15:0]`	[95:80]	16’hAAAA	The destinationID of the NREAD request are swapped in the response transaction.
`sourceId[15:0]`	[79:64]	16'h0DDDD	The sourceID of the NREAD request are swapped in the response transaction.
`ttype[3:0]`	[63:60]	4'b1000	The value of 8 indicates a Response transaction with data payload.
`status[3:0]`	[59:56]	4'b0000	The value of 0 indicates Done. The current packet successfully completes the requested transaction.
`transactionID[7:0]`	[55:48]	8'hBB	Value in the response packet matches the `transactionID` of the corresponding request packet.
`Reserved[47:0]`	[47:0]	48’h0

4.3.5.3.4. User Receiving Read Request and Sending Read Response

Table 46. Avalon^® -ST Pass-Through Interface Usage Example: Receiving NREAD Request and Sending Response
User Operation	Operation Type	RapidIO Transaction	Priority	Device ID Width	Payload Size (Bytes)
Receive read request	Rx	NREAD	1	16	32
Send read response	Tx	Response with payload	2	16	32

The behavior of the signals on the Avalon^® -ST pass-through interface for this example transaction sequence is described in

NREAD Request Transaction
NREAD Response Transaction

NREAD Request Transaction

The NREAD request requires a single clock cycle. During this cycle, user logic asserts gen_rx_hd_ready to indicate it is ready to sample data. In the same cycle, the IP core asserts gen_rx_hd_valid. Because both gen_rx_hd_ready and gen_rx_hd_valid are asserted, the current cycle is an Avalon^® -ST ready cycle on the header Avalon^® -ST interface. The IP core provides valid header information on gen_rx_hd_data for the user logic to sample.

Figure 32. Avalon^® -ST Pass-Through Interface NREAD Request Receive and Response Send Example

The IP core does not assert gen_rx_pd_valid, because the NREAD request transaction contains no payload data.

Table 47. NREAD Request Receive Example: RapidIO Header Fields in gen_rx_hd_data Bus
Field	gen_rx_hd_data Bits	Value	Comment
`pd_size[8:0]`	[114:106]	9’h000	An NREAD request transaction has no payload data.
`VC`	[105]	0	The RapidIO II IP core supports only VC0.
`CRF`	[104]	0	This bit sets packet priority together with `prio` if CRF is supported. This bit is reserved if VC=0 and CRF is not supported.
`prio[1:0]`	[103:102]	2'b01	Specifies packet priority.
`tt[1:0]`	[101:100]	2'b01	The value of 1 indicates 16-bit device IDs.
`ftype[3:0]`	[99:96]	4'b0010	The value of 2 indicates a Request Class packet.
`destinationId[15:0]`	[95:80]	16’h00DD	Indicates the ID of the target.
`sourceId[15:0]`	[79:64]	16'h00AA	Indicates the ID of the source.
`ttype[3:0]`	[63:60]	4'b0100	The value of 4 indicates an `NREAD` transaction.
`size[3:0]`	[59:56]	4'b1100	The `size` and `wdptr` values encode the maximum size of the payload field. In this example, they decode to a value of 32 bytes.
`transactionID[7:0]`	[55:48]	8'hBB	Value in the response packet matches the `transactionID` of the corresponding request packet.
`address[28:0]`	[47:19]	{28’h7654321, 1’b0}
`wdptr`	[18]	0	The `size` and `wdptr` values encode the maximum size of the payload field.
`xamsbs[1:0]`	[17:16]	2’b00	Specifies most significant bits of extended address. Further extends the address specified by the address fields by 2 bits.
`Reserved[15:0]`	[15:0]	16’h0000

NREAD Response Transaction

In the first clock cycle of the NREAD response on the Avalon^® -ST pass-through interface, the IP core asserts gen_tx_ready to indicate it is ready to sample data. In the same cycle, user logic asserts gen_tx_valid. Because both gen_tx_ready and gen_tx_valid are asserted, this clock cycle is an Avalon^® -ST ready cycle. The user logic provides valid data on gen_tx_data for the IP core to sample, and asserts gen_tx_startofpacket to indicate the current value of gen_tx_data is the initial piece of the current packet (the start of packet). On gen_tx_packet_size, user logic reports the full length of the packet is 0x28, which is decimal 40, because the packet comprises eight bytes of header and 32 bytes of payload data.

Figure 33. Avalon^® -ST Pass-Through Interface NREAD Request Receive and Response Send Example

The user logic provides the 32-byte payload and 8-byte header on the same bus, gen_tx_data[127:0]. Transferring these 40 bytes of information requires three clock cycles. During all of these cycles, the IP core holds gen_tx_ready high and user logic holds gen_tx_valid high, indicating the cycles are all Avalon^® -ST ready cycles. In the second cycle, user logic holds gen_tx_startofpacket and gen_tx_endofpacket low, because the information on gen_tx_data is neither start of packet nor end of packet data. In the third clock cycle, user logic asserts gen_tx_endofpacket and sets gen_tx_empty to the value of 0x8 to indicate that eight bytes of the data in the current clock cycle are invalid — in other words, only the initial eight (sixteen minus eight) bytes of data available on gen_tx_data in the current clock cycle are valid. The initial eight bytes of the NREAD response packet contain header information.

Table 48. NREAD Response Transmit Example: RapidIO Header Fields on the gen_tx_data Bus
Field	gen_tx_data Bits	Value	Comment
`ackID`	[127:122]	6'h00	Value is a don’t care, because it is overwritten by the Physical layer `ackID` value before the packet is transmitted on the RapidIO link.
`VC`	[121]	0	The RapidIO II IP core supports only VC0.
`CRF`	[120]	0	This bit sets packet priority together with `prio` if CRF is supported. This bit is reserved if VC=0 and CRF is not supported.
`prio[1:0]`	[119:118]	2'b10	Priority of the response packet. Value must be higher than the priority value of the request packet. In this example, the response packet has a priority value of 2’b10 and the original request has a priority value of 2’b01.
`tt[1:0]`	[117:116]	2'b01	The value of 1 indicates 16-bit device IDs.
`ftype[3:0]`	[115:112]	4’b1101	The value of 4’hD (decimal 13) indicates a Response Class packet.
`destinationId[15:0]`	[111:96]	16'hDDDD	The destinationID of the NREAD request are swapped in the response transaction.
`sourceId[15:0]`	[95:80]	16'hAAAA	The sourceID of the NREAD request are swapped in the response transaction.
`ttype[3:0]`	[79:76]	4'b1000	The value of 8 indicates a Response transaction with data payload.
`status[3:0]`	[75:72]	4'b0000	The value of 0 indicates Done. The current packet successfully completes the requested transaction.
`transactionID[7:0]`	[71:64]	8'hBB	Value in the response packet matches the `transactionID` of the corresponding request packet.

4.3.5.3.5. User Sending Streaming Write Request

Table 49. Avalon^® -ST Pass-Through Interface Usage Example: Send SWRITE Request
User Operation	Operation Type	RapidIO Transaction	Priority	Device ID Width	Payload Size (Bytes)
Send streaming write request	Tx	SWRITE	3	8	40

In the first clock cycle of the example, the IP core asserts gen_tx_ready to indicate it is ready to sample data. In the same cycle, user logic asserts gen_tx_valid. Because both gen_tx_ready and gen_tx_valid are asserted, this clock cycle is an Avalon^® -ST ready cycle. The user logic provides valid data on gen_tx_data for the IP core to sample, and asserts gen_tx_startofpacket to indicate the current value of gen_tx_data is the initial piece of the current packet (the start of packet). On gen_tx_packet_size, user logic reports the full length of the packet is 0x30, which is decimal 48, because the packet comprises eight bytes of header and 40 bytes of payload data.

Figure 34. Avalon^® -ST Pass-Through Interface SWRITE Transmit Example

The user logic provides the 40-byte payload and 8-byte header on the same bus, gen_tx_data[127:0]. Transferring these 48 bytes of information requires three clock cycles. During all of these cycles, the IP core holds gen_tx_ready high and user logic holds gen_tx_valid high, indicating the cycles are all Avalon^® -ST ready cycles. In the second cycle, user logic holds gen_tx_startofpacket and gen_tx_endofpacket low, because the information on gen_tx_data is neither start of packet nor end of packet data. In the third clock cycle, user logic asserts gen_tx_endofpacket and sets gen_tx_empty to the value of 0x0 to indicate that all of the bytes of data available on gen_tx_data in the current clock cycle are valid.

In this example, the IP core does not deassert gen_tx_ready following the three ready cycles, indicating that it is ready to accept an additional transaction whenever user logic is ready to send an additional transaction. Whether or not the IP core deasserts gen_tx_ready following the three Avalon^® -ST ready cycles, the next cycle is not a ready cycle, because user logic has deasserted gen_tx_valid. The initial eight bytes of the packet contain header information.

Table 50. SWRITE Request Transmit Example: RapidIO Header Fields on the gen_tx_data Bus
Field	gen_tx_data Bits	Value	Comment
`ackID`	[127:122]	6'h00	Value is a don’t care, because it is overwritten by the Physical layer `ackID` value before the packet is transmitted on the RapidIO link.
`VC`	[121]	0	The RapidIO II IP core supports only VC0.
`CRF`	[120]	0	This bit sets packet priority together with `prio` if CRF is supported. This bit is reserved if VC=0 and CRF is not supported.
`prio[1:0]`	[119:118]	2'b11	Specifies packet priority.
`tt[1:0]`	[117:116]	2'b00	The value of 0 indicates 8-bit device IDs.
`ftype[3:0]`	[115:112]	4'b0110	The value of 6 indicates a Streaming-Write Class packet.
`destinationId[7:0]`	[111:104]	8'hDD	Indicates the ID of the target.
`sourceId[7:0]`	[103:96]	8'hAA	Indicates the ID of the source.
`address[28:0]`	[95:67]	{28’h0AABBCC, 1’b1}
`wdptr`	[66]	1	Not used for SWRITE transactions.
`xamsbs[1:0]`	[65:64]	2’b00	Specifies most significant bits of extended address. Further extends the address specified by the address fields by 2 bits.

4.3.5.3.6. User Receiving Streaming Write Request

Table 51. Avalon-ST Pass-Through Interface Usage Example: Receive SWRITE Request
User Operation	Operation Type	RapidIO Transaction	Priority	Device ID Width	Payload Size (Bytes)
Receive streaming write request	Rx	SWRITE	3	8	40

Figure 35. Avalon-ST Pass-Through Interface SWRITE Receive Example

Table 52. SWRITE Request Receive Example: RapidIO Header Fields in gen_rx_hd_data Bus
Field	gen_rx_hd_data Bits	Value	Comment
`pd_size[8:0]`	[114:106]	9’h028	Payload data size is 0x28 (decimal 40).
`VC`	[105]	0	The RapidIO II IP core supports only VC0.
`CRF`	[104]	0	This bit sets packet priority together with `prio` if CRF is supported. This bit is reserved if VC=0 and CRF is not supported.
`prio[1:0]`	[103:102]	2'b11	Specifies packet priority.
`tt[1:0]`	[101:100]	2'b00	The value of 0 indicates 8-bit device IDs.
`ftype[3:0]`	[99:96]	4'b0110	The value of 6 indicates a Streaming-Write Class packet.
`destinationId[15:0]`	[95:80]	16’h00DD	For variations with an 8-bit device ID, bits [95:88] (bits [15:8] of the destinationID) are set to 8’h00.
`sourceId[15:0]`	[79:64]	16'h00AA	For variations with an 8-bit device ID, bits [79:72] (bits [15:8] of the sourceID) are set to 8’h00.
`address[28:0]`	[63:35]	{28’h0AABBCC, 1’b1}
`Reserved`	[34]	1'b0
`xamsbs[1:0]`	[33:32]	2’b00	Specifies most significant bits of extended address. Further extends the address specified by the address fields by 2 bits.
`Reserved[31:0]`	[31:0]	32’h00000000

4.4. Transport Layer

The Transport layer is a required module of the RapidIO II IP core. It 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 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 II IP core to process multi-cast transactions correctly.

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

Figure 36. Transport Layer Block Diagram

4.4.1. Receiver

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.

If you turn off destination ID checking in the RapidIO II parameter editor, the Transport layer routes incoming packets from the Physical layer that are not already marked as errored according to the following rules:

Routes packets with unsupported ftype to the Avalon-ST pass-through interface, if the Avalon-ST pass-through interface is instantiated in the IP core variation.
Routes packets with a tt value that does not match the RapidIO II IP core’s device ID width support level according to the following rules:
- If you turned on Enable 16-bit device ID width in the RapidIO II parameter editor, routes packets with an 8-bit device ID to the Avalon-ST pass-through interface, if the Avalon-ST pass-through interface is implemented in the IP core variation. If this interface is not implemented in your variation, drops the packet.
- If you turned off Enable 16-bit device ID width in the RapidIO II parameter editor, drops packets with a 16-bit device ID.
In any of the cases in which the packet is dropped, the Transport layer module asserts the transport_rx_packet_dropped signal.
Request packets with a supported ftype and a tt value that matches the RapidIO II IP core’s device ID width are routed to the Logical layer supporting the ftype. If the request packet has an unsupported ttype, 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 II IP core does not implement an Avalon-ST pass-through interface, are dropped. In this case, the Transport layer module asserts the transport_rx_packet_dropped signal.
ftype=13 response packets are routed based on the value of their target transaction ID 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 Avalon-ST 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 transport_rx_packet_dropped output signal is not asserted.

4.4.2. Transmitter

On the transmit side, the Transport layer module uses a modified round-robin scheduler to select the Logical layer module to transmit packets. The Physical layer continuously sends Physical layer transmit buffer status information to the Transport layer. Based on this information, the Transport layer either implements a standard round-robin algorithm to select the Logical layer module from which to transmit the next packet, or implements a modified algorithm in which the Transport layer only considers packets whose priority field is set at or above a specified threshold. The incoming status information from the Physical layer determines the current priority threshold. The status information can also temporarily backpressure the Transport layer, by indicating no packets of any priority level can currently be selected.

The Transport layer polls the various Logical layer modules to determine whether a packet is available. When a packet of the appropriate priority level 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 and gen_tx_endofpacket signal.

4.5. Physical Layer

The Physical layer has the following features:

Port initialization
Transmitter and receiver with the following features:
- One, two, or four lane high-speed data serialization and deserialization
- Clock and data recovery (receiver)
- 8B10B encoding and decoding
- Lane synchronization (receiver)
- Packet/control symbol assembly and delineation
- Packet cyclic redundancy code (CRC) (CRC-16) generation and checking
- Control symbol CRC-13 generation and checking
- Error detection
- Pseudo-random IDLE2 sequence generation
- IDLE2 sequence removal
- Scrambling and descrambling
Software interface (status/control registers)
Flow control (ackID tracking)
Time-out on acknowledgments
Order of retransmission maintenance and acknowledgments
ackID assignment through software interface
ackID synchronization after reset
Error management
Clock decoupling
FIFO buffer with level output port
Four transmission queues and four retransmission queues to handle packet prioritization

Figure 37. Physical Layer High Level Block Diagram

4.5.1. Low-level Interface Receiver

The receiver in the low-level interface receives the input from the RapidIO interface, and performs the following tasks:

Separates packets and control symbols.
Removes IDLE2 idle sequence characters.
Detects multicast-event and stomp control symbols.
Detects packet-size errors.
Checks the control symbol 13-bit CRC and asserts symbol_error if the CRC is incorrect.

The receiver transceiver is an embedded Transceiver Native PHY IP core.

The Physical layer checks the CRC bits in an incoming RapidIO packet and flags CRC and packet size errors. It strips all CRC bits and padding bytes from the data it sends to the Transport layer.

4.5.2. Low-Level Interface Transmitter

The transmitter in the low-level interface transmits output to the RapidIO interface. This module performs the following tasks:

Assembles packets and control symbols into a proper output format.
Generates the 13-bit CRC to cover the 35-bit symbol and appends the CRC at the end of the symbol.
Transmits an IDLE2 sequence during port initialization and when no packets or control symbols are available to transmit.
Transmits outgoing multicast-event control symbols in response to user requests.
Transmits status control symbols and the rate compensation sequence periodically as required by the RapidIO specification.

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.

The internal transmitters are turned off while the initialization state machine is in the SILENT state. This behavior causes the link partner to detect the need to reinitialize the RapidIO link.

The transmitter transceiver is an embedded Native PHY IP core.

The Physical layer ensures that a maximum of 63 unacknowledged packets are transmitted, and that the ackIDs are used and acknowledged in sequential order. To support retransmission of unacknowledged packets, the Physical layer maintains a copy of each transmitted packet until the packet is acknowledged with a packet-accepted control symbol.

The RapidIO II IP core supports receiver-controlled flow control in both directions.

If the receiver detects that an incoming packet or control symbol is corrupted or a link protocol violation has occurred, the Physical layer enters an error recovery process. In the case of a corrupted incoming packet or control symbol, and some link protocol violations, the transmitter sends 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 seven times. If the protocol and control block times out awaiting the response to the seventh link-request control symbol, it declares a fatal error. When a time-out occurs for an outgoing packet, the Physical layer starts the recovery process. If a packet is retransmitted, the time-out counter is reset. To meet the RapidIO specification requirements for packet priority handling and deadlock avoidance, the Physical layer transmitter includes four transmit queues and four retransmit queues, one for each priority level.

The transmit buffer is the main memory in which the packets are stored before they are transmitted. The buffer is partitioned into 64-byte blocks to be used on a first-come, first-served basis by the transmit and retransmit queues.

The following events cause any stored packets to be lost:

Fatal error caused by receiving a link-response control symbol with the port_status set to OK but the ackid_status set to an ackID that is not pending (transmitted but not acknowledged yet).
Fatal error caused by transmitter timing out while waiting for link-response.
Fatal error caused by receiver timing out while waiting for link-request.
Receive four consecutive link-request control symbols with the cmd set to reset-device.

4.6. Error Detection and Management

The error detection and management mechanisms in the RapidIO specification and those built into the RapidIO II IP core provide a high degree of reliability. In addition to error detection, management, and recovery features, the RapidIO II IP core also provides debugging and diagnostic aids. The RapidIO II IP core optionally implements the Error Management Extensions block and registers.

4.6.1. Physical Layer Error Management

Most errors at the Physical layer are categorized as:

Protocol violations
Transmission errors

Protocol violations can be caused by a link partner that is not fully compliant to the specification, or can be a side effect of the link partner being reset.

Transmission errors can be caused by noise on the line and consist of one or more bit errors. The following mechanisms exist for checking and detecting errors:

The receiver checks the validity of the received 8B10B encoded characters, including the running disparity.
The receiver detects control characters changed into data characters or data characters changed into control characters, based on the context in which the character is received.
The receiver checks the CRC of the received control symbols and packets.

The RapidIO II IP core Physical layer transparently manages these errors for you. The RapidIO specification defines both input and output error detection and recovery state machines that include handshaking protocols in which the receiving end signals that an error is detected by sending a packet-not-accepted control symbol, the transmitter then sends an input-status link-request control symbol to which the receiver responds with a link-response control symbol to indicate which packet requires transmission. The input and output error detection and recovery state machines can be monitored by software that you create to read the status of the Port 0 Error and Status CSR.

In addition to the registers defined by the specification, the RapidIO II IP core provides several output signals that enable user logic to monitor error detection and the recovery process.

4.6.1.1. Protocol Violations

Some protocol violations, such as a packet with an unexpected ackID or a time-out on a packet acknowledgment, can use the same error recovery mechanisms as the transmission errors. Some protocol violations, such as a time-out on a link-request or the RapidIO II IP core receiving a link-response with an ackID outside the range of transmitted ackIDs, can lead to unrecoverable—or fatal—errors.

4.6.1.2. Fatal Errors

Software determines the behavior of the RapidIO II IP core following a fatal error. For example, you can program software to optionally perform any of the following actions, among others:

Set the PORT_DIS bit of the Port 0 Control CSR to force the initialization state machine to the SILENT state.
Write to the OUTBOUND_ACKID field of the Port 0 Local AckID CSR to specify the next outbound and expected packet ackID from the RapidIO link partner. You can use this option to force retransmission of outstanding unacknowledged packets.
Set the CLR_OUTSTANDING_ACKIDS field of the Port 0 Local AckID CSR to clear the queue of outstanding unacknowledged packets.

If the link partner is reset when its expected ackID is not zero, a fatal error occurs when the link partner receives the next transmitted packet because the link partner’s expected ackID is reset to zero, which causes a mismatch between the transmitted ackID and the expected ackID. When that occurs, you can use the Port 0 Local AckID CSR to resynchronize the expected and transmitted ackID values.

4.6.2. Logical Layer Error Management

The Logical layer modules only need to process Logical layer errors because errors detected by the Physical layer are masked from the Logical layer module. If an errored packet arrives at the Transport layer, the Transport layer does not pass it on to the Logical layer modules.

The RapidIO specification defines the following common errors and the protocols for managing them:

Malformed request or response packets
Unexpected Transaction ID
Missing response (time-out)
Response with ERROR status

The RapidIO II IP core implements the optional Error Management Extensions as defined in Part 8 of the RapidIO Interconnect Specification Revision 2.2.

When enabled, each error defined in the Error Management Extensions triggers the assertion of an interrupt on its module-specific interrupt output signal and causes the capture of various packet header fields in the appropriate capture CSRs.

In addition to the errors defined by the RapidIO specification, each Logical layer module has its own set of error conditions that can be detected and managed.

4.6.2.1. Maintenance Avalon-MM Slave

The Maintenance Avalon-MM slave module creates request packets for the Avalon-MM transaction on its slave interface and processes the response packets that it receives. Anomalies are reported through one or more of the following three channels:

Standard error management registers
Registers in the implementation defined space
The Avalon-MM slave interface’s error indication signal

Standard Error Management Registers

The following standard defined error types can be declared by the Maintenance Avalon-MM slave module. The corresponding error bits are then set and the required packet information is captured in the appropriate error management registers.

IO Error Response is declared when a response with ERROR status is received for a pending MAINTENANCE read or write request.
Unsolicited Response is declared when a response is received that does not correspond to any pending MAINTENANCE read or write request.
Packet Response Timeout is declared when a response is not received within the time specified by the Port Response Time-Out CSR for a pending MAINTENANCE read or write request.
Illegal Transaction Decode is declared for malformed received response packets occurring from any of the following events:
- Response packet to pending MAINTENANCE read or write request with status not DONE nor ERROR.
- Response packet with payload with a transaction type different from MAINTENANCE read response.
- Response packet without payload, with a transaction type different from MAINTENANCE write response.
- Response to a pending MAINTENANCE read request with more than 32 bits of payload (The RapidIO II IP core issues only 32-bit MAINTENANCE read requests).

Registers in the Implementation Defined Space

The Maintenance register module defines the Maintenance Interrupt register in which the following two bits report Maintenance Avalon-MM slave related error conditions:

WRITE_OUT_OF_BOUNDS
READ_OUT_OF_BOUNDS

These bits are set when the address of a write or read transfer on the Maintenance Avalon-MM slave interface falls outside of all the enabled address mapping windows. When these bits are set, the system interrupt signal mnt_mnt_s_irq is also asserted if the corresponding bit in the Maintenance Interrupt Enable register is set.

Maintenance Avalon-MM Slave Interface's Error Indication Signal

The mnt_s_readerror output signal is asserted when a response with ERROR status is received for a MAINTENANCE read request packet, when a MAINTENANCE read times out, or when the Avalon-MM read address falls outside of all the enabled address mapping windows.

4.6.2.2. Maintenance Avalon-MM Master

The Maintenance Avalon-MM master module processes the MAINTENANCE read and write request packets that it receives and generates response packets. Anomalies are reported by generating ERROR response packets. A response packet with ERROR status is generated in the following cases:

Received a MAINTENANCE write request packet without payload or with more than 64 bytes of payload.
Received a MAINTENANCE read request packet of the wrong size (too large or too small).
Received a MAINTENANCE read or write request packet with an invalid rdsize or wrsize value

Note: These errors do not cause any of the standard-defined errors to be declared and recorded in the Error Management registers.

4.6.2.3. Port-Write Reception Module

The Port-Write reception module processes receive port-write request MAINTENANCE packets. The following bits in the Maintenance Interrupt register in the implementation-defined space report any detected anomaly. The mnt_mnt_s_irq interrupt signal is asserted if the corresponding bit in the Maintenance Interrupt Enable register is set.

The PORT_WRITE_ERROR bit is set when the packet is either too small (no payload) or too large (more than 64 bytes of payload), or if the actual size of the packet is larger than indicated by the wrsize field. These errors do not cause any of the standard defined errors to be declared and recorded in the error management registers.
The PACKET_DROPPED bit is set when a port-write request packet is received but port-write reception is not enabled (by setting bit PORT_WRITE_ENA in the Rx Port Write Control register, or if a previously received port-write has not been read out from the Rx Port Write Buffer register.

4.6.2.4. Port-Write Transmission Module

Port-write requests do not cause response packets to be generated. Therefore, the port-write transmission module does not detect or report any errors.

4.6.2.5. Input/Output Avalon-MM Slave

The I/O Avalon-MM slave module creates request packets for the Avalon-MM transaction on its read and write slave interfaces and processes the response packets that it receives. Anomalies are reported through one or more of the following three channels:

Standard error management registers
Registers in the implementation defined space
The Avalon-MM slave interface's error indication signal

Standard Error Management Registers

The following standard defined error types can be declared by the I/O Avalon-MM slave module. The corresponding error bits are then set and the required packet information is captured in the appropriate error management registers.

IO Error Response is declared when a response with ERROR status is received for a pending NREAD or NWRITE_R request.
Unsolicited Response is declared when a response is received that does not correspond to any pending NREAD or NWRITE_R request.
Packet Response Time-Out is declared when a response is not received within the time specified by the Port Response Time-Out Response CSR for an NREAD or NWRITE_R request.
Illegal Transaction Decode is declared for malformed received response packets occurring from any of the following events:
- NREAD or NWRITE_R response packet with status not DONE nor ERROR.
- NWRITE_R response packet with payload or with a transaction type indicating the presence of a payload.
- NREAD response packet without payload, with incorrect payload size, or with a transaction type indicating absence of payload.

Registers in the Implementation Defined Space

The I/O Avalon-MM slave module defines the Input/Output Slave Interrupt registers with the following bits:

INVALID_READ_BURSTCOUNT
INVALID_READ_BYTEENABLE
INVALID_WRITE_BYTEENABLE
INVALID_WRITE_BURSTCOUNT
WRITE_OUT_OF_BOUNDS
READ_OUT_OF_BOUNDS

When any of these bits are set, the system interrupt signal io_s_mnt_irq is also asserted if the corresponding bit in the Input/Output Slave Interrupt Enable register is set.

The Avalon-MM Slave Interface's Error Indication Signal

The ios_rd_wr_readresponse output is asserted when a response with ERROR status is received for an NREAD request packet, when an NREAD request times out, or when the Avalon-MM address falls outside of the enabled address mapping window. As required by the Avalon-MM interface specification, a burst in which the ios_rd_wr_readresponse signal is asserted completes despite the error signal assertion.

4.6.2.6. Input/Output Avalon-MM Master

The I/O Avalon-MM master module processes the request packets that it receives and generates response packets when required. Anomalies are reported through one or both of the following two channels:

Standard error management registers
Response packets with ERROR status

Standard Error Management Registers

The following two standard defined error types can be declared by the I/O Avalon-MM master module. The corresponding bits are then set and the required packet information is captured in the appropriate error management registers.

Unsupported Transaction is declared when a request packet carries a transaction type that is not supported in the Destination Operations CAR, whether an ATOMIC transaction type, a reserved transaction type, or an implementation defined transaction type.
Illegal Transaction Decode is declared when a request packet for a supported transaction is too short or if it contains illegal values in some of its fields such as in these examples:
- Request packet with priority = 3.
- NWRITE, NWRITE_R, or SWRITE request packets without payload.
- NWRITE or NWRITE_R request packets with reserved wrsize and wdptr combination.
- NWRITE, NWRITE_R, SWRITE, or NREAD request packets for which the address does not match any enabled address mapping window.
- NREAD request packet with payload.
- NREAD request with rdsize that is not an integral number of transfers on all byte lanes. (The Avalon-MM interface specification requires that all byte lanes be enabled for read transfers. Therefore, Read Avalon-MM master modules do not have a byteenable signal).
- Payload size does not match the size indicated by the rdsize or wrsize and wdptr fields.

Response Packets with ERROR Status

An ERROR response packet is sent for NREAD and NWRITE_R and Type 5 ATOMIC request packets that cause an Illegal Transaction Decode error to be declared. An ERROR response packet is also sent for NREAD requests if the iom_rd_wr_readresponse input signal is asserted through the final cycle of the Avalon-MM read transfer.

4.6.3. Avalon-ST Pass-Through Interface

Packets with valid CRCs that are not recognized as being targeted to one of the implemented Logical layer modules are passed to the Avalon-ST pass-through interface for processing by user logic.

The RapidIO II IP core also provides hooks for user logic to report any error detected by a user-implemented Logical layer module attached to the Avalon-ST pass-through interface.

5. Signals

This chapter lists the RapidIO II IP core signals. Signals are listed with their widths. In this context, the n in [n:0] is the number of lanes minus one, so that signal[n:0] has one bit for each lane.

5.1. Global Signals

Table 53. Clock Signals
Signal	Direction	Description
`sys_clk`	Input	Avalon^® system clock.
`tx_pll_refclk`	Input	Physical layer reference clock. Your design must drive this clock from the same source as the `sys_clk` input clock. In Intel^® Arria^® 10, Intel^® Stratix^® 10 and Intel^® Cyclone^® 10 GX device variations, despite the signal name, this clock is the reference clock for the RX CDR block in the transceiver. In other variations, this clock is also the reference clock for the TX PLL in the transceiver.
`rx_clkout`	Output	Receive-side recovered clock. This signal is derived from the incoming RapidIO data.
`tx_clkout`	Output	Transmit-side clock.
`tx_bonding_clocks_ch0[5:0]`	Input	Transceiver channel TX input clocks for RapidIO lane 0. This signal is available in Intel^® Arria^® 10, Intel^® Stratix^® 10 and Intel^® Cyclone^® 10 GX variations. Each transceiver channel that corresponds to a RapidIO lane has six input clock bits. The bits are expected to be driven from a TX PLL.
`tx_bonding_clocks_ch1[5:0]`	Input	Transceiver channel TX input clocks for RapidIO lane 1. This signal is available in Intel^® Arria^® 10, Intel^® Stratix^® 10 and Intel^® Cyclone^® 10 GX 2x and 4x variations. Each transceiver channel that corresponds to a RapidIO lane has six input clock bits. The bits are expected to be driven from a TX PLL.
`tx_bonding_clocks_ch2[5:0]`	Input	Transceiver channel TX input clocks for RapidIO lane 2. This signal is available in Intel^® Arria^® 10, Intel^® Stratix^® 10 and Intel^® Cyclone^® 10 GX 4x variations. Each transceiver channel that corresponds to a RapidIO lane has six input clock bits. The bits are expected to be driven from a TX PLL.
`tx_bonding_clocks_ch3[5:0]`	Input	Transceiver channel TX input clocks for RapidIO lane 3. This signal is available in Intel^® Arria^® 10, Intel^® Stratix^® 10 and Intel^® Cyclone^® 10 GX 4x variations. Each transceiver channel that corresponds to a RapidIO lane has six input clock bits. The bits are expected to be driven from a TX PLL.
`reconfig_clk_ch0`	Input	Clocks the dynamic reconfiguration interface for RapidIO lane 0. This interface is available in Intel^® Arria^® 10, Intel^® Stratix^® 10 and Intel^® Cyclone^® 10 GX variations for which you turn on Enable transceiver dynamic reconfiguration.
`reconfig_clk_ch1`	Input	Clocks the dynamic reconfiguration interface for RapidIO lane 1. This interface is available in Intel^® Arria^® 10, Intel^® Stratix^® 10 and Intel^® Cyclone^® 10 GX 2x and 4x variations for which you turn on Enable transceiver dynamic reconfiguration.
`reconfig_clk_ch2`	Input	Clocks the dynamic reconfiguration interface for RapidIO lane 2. This interface is available in Intel^® Arria^® 10, Intel^® Stratix^® 10 and Intel^® Cyclone^® 10 GX 4x variations for which you turn on Enable transceiver dynamic reconfiguration.
`reconfig_clk_ch3`	Input	Clocks the dynamic reconfiguration interface for RapidIO lane 3. This interface is available in Intel^® Arria^® 10, Intel^® Stratix^® 10 and Intel^® Cyclone^® 10 GX 4x variations for which you turn on Enable transceiver dynamic reconfiguration.

Table 54. Global Reset Signals
Signal	Direction	Description
`rst_n`	Input	Active-low system reset. This reset is associated with the Avalon^® system clock. `rst_n` can be asserted asynchronously, but must stay asserted at least one clock cycle and must be de-asserted synchronously with `sys_clk`. To reset the IP core correctly you must also assert this signal together with the `reset` input signal to the Transceiver PHY Reset Controller IP core to which you must connect the RapidIO II IP core. Intel^® recommends that you apply an explicit 1 to 0 transition on the `rst_n` input port in simulation, to ensure that the simulation model is properly reset.
`reconfig_reset_ch0`	Input	Resets the dynamic reconfiguration interface for RapidIO lane 0. This interface is available in Intel^® Arria^® 10, Intel^® Stratix^® 10 and Intel^® Cyclone^® 10 GX variations for which you turn on Enable transceiver dynamic reconfiguration.
`reconfig_reset_ch1`	Input	Resets the dynamic reconfiguration interface for RapidIO lane 1. This interface is available in Intel^® Arria^® 10, Intel^® Stratix^® 10 and Intel^® Cyclone^® 10 GX 2x and 4x variations for which you turn on Enable transceiver dynamic reconfiguration.
`reconfig_reset_ch2`	Input	Resets the dynamic reconfiguration interface for RapidIO lane 2. This interface is available in Intel^® Arria^® 10, Intel^® Stratix^® 10 and Intel^® Cyclone^® 10 GX 4x variations for which you turn on Enable transceiver dynamic reconfiguration.
`reconfig_reset_ch3`	Input	Resets the dynamic reconfiguration interface for RapidIO lane 3. This interface is available in Intel^® Arria^® 10, Intel^® Stratix^® 10 and Intel^® Cyclone^® 10 GX 4x variations for which you turn on Enable transceiver dynamic reconfiguration.

5.2. Physical Layer Signals

Table 55. RapidIO Interface
Signal	Direction	Description
`rd[n:0]`	Input	Receive data — a unidirectional data receiver. It is connected to the `td` bus of the transmitting device.
`td[n:0]`	Output	Transmit data — a unidirectional data driver. The `td` bus of one device is connected to the `rd` bus of the receiving device.

5.2.1. Status Packet and Error Monitoring Signals

Table 56. Status Packet and Error Monitoring SignalsAll of these signals are output signals synchronized with the `sys_clk` clock.
Output Signals	Description
`packet_transmitted`	Pulsed high for one clock cycle when a packet’s transmission completes normally.
`packet_cancelled`	Pulsed high for one clock cycle when a packet’s transmission is cancelled by sending a `stomp`, a `restart-from-retry`, or a `link-request` control symbol.
`packet_accepted_cs_ sent`	Pulsed high for one clock cycle when a `packet-accepted` control symbol has been transmitted.
`packet_accepted_cs_ received`	Pulsed high for one clock cycle when a `packet-accepted` control symbol has been received.
`packet_retry_cs_ sent`	Pulsed high for one clock cycle when a `packet-retry` control symbol has been transmitted.
`packet_retry_cs_ received`	Pulsed high for one clock cycle when a `packet-retry` control symbol has been received.
`packet_not_accepted _cs_sent`	Pulsed high for one clock cycle when a `packet-not-accepted` control symbol has been transmitted.
`packet_not_accepted _cs_received`	Pulsed high for one clock cycle when a `packet-not-accepted` control symbol has been received.
`packet_crc_error`	Pulsed high for one clock cycle when a CRC error is detected in a received packet.
`control_symbol_error`	Pulsed high for one clock cycle when a corrupted control symbol is received.
`port_initialized`	Indicates that the RapidIO initialization sequence has completed successfully. This is a level signal asserted high while the initialization state machine is in the 1X_MODE, 2X_MODE, or 4X_MODE state, as described in paragraph 4.12 of the RapidIO Interconnect Specification v2.2 Part 6: LP-Serial Physical Layer Specification. This signal holds the inverse of the value of the `PORT_UNINIT` field of the `Port 0 Error and Status` CSR (offset `0x158`)
`port_error`	This signal holds the value of the `PORT_ERR` bit of the `Port 0 Error and Status` CSR (offset `0x158`)
`link_initialized`	Indicates that the RapidIO port successfully completed link initialization.
`port_ok`	This signal holds the value of the `PORT_OK` bit of the `Port 0 Error and Status` CSR (offset `0x158`)
`four_lanes_aligned`	Indicates that all four lanes of the 4× RapidIO port are in sync and aligned. This signal is present only in variations that support four lanes.
`two_lanes_aligned`	Indicates that the both lanes of the 2× RapidIO port are in sync and aligned. This signal is present only in variations that support two lanes.

5.2.2. Low Latency Signals

The low-latency signals connect to the lowest level of the Physical layer module, to minimize latency.

5.2.2.1. Multicast Event Signals

Table 57. Multicast Event SignalsAll of these signals are synchronized with the sys_clk clock.
Signal	Direction	Description
`send_multicast_event`	Input	Change the value of this signal to indicate the RapidIO II IP core should transmit a `multicast-event` control symbol. After you assert the `send_multicast_event` signal, await assertion of the `sent_multicast_event` signal before you toggle this signal again. If you toggle this signal before you see the `sent_multicast_event` confirmation from the previous change of value, the number of multicast events that are sent is undefined.
`multicast_event_rx`	Output	Changes value when a `multicast-event` control symbol is received.
`sent_multicast_event`	Output	Indicates the RapidIO II IP core has queued a `multicast-event` control symbol for transmission.

5.2.2.2. Link-Request Reset-Device Signals

Table 58. Link-Request Reset-Device Signals
Signal	Direction	Description
`send_link_request_reset_device`	Input	Change the value of this signal to indicate the RapidIO II IP core should transmit five `link-request reset-device` control symbols. Await assertion of the `sent_link_request_reset_device` signal before you toggle this signal again. If you toggle this signal before you see the `sent_link_request_reset_device` confirmation from the previous change of value, the RapidIO II IP core behavior is undefined.
`link_req_reset_device_received`	Output	Asserted for one `sys_clk` cycle when four valid `link-request reset-device` control symbols in a row are received. The assertion of this signal does not automatically reset the IP core. However, your design can implement logic to reset the IP core in response to the assertion of this signal. For example, you could implement a direct connection from this signal to a reset controller for the IP core and the transceiver, or implement logic to write to a register that reset software polls.
`sent_link_request_reset_device`	Output	Indicates the RapidIO II IP core has queued a series of five `link-request reset-device` control symbols for transmission.

5.2.3. Transceiver Signals

Table 59. Transceiver SignalsThese signals are connected directly to the transceiver block. In some cases these signals must be shared by multiple transceiver blocks that are implemented in the same device.
Signal	Direction	Description
`reconfig_to_xcvr`	Input	Driven from an external dynamic reconfiguration block. Supports the selection of multiple transceiver channels for dynamic reconfiguration. Note that not using a dynamic reconfiguration block that enables offset cancellation results in a non-functional hardware design. The width of this bus is (C + 1) × 70, where C is the number of channels: 1, 2, or 4. This width supports communication from the Reconfiguration Controller with C + 1 reconfiguration interfaces—one dedicated to each channel and another for the transceiver PLL—to the transceiver. If you omit the Reconfiguration Controller from your simulation model, you must ensure all bits of this bus are tied to 0. This bus is available only in Arria^® V, Arria^® V GZ, Cyclone^® V, and Stratix^® V IP core variations.
`reconfig_from_xcvr`	Output	Driven to an external dynamic reconfiguration block. The bus identifies the transceiver channel whose settings are being transmitted to the dynamic reconfiguration block. If no external dynamic reconfiguration block is used, then this output bus can be left unconnected. The width of this bus is (C + 1) × 46, where C is the number of channels: 1, 2, or 4. This width supports communication from the transceiver to C + 1 reconfiguration interfaces in the Reconfiguration Controller, one interface dedicated to each channel and an additional interface for the transceiver PLL. This bus is available only in Arria^® V, Arria^® V GZ, Cyclone^® V, and Stratix^® V IP core variations.
`tx_cal_busy[n:0]`	Output	Connect to the corresponding signal in the Transceiver PHY Reset Controller IP core, which implements the appropriate reset sequence for the device.
`rx_cal_busy[n:0]`	Output	Connect to the corresponding signal in the Transceiver PHY Reset Controller IP core, which implements the appropriate reset sequence for the device.
`pll_locked`	Output	Connect to the corresponding signal in the Transceiver PHY Reset Controller IP core, which implements the appropriate reset sequence for the device. This signal is available only in Arria^® V, Arria^® V GZ, Cyclone^® V, and Stratix^® V IP core variations.
`pll_powerdown`	Input	Connect to the corresponding signal in the Transceiver PHY Reset Controller IP core, which implements the appropriate reset sequence for the device. This signal is available only in Arria^® V, Arria^® V GZ, Cyclone^® V, and Stratix^® V IP core variations.
`rx_digitalreset[n:0]`	Input	Connect to the corresponding signal in the Transceiver PHY Reset Controller IP core, which implements the appropriate reset sequence for the device.
`rx_digitalreset_stat[n:0]`	Output	Connect to the corresponding signal in the Transceiver PHY Reset Controller IP core while using Intel^® Stratix^® 10 devices, which implements the appropriate reset sequence for the device.
`rx_analogreset[n:0]`	Input	Connect to the corresponding signal in the Transceiver PHY Reset Controller IP core, which implements the appropriate reset sequence for the device.
`rx_analogreset_stat[n:0]`	Output	Connect to the corresponding signal in the Transceiver PHY Reset Controller IP core while using Intel^® Stratix^® 10 devices, which implements the appropriate reset sequence for the device.
`rx_ready[n:0`	Input

Maximum Baud Rate

Avalon® -MM Interface Byte Ordering

IP Core Actions

Tracking I/O Write Transactions

Pass-Through Transmit Side Signals

Avalon^® -MM Interface Byte Ordering