RapidIO II Intel FPGA IP User Guide
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 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.
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
- 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
- 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.
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.
- Link initialization
- Packet format
- Packet priority
- Error handling
- Throughput
- Flow control
1.3.2. Hardware Testing
- 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
- 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
- Texas Instruments Incorporated
- Integrated Device Technology, Inc. (IDT)
1.4. Performance and Resource Utilization
- 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
- 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.
Device | Parameters | ALMs | Registers | Memory Blocks (M10K or M20K)1 | ||
---|---|---|---|---|---|---|
Variation | Baud Rate (Gbaud) | Primary | Secondary | |||
Intel® Cyclone® 10 GX | Minimal | 6.25 | 11400 | 10400 | 1300 | 28 |
Full-featured | 6.25 | 24300 | 27800 | 3700 | 51 | |
Intel® Stratix® 10 L-Tile | Minimal | 6.25 | 11800 | 12800 | 700 | 28 |
Full-featured | 6.25 | 27400 | 35000 | 3200 | 54 | |
Intel® Stratix® 10 H-Tile | Minimal | 6.25 | 12000 | 12900 | 600 | 28 |
Full-featured | 6.25 | 34300 | 35000 | 3100 | 54 | |
Intel® Arria® 10 | Minimal | 6.25 | 11200 | 10300 | 13000 | 28 |
Full-featured | 6.25 | 24400 | 28300 | 4000 | 53 | |
Arria® V | Minimal | 6.25 | 11600 | 10700 | 1300 | 38 |
Full-featured | 6.25 | 21100 | 26200 | 2800 | 82 | |
Cyclone® V | Minimal | 3.125 | 11000 | 11000 | 1300 | 38 |
Full-featured | 3.125 | 20000 | 25100 | 2600 | 84 | |
Stratix® V | Minimal | 6.25 | 11100 | 11200 | 1100 | 28 |
Full-featured | 6.25 | 20600 | 25500 | 2600 | 49 |
1.5. Device Speed Grades
Device Family | Rate | ||||
---|---|---|---|---|---|
1.25 Gbaud | 2.5 Gbaud | 3.125 Gbaud | 5.0 Gbaud | 6.25 Gbaud | |
fMAX | |||||
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, –52 |
Arria® V GZ | –3, –4 | –3, –4 | –3, –4 | –3, –4 | –3, –4 |
Cyclone® V | –6, –7 | –6, –7 | –6, –7 | –73 | – |
Stratix® V | –2, –3, –4 | –2, –3, –4 | –2, –3, –4 | –2, –3, –4 | –2, –3, –4 |
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.
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 installs IP cores in the following locations by default:
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 |
2.2. Intel FPGA IP Evaluation Mode
- Simulate the behavior of a licensed Intel® FPGA IP core in your system.
- Verify the functionality, size, and speed of the IP core quickly and easily.
- Generate time-limited device programming files for designs that include IP cores.
- Program a device with your IP core and verify your design in hardware.
Intel® FPGA IP Evaluation Mode supports the following operation modes:
- Tethered—Allows running the design containing the licensed Intel® FPGA IP indefinitely with a connection between your board and the host computer. Tethered mode requires a serial joint test action group (JTAG) cable connected between the JTAG port on your board and the host computer, which is running the Intel® Quartus® Prime Programmer for the duration of the hardware evaluation period. The Programmer only requires a minimum installation of the Intel® Quartus® Prime software, and requires no Intel® Quartus® Prime license. The host computer controls the evaluation time by sending a periodic signal to the device via the JTAG port. If all licensed IP cores in the design support tethered mode, the evaluation time runs until any IP core evaluation expires. If all of the IP cores support unlimited evaluation time, the device does not time-out.
- Untethered—Allows running the design containing the licensed IP for a limited time. The IP core reverts to untethered mode if the device disconnects from the host computer running the Intel® Quartus® Prime software. The IP core also reverts to untethered mode if any other licensed IP core in the design does not support tethered mode.
When the evaluation time expires for any licensed Intel® FPGA IP in the design, the design stops functioning. All IP cores that use the Intel® FPGA IP Evaluation Mode time out simultaneously when any IP core in the design times out. When the evaluation time expires, you must reprogram the FPGA device before continuing hardware verification. To extend use of the IP core for production, purchase a full production license for the IP core.
You must purchase the license and generate a full production license key before you can generate an unrestricted device programming file. During Intel® FPGA IP Evaluation Mode, the Compiler only generates a time-limited device programming file (<project name> _time_limited.sof) that expires at the time limit.
Intel® licenses IP cores on a per-seat, perpetual basis. The license fee includes first-year maintenance and support. You must renew the maintenance contract to receive updates, bug fixes, and technical support beyond the first year. You must purchase a full production license for Intel® FPGA IP cores that require a production license, before generating programming files that you may use for an unlimited time. During Intel® FPGA IP Evaluation Mode, the Compiler only generates a time-limited device programming file (<project name> _time_limited.sof) that expires at the time limit. To obtain your production license keys, visit the Self-Service Licensing Center.
The Intel® FPGA Software License Agreements govern the installation and use of licensed IP cores, the Intel® Quartus® Prime design software, and all unlicensed IP cores.
2.3. Generating IP Cores
- 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 ProjectNote:
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)
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)

- 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)
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.
- 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>.
- 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>.
- 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>.
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 simulators4. 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.
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:
-
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.
-
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.
-
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.
-
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. -
For V-series FPGA variations using the
Intel®
Quartus® Prime IP
Catalog, type the following commands:
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.
- Enable PLL calibration
- Enable Analog controls
- reconfig_to_xcvr (output)
- reconfig_from_xcvr (input)
- 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 5
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
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.
- 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.
<your_ip>/altera_rapidio2_<version>/synth/<your_ip>_altera_rapidio2_<version>_<random_string>.v/.vhd 6
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.
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. |
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.
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
- Physical Layer
- Transport Layer
- Logical Layer
- Capability Registers
- Command and Status Registers
- Error Management Registers
3.1. Physical Layer Settings
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 7.
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
Maximum Baud Rate
Maximum baud rate defines the maximum supported baud rate. The RapidIO II IP core does not support automatic baud rate discovery.
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 8 | No | Yes | Yes | Yes | Yes 8 | 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.
3.1.3. Transceiver Settings
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 - [log2<N> + 9:10] and for Intel® Stratix® 10 devices - [log2<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
- 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.
3.2.3. Disable Destination ID Checking
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
- 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.
- 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.
3.4.1. 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
- 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
- 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
- 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
- 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
- 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 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 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
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
- 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.
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
- 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].
Protocol | Byte Lane (Binary) | |||||||
---|---|---|---|---|---|---|---|---|
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}.
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]9
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 |
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
- 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)
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
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.
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.
Baud Rate (Gbaud) | Default reference clock frequency (MHz)10 | Avalon system clock Frequency (MHz)11 |
---|---|---|
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 |
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
- rst_n — resets the RapidIO II IP core
- tx_ready, tx_analogreset, tx_digitalreset, tx_digitalreset_stat 12, tx_analogreset_stat 12 — reset the transmit side of the transceiver
- rx_ready, rx_analogreset, rx_digitalreset, rx_digitalrest_stat 12, rx_analogreset_stat 12 — 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.
- 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.
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.
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.
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.
4.3. Logical Layer Interfaces
- 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.
4.3.1. Register Access 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
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. |
- 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
4.3.2.1.1. 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. |
- 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.
- 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.
(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.
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.
- 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.
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.
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 13 | 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 | |
011113 | 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 | |
100113 | 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 | |
101013 | 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 | Reserved14 | ||
1100 15 | 0 | 0 | 2 | 1111_1111_1111_1111 |
1 | 0 | 4 | 1111_1111_1111_1111 | |
110115 | 0 | 0 | 6 | 1111_1111_1111_1111 |
1 | 0 | 8 | 1111_1111_1111_1111 | |
111015 | 0 | 0 | 10 | 1111_1111_1111_1111 |
1 | 0 | 12 | 1111_1111_1111_1111 | |
111115 | 0 | 0 | 14 | 1111_1111_1111_1111 |
1 | 0 | 16 | 1111_1111_1111_1111 |
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 16 | 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 | |
011116 | 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 | |
100116 | 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 | |
101016 | 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 |
RapidIO Values | Avalon® -MM Signal Values | |||||
---|---|---|---|---|---|---|
RapidIO Field Values | Payload Size is Multiple of 16 Bytes17 | Burstcount | Byteenable (16'hXXXX) | |||
wrsize (4'bxxxx) | address[0] (1'bx) | 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 | 18 | FFFF | FFFF | 00FF | |
1 | No | 18 | FF00 | FFFF | FFFF |
4.3.2.1.4. Input/Output Avalon-MM Master Module Timing Diagrams
4.3.2.2. Input/Output Avalon-MM Slave Module
- 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).
4.3.2.2.1. 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. |
- 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
IP Core Actions
- 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.
- 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.
Tracking 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.
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.
- 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
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.
(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.
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.
- 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.
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
4.3.2.3. Avalon -MM Burstcount and Byteenable Encoding in RapidIO Packets
Avalon® -MM Signal Values19 | 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 |
Avalon® -MM Signal Values20 | RapidIO Header Field Values | |||
---|---|---|---|---|
burstcount (5'dx, 128-bit units) 21 | byteenable (16'hxxxx) | wdptr (1'bx) | rdsize (4'bxxxx)21 | 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 |
Avalon® -MM Signal Values22 | RapidIO Header Field Values | ||||
---|---|---|---|---|---|
burstcount (Decimal, 128-bit units) | byteenable (16'hxxxx) | wdptr (1'bx) | wrsize (4'bxxxx) | address[0] (rio_addr[3]) | |
Initial | Final | ||||
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 |
4.3.2.4. Input/Output Avalon -MM Slave Module Timing Diagrams
4.3.3. Maintenance Module
- Type 8 – MAINTENANCE read and write requests and responses
- Type 8 – Port-write packets
- Single slave write transfer with variable wait-states
- Pipelined read transfers with variable latency
- Single master write transfer
- Pipelined master read transfers
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
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. |
- Received port-write.
- Various error conditions, including a MAINTENANCE read request or MAINTENANCE write request that targets an out-of-bounds address.
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
4.3.3.3.1. IP Core Actions
- 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.
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.
- prio
- destinationID
- hop_count
- A base register: Tx Maintenance Mapping Window n Base
- A mask register: Tx Maintenance Mapping Window n Mask
- An offset register: Tx Maintenance Mapping Window n Offset
- A control register: Tx Maintenance Mapping Window n Control
For each defined and enabled window, the 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.
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
4.3.3.5.1. IP Core Actions
- 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.
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
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
- 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
- DESTINATION_ID
- priority
- wrsize
- 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
4.3.3.6.3. Port-Write Reception
- 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.
4.3.3.7. Maintenance Interface Transaction Examples
- 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
User Operation | Device ID Width | Payload Size |
---|---|---|
Send MAINTENANCE write request | 8-bit | 32-bit |
- Set up the registers.
- Perform a write transfer on the Maintenance Avalon-MM slave interface.
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
User Operation | Device ID Width | Payload Size |
---|---|---|
Receive MAINTENANCE write request | 8-bit | 32-bit |
- 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
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
User Operation | Device ID Width | Payload Size |
---|---|---|
Send MAINTENANCE read request | 16-bit | 0 |
Receive MAINTENANCE read response | 16-bit | 32-bit |
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.
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
User Operation | Device ID Width | Payload Size |
---|---|---|
Receive MAINTENANCE read request | 16-bit | 0 |
Send MAINTENANCE read response | 16-bit | 32-bit |
- 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
User logic presents the read responses on the Maintenance Avalon-MM master interface by asserting the usr_mnt_readdatavalid signal while presenting the data on the usr_mnt_data bus.
4.3.3.8. Maintenance Packet Error Handling
- 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
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.
- 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
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
- 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.
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.
- 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
- 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.
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.
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. |
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
- 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 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.
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]23 | 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. |
Field | gen_tx_data Bits | |
---|---|---|
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:...] |
ftype | Field | gen_tx_data Bits | |
---|---|---|---|
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] | |
824 | 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] |
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. |
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. |
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. |
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] |
4.3.5.3. Pass-Through Interface Usage Examples
- 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
User Operation | Operation Type | RapidIO Transaction | Priority | Device ID Width | Payload Size (Bytes) |
---|---|---|---|---|---|
Send write request | Tx | NWRITE | 0 | 8 | 40 |
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
User Operation | Operation Type | RapidIO Transaction | Priority | Device ID Width | Payload Size (Bytes) |
---|---|---|---|---|---|
Receive write request | Rx | NWRITE | 0 | 8 | 40 |
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
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 |
- NREAD Request Transaction
- NREAD Response Transaction
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. |
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
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 |
- NREAD Request Transaction
- NREAD Response Transaction
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 |
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
User Operation | Operation Type | RapidIO Transaction | Priority | Device ID Width | Payload Size (Bytes) |
---|---|---|---|---|---|
Send streaming write request | Tx | SWRITE | 3 | 8 | 40 |
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
User Operation | Operation Type | RapidIO Transaction | Priority | Device ID Width | Payload Size (Bytes) |
---|---|---|---|---|---|
Receive streaming write request | Rx | SWRITE | 3 | 8 | 40 |
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
- 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.
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.
- 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.
- 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.
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
- 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
4.5.1. Low-level Interface Receiver
- 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
- 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 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.
- 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
4.6.1. Physical Layer Error Management
- Protocol violations
- Transmission 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.
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
- 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.
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.
- Malformed request or response packets
- Unexpected Transaction ID
- Missing response (time-out)
- Response with ERROR status
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
- Standard error management registers
- Registers in the implementation defined space
- The Avalon-MM slave interface’s error indication signal
- 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).
- WRITE_OUT_OF_BOUNDS
- READ_OUT_OF_BOUNDS
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
- 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
4.6.2.3. Port-Write Reception Module
- 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
- Standard error management registers
- Registers in the implementation defined space
- The Avalon-MM slave interface's error indication signal
- 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.
- INVALID_READ_BURSTCOUNT
- INVALID_READ_BYTEENABLE
- INVALID_WRITE_BYTEENABLE
- INVALID_WRITE_BURSTCOUNT
- WRITE_OUT_OF_BOUNDS
- READ_OUT_OF_BOUNDS
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
- Standard error management registers
- Response packets with ERROR status
- 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.
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
5.1. Global 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. |
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
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
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
5.2.2.1. Multicast Event Signals
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
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
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 |