RapidIO Intel FPGA IP User Guide
Version Information
Updated for: |
---|
Intel® Quartus® Prime Design Suite 20.3 |
Product Discontinuance Notification
Attention:
The RapidIO 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 Intel FPGA IP Core
The RapidIO Intel FPGA IP core complies with the RapidIO v2.1 specification and targets high-performance, multicomputing, high-bandwidth, and coprocessing I/O applications. The RapidIO Interconnect is an open standard developed by the RapidIO Trade Association. It is a high-performance packet-switched interconnect technology designed to pass data and control information between microprocessors, digital signal processors (DSPs), communications and network processors, system memories, and peripheral devices.
1.1. Features
The RapidIO IP core has the following features:
- Compliant with RapidIO Interconnect Specification, Revision 2.1, August 2009, available from the RapidIO Trade Association website.
- Successfully passed RIOLAB’s Device Interoperability Level-3 (DIL-3) testing.
- Supports 8-bit or 16-bit device IDs.
- Supports incoming and outgoing multi-cast events.
- All RapidIO IP core variations include configuration of the high-speed transceivers on the device.
- All RapidIO IP core variations have a Transport layer.
- Physical layer
features:
- 1x/2x/4x serial with integrated transceivers in selected device families and support for external transceivers in older device families.
- All four standard serial data rates supported: 1.25, 2.5, 3.125, and 5.0 gigabaud (Gbaud).
- Receive/transmit packet buffering, flow control, error detection, packet assembly, and packet delineation.
- Automatic freeing of resources used by acknowledged packets.
- Automatic retransmission of retried packets.
- Scheduling of transmission, based on priority.
- Automatic recovery from fatal errors.
- Optional automatic resetting of link partner after detection of fatal errors.
- Support for synchronizing with link partner’s expected ackID after reset.
- Full control over integrated transceiver parameters.
- Configurable number of recovery attempts after link response time-out before declaring fatal error.
- Transport layer
features:
- Supports multiple Logical layer modules.
- A round-robin outgoing scheduler chooses packets to transmit from various Logical layer modules.
- Logical layer
features:
- Generation and management of transaction IDs.
- Automatic response generation and processing.
- Request to response time-out checking.
- Capability registers (CARs) and command and status registers (CSRs).
- Direct register access, either remotely or locally.
- Maintenance master and slave Logical layer modules.
- Input/Output Avalon® Memory-Mapped ( Avalon® -MM) master and slave Logical layer modules with burst support.
- Avalon® streaming ( Avalon® -ST) interface for custom implementation of message passing.
- Doorbell module supporting 16 outstanding DOORBELL packets with time-out mechanism.
- Support for preservation of transaction order between outgoing DOORBELL messages and I/O write requests.
- New registers and interrupt indicate NWRITE_R transaction completion.
- Support for preservation of transaction order between outgoing I/O read requests and I/O write requests from Avalon® -MM interfaces.
- Platform Designer (Standard) support.
- IP functional simulation models for use in Intel® -supported VHDL and Verilog HDL simulators.
- Support for Intel® FPGA IP Evaluation Mode.
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
- MAINTENANCE port-write request
- DOORBELL request and response
1.2. Device Family Support
The following are the device support level definitions for Intel® FPGA IP cores:
FPGA Device Families |
---|
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 |
---|---|
Arria® II GX | Final |
Arria II GZ | Final |
Arria® V (GX, GT, GZ, SX, and ST) | Final |
Intel® Arria® 10 | Final |
Cyclone® IV GX1 | Final |
Cyclone® V (GX, GT, SX, and ST) | Final |
Intel® Cyclone® 10 GX | Final |
Stratix® IV | Final |
Stratix IV GT | Final |
Stratix® V | Final |
Other device families | No support |
1.3. IP Core Verification
Before releasing a version of the RapidIO IP core, Intel® runs comprehensive regression tests in the current version of the Intel® Intel® Quartus® Prime software. These tests use the parameter editor and the Platform Designer (Standard) system integration tool to create the instance files. These files are tested in simulation and hardware to confirm functionality.
Intel® also performs interoperability testing to verify the performance of the IP core and to ensure compatibility with ASSP devices.
The RapidIO IP core v9.0 successfully passed RIOLAB’s Device Interoperability Level-3 (DIL-3) testing in 2009.
1.3.1. Simulation Testing
- ModelSim*
- VCS* in combination with the Synopsys Native Testbench (NTB)
- Xcelium*
The test suite contains testbenches that use the RapidIO bus functional model (BFM) from the RapidIO Trade Association to verify the functionality of the IP core.
The regression suite tests various functions, including the following functionality:
- Link initialization
- Packet format
- Packet priority
- Error handling
- Throughput
- Flow control
Constrained random techniques generate appropriate stimulus for the functional verification of the IP core. Functional coverage metrics measure the quality of the random stimulus, and ensure that all important features are verified.
1.3.2. Hardware Testing
Intel® tests and verifies the RapidIO IP core in hardware for different platforms and environments.
The hardware tests cover 1x, 2x, and 4x variations running at 1.25, 2.5, 3.125, and 5.0 Gbaud, and processing the following traffic types:
- NREADs of various size payloads—4 bytes to 256 bytes
- NWRITEs of various size payloads—4 bytes to 256 bytes
- NWRITE_Rs of several different size packets
- SWRITEs
- Port-writes
- DOORBELL messages
- MAINTENANCE reads and writes
The hardware tests also cover the following control symbol types:
- Status
- Packet-accepted
- Packet-retry
- Packet-not-accepted
- Start-of-packet
- End-of-packet
- Link-request, Link-response
- Stomp
- Restart-from-retry
- Multicast-event
1.3.3. Interoperability Testing
Intel® performs interoperability tests on the RapidIO IP core, which certify that the RapidIO IP core is compatible with third-party RapidIO devices.
Intel® performs interoperability testing with processors and switches from various manufacturers including:
- Texas Instruments Incorporated
- Integrated Device Technology, Inc. (IDT)
Testing of additional devices is an on-going process.
In addition, the RapidIO IP core v9.0 successfully passed RIOLAB’s Device Interoperability Level-3 (DIL-3) testing in 2009.
1.4. Performance and Resource Utilization
The numbers of LEs, combinational ALUTs, ALMs, and primary logic registers are rounded up to the nearest 100.
Device | Parameters | ALMs | Combinational ALUTs | Logic Registers | Memory Blocks (M20K) 2 | ||
---|---|---|---|---|---|---|---|
Variation | Mode | Baud Rate (Gbaud) | |||||
Intel® Arria® 10 | Physical and Transport layers, I/O master and slave, and Maintenance master and slave | 1x | 5.00 | 12500 | 15000 | 17000 | 58 |
2x | 5.00 | 13300 | 15800 | 17700 | 52 | ||
4x | 3.125 | 12800 | 15400 | 17400 | 52 |
Device | Parameters | ALMs | Combinational ALUTs | Logic Registers | Memory Blocks (M20K)3 2 | ||
---|---|---|---|---|---|---|---|
Variation | Mode | Baud Rate (Gbaud) | |||||
Intel® Cyclone® 10 GX | Physical and Transport layers, I/O master and slave, and Maintenance master and slave | 1x | 5.00 | 12859 | 14855 | 17074 | 58 |
2x | 5.00 | 13272 | 15478 | 17660 | 52 | ||
4x | 3.125 | 13230 | 15478 | 17349 | 52 |
Device | Parameters | ALMs | Combinational ALUTs | Logic Registers | Memory Blocks | ||
---|---|---|---|---|---|---|---|
Variation | Mode | Baud Rate (Gbaud) | |||||
Arria® V GX | Physical and Transport layers, I/O master and slave, and Maintenance master and slave | 1x | 5.00 | 9700 | 13100 | 14600 | 113 |
2x | 3.125 | 11200 | 15500 | 17000 | 116 | ||
4x | 11000 | 15100 | 17700 | 116 | |||
Arria® V GZ | 1x | 5.00 | 9700 | 13300 | 14700 | 63 | |
2x | 11400 | 15100 | 17600 | 56 | |||
4x | 11300 | 15500 | 18000 | 63 | |||
Cyclone® V GX | 1x | 3.125 | 9600 | 13700 | 14500 | 115 | |
2x | 11200 | 15500 | 17000 | 116 | |||
4x | 2.5 | 11000 | 15500 | 17600 | 116 | ||
Stratix® V GX | 1x | 5.00 | 9700 | 13300 | 14500 | 63 | |
2x | 11300 | 15100 | 17500 | 57 | |||
4x | 11000 | 15000 | 17600 | 64 |
Device | Parameters | Combinational ALUTs | Logic Registers | Memory Blocks (M9K) 5 | ||
---|---|---|---|---|---|---|
Variation | Mode | Baud Rate (Gbaud) | ||||
Cyclone IV GX | Physical and Transport layers, I/O master and slave, and Maintenance master and slave | 1× | 3.125 | 22400 | 13600 | 123 |
4× | 1.25 | 25200 | 15600 | 123 |
Device | Parameters | ALMs | Combinational ALUTs | Logic Registers | Memory Blocks (M9K)5 | ||
---|---|---|---|---|---|---|---|
Variation | Mode | Baud Rate (Gbaud) | |||||
Stratix IV GX | Physical and Transport layers, I/O master and slave, and Maintenance master and slave | 1x | 3.125 | 12000 | 13000 | 14000 | 44 |
4x | 13900 | 15100 | 16600 | 42 | |||
Arria® II GX | 1x | 3.125 | 12700 | 12900 | 13800 | 115 | |
4x | 14000 | 14200 | 16000 | 112 | |||
Arria® II GZ | 1x | 5.00 | 11900 | 12700 | 13900 | 115 | |
4x | 3.125 | 13700 | 15000 | 16400 | 115 |
1.5. Device Speed Grades
Device Family | Mode | Rate | 1.25 Gbaud | 2.5 Gbaud | 3.125 Gbaud | 5.0 Gbaud | |
---|---|---|---|---|---|---|---|
fMAX | 1x, 2x | 31.25 MHz | 62.50 MHz | 78.125 MHz | 125 MHz | ||
4x | 62.5 MHz | 125 MHz | 156.25 MHz | 250 MHz | |||
Intel® Arria® 10 | 1x | -1, -2, -3 | -1, -2, -3 | -1, -2, -3 | -1, -2 | ||
2x | -1, -2, -3 | -1, -2, -3 | -1, -2, -3 | -1, -2 | |||
4x | -1, -2, -3 | -1, -2, -3 | -1, -2, -3 | -1, -2 | |||
Arria® V (GX, GT, SX, ST) | 1x | C4, -5, C6 | C4, -5, C6 | C4, -5, C6 | C46 | ||
2x | C4, -5, C6 | C4, -5, C6 | C4, -5, C6 | C4, -5 | |||
4x | C4, -5, C6 | C4, -5 | C4 6 | 7 | |||
Arria® V GZ | 1x | -3, -4 | -3, -4 | -3, -4 | -3 | ||
2x | -3, -4 | -3, -4 | -3, -4 | -3, -4 | |||
4x | -3, -4 | -3, -4 | -3, -4 | -3 | |||
Stratix® V | 1x | C1, -2, -3, -4 | C1, -2, -3, -4 | C1, -2, -3, -4 | C1, -2, -3 | ||
2x | C1, -2, -3, -4 | C1, -2, -3, -4 | C1, -2, -3, -4 | C1, -2, -3, -4 | |||
4x | C1, -2, -3, -4 | C1, -2, -3, -4 | C1, -2, -3, -4 | C1, -2, -38 | |||
Intel® Cyclone® 10 GX | 1x | -5, -6 | -5, -6 | -5, -6 | -5 | ||
2x | -5, -6 | -5, -6 | -5, -6 | -5 | |||
4x | -5, -6 | -5, -6 | -5, -6 | -5 | |||
Cyclone® V (GX, GT9, SX, ST) | 1x | C6, -7, C8 | C6, -7, C8 | C6, -7, C8 | C710 | ||
2x | C6, -7 | C6, -7 | C6, -7 | -711 | |||
4x | C6, -7, C8 | C6, -7 | 7 | 7 |
Device Family | Mode | 1x | 4x | ||||||
---|---|---|---|---|---|---|---|---|---|
Rate | 1.25 Gbaud | 2.5 Gbaud | 3.125 Gbaud | 5.0 Gbaud | 1.25 Gbaud | 2.5 Gbaud | 3.125 Gbaud | 5.0 Gbaud | |
fMAX | 31.25 MHz | 62.50 MHz | 78.125 MHz | 125 MHz | 62.5 MHz | 125 MHz | 156.25 MHz | 250 MHz | |
Arria II GX | -4, -5, -6 | -4, -5, -6 | -4, -5, -6 | 7 | -4, -5, -6 | -4, -5 | -4, -5 | 7 | |
Arria II GZ | -3, -4 | -3, -4 | -3, -4 | -3 | -3, -4 | -3, -4 | -3, -4 | 7 | |
Stratix IV | -2, -3, -4 | -2, -3, -4 | -2, -3, -4 | -2, -3, -4 | -2, -3, -4 | -2, -3, -4 | -2, -3, -4 | -2, -312 | |
Cyclone IV GX13 | -6, -7, -8 | -6, -7, -8 | -6, -7 | 7 | -6, -7, -8 | -614 | 7 | 7 |
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 | 20.3 |
Release Date | 2020.09.28 |
Ordering Code | IP-RIOPHY |
2. Getting Started
You can customize the RapidIO IP core to support a wide variety of applications.
When you generate the IP core you can choose whether or not to generate a simulation model. If you generate a simulation model, Intel® provides a Verilog testbench customized for your IP core variation. If you specify a VHDL simulation model, you must use a mixed-language simulator to run the testbench, or create your own VHDL-only simulation environment.
The following sections provide generic instructions and information for Intel® FPGA IP cores. It explains how to install, parameterize, simulate, and initialize the RapidIO IP core.
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.1.1. 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.2. 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 (IDLE1 up to 5.0 Gbaud) IP core to customize. The New IP Variation window appears.
-
Specify a top-level name for your custom 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 and Intel® Cyclone® 10 GX variations in the Intel® Quartus® Prime Pro Edition software.)
- <your_ip> .qsys (When you generate any device 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 if provided for your IP core. 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, 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 IP core in any meaningful way.
- 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 and Intel® Cyclone® 10 GX 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.2.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.3. IP Core Generation Output ( Intel Quartus Prime Standard Edition)
2.4. RapidIO IP Core Testbench Files
The RapidIO 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 and simulation files appear in <your_ip>/altera_rapidio_<version>/sim/tb.
- The testbench script appears in <your_ip>/simulation/<vendor>.
- The testbench and simulation files appear in <your_ip>/simulation/submodules.
- The main testbench file is <your_ip>/simulation/submodules/<your_ip>_rapidio_0_tb.v
The RapidIO IP core does not generate an example design. The static design example included in the RapidIO installation directory does not function correctly with Intel® Arria® 10 and Intel® Cyclone® 10 GX IP core variations.
2.5. Simulating IP Cores
The Intel® Quartus® Prime software supports RTL- and gate-level design simulation of Intel® FPGA IP cores in supported EDA simulators15. Simulation involves setting up your simulator working environment, compiling simulation model libraries, and running your simulation.
You can use the functional simulation model and the testbench or example design generated with your IP core for simulation. The functional simulation model and testbench files are generated in a project subdirectory. This directory may also include scripts to compile and run the testbench. For a complete list of models or libraries required to simulate your IP core, refer to the scripts generated with the testbench. You can use the Intel® Quartus® Prime NativeLink feature to automatically generate simulation files and scripts. NativeLink launches your preferred simulator from within the Intel® Quartus® Prime software.
2.5.1. Simulating the Testbench with the ModelSim Simulator
- Start the ModelSim* simulator.
-
In ModelSim*, change directory to the directory where the testbench
simulation script is located:
- For Intel® Arria® 10 and Intel® Cyclone® 10 GX variations, change directory to <your_ip>/sim/mentor.
- For variations other than Intel® Arria® 10 and Intel® Cyclone® 10 GX, change directory to <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
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_rapidio_<version>.tb ld run -all
For example:
set TOP_LEVEL_NAME my_srio_altera_rapidio_171.tb
where "my_srio" is the IP variation.
-
For
Intel®
Arria® 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_rapidio_<version>.tb ld run -all
For example:
set TOP_LEVEL_NAME altera_rapidio_171.tb
-
For variations other than
Intel®
Arria® 10 and
Intel®
Cyclone® 10 GX, type the following
commands:
do msim_setup.tcl set TOP_LEVEL_NAME rapidio_0.tb ld run -all
Simulation of the testbench might take few minutes. The testbench displays a TESTBENCH_PASSED message after completion. -
For
Intel®
Arria® 10 variations
using the
Intel®
Quartus® Prime Standard Edition software,
type the following commands:
2.5.2. Simulating the Testbench with the VCS Simulator
-
Change directory to the directory where the testbench simulation
script is located:
- For Intel® Arria® 10 and Intel® Cyclone® 10 GX variations, change directory to <your_ip>/sim/synopsys.
- For variations other than Intel® Arria® 10 and Intel® Cyclone® 10 GX, change directory to <your_ip>/simulation/synopsys/vcs.
-
Type the following command to set up the required libraries,
compile the generated IP functional model, and exercise the simulation model with the
provided
testbench:
sh vcs_setup.sh TOP_LEVEL_NAME="tb" ./simv
2.5.3. Simulating the Testbench with the Xcelium Simulator
-
Change
directory to the directory where the testbench simulation script is
located:
- For Intel® Arria® 10 and Intel® Cyclone® 10 GX variations, change directory to <your_ip>/sim/xcelium.
-
Type the following command to set up the required libraries,
compile the generated IP functional model, and exercise the simulation model
with the provided testbench:
sh xcelium_setup.sh TOP_LEVEL_NAME="altera_rapidio_<version>.tb" USER_DEFINED_SIM_OPTIONS="-input\\"@run\2ms\;\exit\""
2.6. 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 (Standard) IP catalog and build your design in Platform Designer (Standard), you can perform these steps in Platform Designer (Standard). If you generate your IP core directly from the Intel® Quartus® Prime IP catalog, you must implement these steps manually in your design.
2.6.1. Calibration Clock
For Arria II GX, Arria II GZ, Cyclone IV GX, and Stratix IV GX designs, ensure that you connect the calibration clock (cal_blk_clk) to a clock signal with the appropriate frequency range of 10 to 125 MHz. The cal_blk_clk ports on other components that use transceivers must be connected to the same clock signal.
2.6.2. Dynamic Transceiver Reconfiguration Controller
RapidIO IP core variations that target an Intel® Arria® 10 and Intel® Cyclone® 10 GX devices include a reconfiguration controller block and do not require an external reconfiguration controller. All other RapidIO IP core variations require an external reconfiguration controller to function correctly in hardware.
For Arria II GX, Arria II GZ, Cyclone IV GX, and Stratix IV GX designs with high-speed transceivers, you must add a dynamic reconfiguration block (altgx_reconfig) to your design. You must connect it as specified in device handbook.This block supports offset cancellation. The design compiles without the altgx_reconfig block, but it cannot function correctly in hardware.
For Arria® V, Cyclone® V, and Stratix® V designs, you must add a dynamic reconfiguration block (Transceiver Reconfiguration Controller) to your design, and connect it to the RapidIO IP core dynamic reconfiguration signals reconfig_fromgxb and reconfig_togxb. This block supports offset cancellation. The design compiles without the Transceiver Reconfiguration Controller, but it cannot function correctly in hardware.
For information about the number of reconfiguration interfaces you must configure in your Arria® V, Cyclone® V , or Stratix® V dynamic reconfiguration block, refer to the descriptions of the reconfig_togxb and reconfig_fromgxb signals. An informational message in the RapidIO parameter editor tells you the required number of reconfiguration interfaces.
2.6.3. Transceiver Settings
If you want to modify the high-speed transceiver settings in an Arria II GX, Arria II GZ, Cyclone IV GX, or Stratix IV GX variation, you must first generate the IP core and then edit the existing ALTGX megafunction in the Intel® Quartus® Prime software. Regenerating overwrites the changes.
The ALTGX megafunction that is generated in your RapidIO IP core is not accessible through Platform Designer (Standard). You must edit this megafunction using the Intel® Quartus® Prime software.
If your RapidIO IP core targets an Arria® V, Cyclone® V, or Stratix® V device, Intel® recommends you do not modify the default transceiver settings configured in the Custom PHY IP core instance generated with the RapidIO IP core.
If your RapidIO IP core targets Intel® Arria® 10 and Intel® Cyclone® 10 GX devices, Intel® recommends you do not modify the default transceiver settings configured in the Intel® Arria® 10 Native PHY and the Intel® Cyclone® 10 GX Transceiver Native PHY IP cores.
2.6.4. Adding Transceiver Analog Settings for Arria II GX, Arria II GZ, and Stratix IV GX Variations
For Arria II GX, Arria II GZ, and Stratix IV GX designs, after you generate the system, you must create assignments for the high-speed transceiver VCCH settings by following these instructions:
- In the Intel® Quartus® Prime window, on the Assignments menu, click Assignment Editor.
- In the <<new>> cell in the To column, type the top-level signal name for your RapidIO IP core instance td signal.
- Double-click in the Assignment Name column and click I/O Standard.
- Double-click in the Value column and click your standard (for example, 1.5-V PCML).
- In the <<new>> row, repeat steps 2 to 4 for your RapidIO IP core instance rd signal.
2.6.5. External Transceiver PLL
RapidIO IP cores that target Intel® Arria® 10 and Intel® Cyclone® 10 GX devices require an external TX transceiver PLL to compile and to function correctly in hardware. You must instantiate and connect this IP core to the RapidIO IP core.
You can create an external transceiver PLL from the IP Catalog. Select the ATX PLL IP core or the fPLL IP core. In the PLL parameter editor, set the following parameter values:
- Set PLL output frequency to one half the value you select for the Baud rate parameter in the RapidIO parameter editor. The transceiver performs dual edge clocking, using both the rising and falling edges of the input clock from the PLL. Therefore, this PLL output frequency setting supports the customer-selected maximum data rate on the RapidIO link.
- Set PLL reference clock frequency to the value you select for the Reference clock frequency parameter in the RapidIO parameter editor.
- Turn on Include Master Clock Generation Block.
- Turn on Enable bonding clock output ports.
- Set PMA interface width to 20.
When you generate a RapidIO IP core, the Quartus Prime software also generates the HDL code for an ATX PLL, in the following file: <your_ip>/altera_rapidio_<version>/synth/<your_ip>_altera_rapidio_<version>_<random_string>.v/.vhd.16
However, the HDL code for the RapidIO IP core does not instantiate the ATX PLL. If you choose to use the ATX PLL provided with the RapidIO IP core, you must instantiate and connect the ATX PLL instance with the RapidIO IP core in user logic.
You must connect the TX PLL IP core to the RapidIO IP core according to the following rules.
Signal | Direction | Connection Requirements |
---|---|---|
pll_refclk0 | Input | Drive the PLL pll_refclk0 input port and the RapidIO IP core reference clock clk signal from the same clock source. The minimum allowed frequency for the pll_refclk0 clock in Intel® Arria® 10 and Intel® Cyclone® 10 GX 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 IP core input ports. |
To see how to configure and connect a TX PLL IP core to the other system components, such as the external reset controller, refer to the cleartext testbench files.
2.6.6. Transceiver PHY Reset Controller for Intel Arria 10 and Intel Cyclone 10 GX Variations
You must add a Transceiver PHY Reset Controller IP core to your design, and connect it to the RapidIO IP core reset signals. This block implements a reset sequence that resets the device transceivers correctly.
- Leave unchecked the Use separate RX reset per channel option.
When you generate a RapidIO IP core that target Intel® Arria® 10 and Intel® Cyclone® 10 GX devices, the Intel® Quartus® Prime software generates the HDL code for the Transceiver PHY Reset Controller in the following file: <your_ip>/altera_rapidio_<version>/synth/<your_ip>_altera_rapidio_<version>_<random_string>.v/.vhd 17
2.7. Specifying Timing Constraints
To use the generated constraint files, follow these steps:
- Open your project in the Intel® Quartus® Prime software.
- On the View menu, point to Utility Windows and then click Tcl Console.
- Source the generated constraint file by typing
the following command at the Tcl console command prompt:
source <variation_name>/synthesis/submodules/<instance_name >_constraints.tcl
- Add the Rapid IO constraints to your project
by typing the following command at the Tcl console command prompt:
add_rio_constraints
This command adds the necessary logic constraints to your Intel® Quartus® Prime project.
If you rename any clocks in Platform Designer (Standard), you require the -ref_clk_name, -sys_clk_name, -phy_mgmt_clk, and -patch_sdc command-line options specified.
The script automatically constrains the system clocks and the reference clock based on the data rate chosen. For supported transceivers, Intel® recommends that you adjust the reference clock frequency in the Physical Layer tab of the RapidIO parameter editor only. However, you can adjust the system clock frequency in the Tcl constraints script or the generated Synopsys Design Constraint File (.sdc).
The Tcl script assumes that virtual pins and I/O standards are connected to Intel® -provided pin names. For user-defined pin names, you must edit the script after generation to ensure that the assignments are made properly.
The add_rio_constraints command has the following additional options that you can use:
add_rio_constraints [-no_compile] [-ref_clk_name <name>] [-sys_clk_name <name>] [-phy_mgmt_clk_name <name>] [-patch_sdc] [-help]
Constraint | Use |
---|---|
-no_compile | Use the -no_compile option to prevent analysis and synthesis. Use this option only if you performed analysis and synthesis or fully compiled your project prior to using this script. Using this option decreases turnaround time during development. |
-ref_clk_name | The Rapid IO IP core
has a top-level reference clock name clk. If, in Platform Designer (Standard), you rename this clock
or you connect the reference clock port of the IP core to a clock named
something other than clk, you must run the add_rio_constraints command with this
option followed by the name of the clock connected to the reference clock port
of the RapidIO IP core. The following example command illustrates the
syntax:
add_rio_constraints -ref_clk_name CLK125 |
-sys_clk_name | By default, the
Avalon®
system clock name used for the RapidIO IP core is named sysclk. If, in Platform Designer (Standard), you
rename this clock or connect it to a clock named something other than sysclk, you must run the
add_rio_constraints command with this option followed by the
updated clock name. The following example command illustrates the syntax:
add_rio_constraints -sys_clk_name CLK50 |
-phy_mgmt_clk_name | This option is
available only for RapidIO variations that target an
Arria® V,
Cyclone® V, or
Stratix® V device. By default, the PHY IP core management clock, which is
present only in RapidIO variations that target an
Arria® V,
Cyclone® V, or
Stratix® V device, is named phy_mgmt_clk. If, in Platform Designer (Standard), you rename this clock or you connect it
to a clock named something other than <variation>_phy_mgmt_clk, you must run the add_rio_constraints
command with this option followed by the updated clock name. The following
example command illustrates the syntax:
add_rio_constraints -phy_mgmt_clk_name CLK_PHY_MGMT |
-patch_sdc | This option is only valid when used with the -ref_clk_name, -sys_clk_name, or -phy_mgmt_clk option. The -patch_sdc option patches the generated SDC script with the new clock names. A back-up copy of the SDC script is created before the patch is made, and any edits that were previously made to the SDC script are preserved. |
-help | Use the -help option for information about the options used with the add_rio_constraints command. |
2.8. Compiling the Full Design and Programming the FPGA
2.9. Instantiating Multiple RapidIO IP Cores
If you want to instantiate multiple RapidIO IP cores, a few additional steps are required. The following sections outline these steps.
2.9.1. Clock and Signal Requirements for Arria V, Cyclone V, and Stratix V Variations
When your design targets an Arria® V, Cyclone® V, or Stratix® V device, the transceivers are configured with the Custom PHY IP core. When your design contains multiple RapidIO IP cores, the Intel® Quartus® Prime Fitter handles the merge of multiple Custom PHY IP cores in the same transceiver block automatically. To merge multiple Custom PHY IP cores in the same transceiver block, the Fitter requires that the phy_mgmt_clk_reset input signal for all of the merged IP cores be driven by the same source.
If you have different RapidIO IP cores in different transceiver blocks on your device, you may choose to include multiple Transceiver Reconfiguration Controllers in your design. However, you must ensure that the Transceiver Reconfiguration Controllers that you add to your design have the correct number of interfaces to control dynamic reconfiguration of all your RapidIO IP core transceivers. The correct total number of reconfiguration interfaces is the sum of the reconfiguration interfaces for each RapidIO IP core; the number of reconfiguration interfaces for each RapidIO IP core is the number of channels plus one. You must ensure that the reconfig_togxb and reconfig_fromgxb signals of an individual RapidIO IP core connect to a single Transceiver Reconfiguration Controller.
For example, if your design includes one 4× RapidIO IP core and three 1× RapidIO IP cores, the Transceiver Reconfiguration Controllers in your design must include eleven dynamic reconfiguration interfaces: five for the 4× RapidIO IP core, and two for each of the 1× RapidIO IP cores. The dynamic reconfiguration interfaces connected to a single RapidIO IP core must belong to the same Transceiver Reconfiguration Controller. In most cases, your design has only a single Transceiver Reconfiguration Controller, which has eleven dynamic reconfiguration interfaces. If you choose to use two Transceiver Reconfiguration Controllers, for example, to accommodate placement and timing constraints for your design, each of the RapidIO IP cores must connect to a single Transceiver Reconfiguration Controller.
In the following example, the Transceiver Reconfiguration Controller 0 has seven reconfiguration interfaces, and Transceiver Reconfiguration Controller 1 has four reconfiguration interfaces. Each sub-block shown in a Transceiver Reconfiguration Controller block represents a single reconfiguration interface. The example shows only one possible configuration for this combination of RapidIO IP cores; subject to the constraints described, you may choose a different configuration.
To enable the Intel® Quartus® Prime software to place distinct RapidIO IP cores in the same Arria® V, Cyclone® V, or Stratix® V transceiver block, you must ensure that the phy_mgmt_clk input to each RapidIO IP core is driven by the same programming interface clock.
2.9.2. Clock and Signal Requirements for Arria II GX, Arria II GZ, Cyclone IV GX, and Stratix IV GX Variations
RapidIO IP cores that target an Arria II GX, Arria II GZ, Cyclone IV GX, or Stratix IV GX device all instantiate an ALTGX transceiver megafunction to configure the device transceivers. When your design contains multiple IP cores that use the ALTGX megafunction, you must ensure that the cal_blk_clk and gxb_powerdown input signals are connected properly.
You must ensure that the cal_blk_clk input to each RapidIO IP core (or any other megafunction or user logic that uses the ALTGX megafunction) is driven by the same calibration clock source.
When you merge multiple RapidIO IP cores in a single transceiver block, the same signal must drive gxb_powerdown to each of the RapidIO IP core variations and other megafunctions, IP cores, and user logic that use the ALTGX megafunction.
To successfully combine multiple high-speed transceiver channels in the same transceiver block, they must have the same dynamic reconfiguration setting. If two IP cores implement dynamic reconfiguration in the same transceiver block of an Arria II GX, Arria II GZ, Cyclone IV GX, or Stratix IV GX device, the parameters or characteristics that you want to control with the dynamic reconfiguration megafunction instance must be identical.
To support the dynamic reconfiguration block, turn on Analog controls on the Reconfiguration Settings tab in the transceiver parameter editor. Arria II GX, Arria II GZ, Cyclone IV GX, and Stratix IV GX device transceivers require a dynamic reconfiguration block, to support offset cancellation.
2.9.3. Correcting the Synopsys Design Constraints File to Distinguish RapidIO IP Core Instances
When you instantiate multiple RapidIO IP core instances in your design, you must modify the Synopsys Design Constraints File (.sdc) to repeat the create_generated_clock statements for each IP core instance. The statements must include the full name of the variation in the clock names.
If you do not do this, the source and destination clocks each have multiple matches; the rxclk and clk_div_by_2 filters match the relevant clocks in all of the IP core instances.
2.9.4. Sourcing Multiple Tcl Scripts for Variations other than Intel Arria 10 and Intel Cyclone 10 GX
3. Parameter Settings
You customize the RapidIO IP core by specifying parameters in the RapidIO parameter editor, which you access from the IP Catalog.
This chapter describes the parameters and how they affect the behavior of the IP core.
In the RapidIO parameter editor, you use the following pages from the Parameter Settings tab to parameterize the RapidIO IP core:
- Physical Layer
- Transport and Maintenance
- I/O and Doorbell
- Capability Registers
3.1. Physical Layer Settings
3.1.1. Device Options
- Mode selection
- Transceiver selection
- Automatically synchronize transmitted ackID
- Send link-request reset-device on fatal errors
- Link-request attempts
- Packet-Not-Accepted to Link Request timeout
Mode Selection
Mode selection allows you to specify a 1x serial, 2x serial, or 4x serial port consisting of one-, two-, or four-lane high-speed data serialization and deserialization.
The 2x mode is available only in variations that target an Intel® Arria® 10, Arria® V, Intel® Cyclone® 10 GX, Cyclone® V, or Stratix® V device.
The 2x and 4x variations do not support fallback to 1x or 2x mode. You must know whether the IP core has a 1x, 2x, or 4x link partner and configure the FPGA accordingly. If fallback is required, the FPGA can be programmed with a 2x or 4x variation by default and then reprogrammed to a 1x (or 2x) configuration under system control after failure to synchronize in the original mode.
Transceiver Selection
The Transceiver selection parameter value is determined by the device family your IP core targets.Although this parameter appears in the parameter editor, you cannot modify its value.
Synchronizing Transmitted ackID
Sending Link-Request Reset-Device on Fatal Errors
The Send link-request reset-device on fatal errors option specifies that if the RapidIO IP core identifies a fatal error, it transmits four link-request control symbols with cmd set to reset-device on the RapidIO link. By default, this option is turned off. The option is available for backward compatibility, because previous releases of the RapidIO IP core implement this behavior.
Number of Link-Request Attempts Before Declaring Fatal Error
Packet-Not-Accepted to Link Request timeout
This parameter specifies whether or not the IP core enters a Fatal Error state if it sends a packet-not-accepted control symbol and then does not receive any link-request control symbol from the RapidIO link partner within the period of time indicated in the VALUE field of the PLTCTRL register at offset 0x120. By default, for backward compatibility, this parameter is turned on.
3.1.2. Data Settings
Baud Rate
Baud rate defines the baud rate based on the value that you specify. A device family may include devices at speed grades that do not support all the indicated baud rates. The speed grade tables in this user guide provide information about the speed grades supported for each device family, RapidIO mode, and baud rate combination.
Reference Clock Frequency
Reference clock frequency defines the frequency of the reference clock for your RapidIO IP core internal transceiver. The RapidIO parameter editor allows you to select any frequency supported by the transceiver.
Receive Buffer Size
Receive buffer size defines the receive buffer size in KBytes based on the value that you specify. You can select a receive buffer size of 4, 8, 16, or 32 KBytes.
This parameter is not available for variations that target an Intel® Arria® 10 and Intel® Cyclone® 10 GX devices. RapidIO IP core Intel® Arria® 10 and Intel® Cyclone® 10 GX variations have a Physical layer receive buffer size of 32 KBytes.
Transmit Buffer Size
Transmit buffer size defines the transmit buffer size in KBytes based on the value that you specify. You can select a transmit buffer size of 4, 8, 16, or 32 KBytes.
This parameter is not available for variations that target an Intel® Arria® 10 and Intel® Cyclone® 10 GX devices. RapidIO IP core Intel® Arria® 10 and Intel® Cyclone® 10 GX variations have a Physical layer transmit buffer size of 32 KBytes.
3.1.3. Receive Priority Retry Thresholds
- Priority 2 Threshold > 9
- Priority 1 Threshold > Priority 2 Threshold + 4
- Priority 0 Threshold > Priority 1 Threshold + 4
- Priority 0 Threshold < (receive buffer size x 1024/64)
Receive priority retry threshold values are numbers of 64-byte buffers.
3.1.4. Transceiver Settings
Enable transceiver dynamic reconfiguration
Enable transceiver dynamic reconfiguration parameter allows you to specify whether or not the Intel® Arria® 10 or Intel® Cyclone® 10 GX Native PHY IP core dynamic reconfiguration interface is available in the visible signals of the RapidIO IP core. 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 capability registers
- Set user-defined IP identifier
- Enable transceiver control and status register
- Enable transceiver PRBS soft accumulators
3.2. Transport and Maintenance Settings
The Transport and Maintenance tab lets you enable and configure the Transport layer and Logical layer Input/Output Maintenance modules.
3.2.1. Transport Layer
Enable 16-Bit Device ID Width
All RapidIO IP core variations have a Transport layer. The Transport Layer parameters determine whether the RapidIO IP core uses 8-bit or 16-bit device IDs, whether the Transport layer has an Avalon® -ST pass-through interface, and whether the IP core is in promiscuous mode.
The Enable 16-bit device ID width setting specifies whether the IP core supports an 8-bit device ID width or a 16-bit device ID width. 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.
Enable Avalon® -ST Pass-Through Interface
Turn on Enable Avalon® -ST pass-through interface to include the Avalon® -ST pass-through interface in your RapidIO variation.
The Transport layer routes all unrecognized packets to the Avalon® -ST pass-through interface. Unrecognized packets are those that contain Format Types (ftypes) for Logical layers not enabled in this IP core, or destination IDs not assigned to this endpoint. However, if you disable destination ID checking, the packet is a request packet with a supported ftype, and the Transport Type (tt) field of the packet matches the device ID width setting of this IP core, the packet is routed to the appropriate Logical layer.
Request packets with a supported ftype and correct tt field, but an unsupported ttype, are routed to the Logical layer supporting the ftype, which allows the following tasks:
- An ERROR response can be sent to requests that require a response.
- An unsupported_transaction error can be recorded in the Error Management extension registers.
Response packets are routed to a Logical layer module or the Avalon® -ST pass-through port based on the value of the target transaction ID field.
Destination ID Checking
Disable Destination ID checking by default lets you turn on or off the option to route a request packet with a supported ftype but a destination ID not assigned to this endpoint. The effect of this settings is detailed in the above section.
You specify the initial value for the option in the RapidIO parameter editor, and software can change it by modifying the value of the PROMISCUOUS_MODE bit in the Rx Transport Control register.
This parameter is not available for variations that target Intel® Arria® 10 and Intel® Cyclone® 10 GX devices. RapidIO IP core Intel® Arria® 10 and Intel® Cyclone® 10 GX variations do not check destination IDs by default. However, you can modify the PROMISCUOUS_MODE setting during normal operation.
3.2.2. Input/Output Maintenance Logical Layer Module
Maintenance Logical Layer
The I/O Maintenance Logical Layer Module parameters specify the interface to the Maintenance Logical layer and the number of translation windows.
Maintenance logical layer interface(s) selects which parts of the Maintenance Logical layer to implement. You can specify any one of the following valid options:
- Avalon® -MM Master and Slave
- Avalon® -MM Master (this option is not valid in Intel® Arria® 10 and Intel® Cyclone® 10 GX variations)
- Avalon® -MM Slave (this option is not valid in Intel® Arria® 10 and Intel® Cyclone® 10 GX variations)
- None
For variations that target Intel® Arria® 10 and Intel® Cyclone® 10 GX devices. RapidIO IP core, only two of the values are valid. Intel® Arria® 10 and Intel® Cyclone® 10 GX variations either include a Maintenance Logical layer module ( Avalon® -MM Master and Slave) or do not include a Maintenance Logical layer module (None).
Transmit Address Translation Windows
Number of transmit address translation windows is applicable only if you select Avalon® -MM Slave or Avalon® -MM Master and Avalon® -MM Slave as the Maintenance logical layer interface(s). You can specify a value from 1 to 16 to define the number of transmit address translation windows supported.
This parameter is not available for variations that target Intel® Arria® 10 and Intel® Cyclone® 10 GX devices. RapidIO IP core Intel® Arria® 10 and Intel® Cyclone® 10 GX variations that include a Maintenance Logical layer module have 16 Maintenance transmit address translation windows.
3.2.3. Port Write
The Port Write options control whether the Maintenance Logical layer module can transmit or receive port-write requests. These options are available only if the Maintenance Logical layer has an Avalon® -MM slave port.
These options are not available independently for variations that target Intel® Arria® 10 and Intel® Cyclone® 10 GX devices. RapidIO IP core Intel® Arria® 10 and Intel® Cyclone® 10 GX variations that include a Maintenance Logical layer module either support both reception and transmission of port-write requests, or do not support port-write requests at all (neither reception nor transmission).
Port Write Tx Enable
Port write Tx enable turns on or turns off the transmission of port-write requests by the Maintenance Logical layer module.
Port Write Rx Enable
Port write Rx enable turns on or turns off the reception of port-write requests by the Maintenance Logical layer module.
3.3. I/O and Doorbell Settings
3.3.1. I/O Logical Layer Interfaces
- Avalon® -MM Master and Slave
- Avalon® -MM Master (this option is not valid in Intel® Arria® 10 and Intel® Cyclone® 10 GX variations)
- Avalon® -MM Slave (this option is not valid in Intel® Arria® 10 and Intel® Cyclone® 10 GX variations)
- None
3.3.2. I/O Slave Address Width
I/O slave address width specifies the Input/Output slave address width. The default width is 30 bits.
However, because the I/O Logical layer slave module addresses all hold word address values in 1x variations or double-word address values in 2x and 4x variations, the width of the external I/O Logical layer slave module address buses is the value you specify, minus 2 in 1x variations, or the value you specify, minus 3 in 2x and 4x variations.
3.3.3. I/O Read and Write Order Preservation
I/O read and write order preservation controls support for order preservation between read and write operations (NWRITE, NWRITE_R, SWRITE, and NREAD requests) in the I/O Avalon® -MM Logical layer slave module. By default this feature is turned off.
This parameter is available only if you set I/O logical layer Interfaces to Avalon® -MM Master and Slave or Avalon® -MM Slave.
This parameter is not available for variations that target Intel® Arria® 10 and Intel® Cyclone® 10 GX devices. RapidIO IP core Intel® Arria® 10 and Intel® Cyclone® 10 GX variations that include an I/O Logical layer Avalon® -MM slave module preserve transaction ordering between read and write operations in the I/O Avalon® -MM Logical layer slave module.
Whether you turn on this feature or not, as required by the Avalon® -MM specification, each individual Logical layer Avalon® -MM slave module preserves response order. Even if the responses to two requests from the same Logical layer Avalon® -MM slave module arrive in reverse order on the RapidIO link, the Logical layer module enforces the response order on the Avalon® -MM interface. The slave module enforces the order by maintaining a queue of the Transaction IDs of transactions awaiting responses from the RapidIO link.
3.3.4. Avalon -MM Master
Number of Rx address translation windows is only applicable if you select an I/O Avalon® -MM master as an I/O Logical layer interface. You can specify a value from 1 to 16.
This parameter is not available for variations that target Intel® Arria® 10 and Intel® Cyclone® 10 GX devices. RapidIO IP core Intel® Arria® 10 and Intel® Cyclone® 10 GX variations that include I/O Logical layer master module have 16 Rx address translation windows.
3.3.5. Avalon -MM Slave
Number of Tx address translation windows is only applicable if you select an I/O Avalon® -MM slave as an I/O Logical layer interface. You can specify a value from 1 to 16.
This parameter is not available for variations that target Intel® Arria® 10 and Intel® Cyclone® 10 GX devices. RapidIO IP core Intel® Arria® 10 and Intel® Cyclone® 10 GX variations that include I/O Logical layer slave module have 16 Tx address translation windows.
3.3.6. Doorbell Slave
Doorbell Tx enable controls support for the generation of outbound DOORBELL messages.Doorbell Rx enable controls support for the processing of inbound DOORBELL messages. If not enabled, 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.
These parameters are linked for variations that target Intel® Arria® 10 and Intel® Cyclone® 10 GX devices. RapidIO IP core Intel® Arria® 10 and Intel® Cyclone® 10 GX variations either support outbound and inbound DOORBELL messages, or do not support DOORBELL messages. If you turn on one of these options, you must turn on both.
Prevent doorbell messages from passing write transactions controls support for preserving transaction order between DOORBELL messages and I/O write request transactions. This option is available only if you turn on Doorbell Tx enable and set I/O logical layer Interfaces to Avalon® -MM Master and Slave or Avalon® -MM Slave.
This parameter is not available for variations that target Intel® Arria® 10 and Intel® Cyclone® 10 GX devices. RapidIO IP core Intel® Arria® 10 and Intel® Cyclone® 10 GX variations that support DOORBELL messages preserve transaction order between DOORBELL messages and I/O write request transactions.
3.4. Capability Registers Settings
3.4.1. Device Registers
Device ID
Vendor ID
Vendor ID uniquely identifies the vendor and sets the VENDOR_ID field in the Device Identity register. Set Vendor ID to the identifier value assigned by the RapidIO Trade Association to your company.
Revision ID
Revision ID identifies the revision level of the device. This value in the Device Information register is assigned and managed by the vendor specified in the VENDOR_ID field of the Device Identity register.
3.4.2. Assembly Registers
The Assembly Registers options identify the vendor who manufactured the assembly or subsystem of the device. These registers include the Assembly Identity and the Assembly Information CARs.
Assembly ID
Assembly ID corresponds to the ASSY_ID 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 ASSY_VENDOR_ID field of the Assembly Identity register.
Assembly Vendor ID
Assembly vendor ID uniquely identifies the vendor who manufactured the assembly. This value corresponds to the ASSY_VENDOR_ID field of the Assembly Identity register.
Assembly Revision ID
Assembly revision ID indicates the revision level of the assembly and sets the ASSY_REV field of the Assembly Information CAR.
Extended Features Pointer
Extended features pointer points to the first entry in the extended feature list and corresponds to the EXT_FEATURE_PTR in the Assembly Information CAR.
3.4.3. Processing Element Features
The Processing Element Features CAR identifies the major features of the processing element.
Bridge Support
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
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
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.
3.4.4. Switch Support
Enable Switch Support
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.
Number of Ports
Number of ports specifies the total number of ports on the processing element. This value sets the PORT_TOTAL field of the Switch Port Information CAR.
Port Number
Port number sets the PORT_NUMBER 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.5. Data Messages
Source Operation
Source operation, when turned on, sets the Data Message bit in the Source Operations CAR and indicates that this endpoint can issue Data Message request packets.
Destination Operation
Destination operation, when turned on, sets the Data Message bit in the Destination Operations CAR and indicates that this endpoint can process received Data Message request packets.
4. Functional Description
4.1. Interfaces
- RapidIO Interface
- Avalon® Memory Mapped ( Avalon® -MM) Master and Slave Interfaces
- Avalon® Streaming ( Avalon® -ST) Interface
4.1.1. RapidIO Interface
The RapidIO interface complies with revision 2.1 of the RapidIO serial interface standard described in the RapidIO Trade Association specifications. The protocol is divided into a three-layer hierarchy: Physical layer, Transport layer, and Logical layer.
4.1.2. Avalon Memory Mapped ( Avalon -MM) Master and Slave Interfaces
The Avalon® -MM master and slave interfaces execute transfers between the RapidIO IP core and the system interconnect. The system interconnect allows you to use the Platform Designer (Standard) Platform Designer (Standard) system integration tool to connect any master peripheral to any slave peripheral, without detailed knowledge of either the master or slave interface. The RapidIO IP core implements both Avalon® -MM master and Avalon® -MM slave interfaces.
4.1.2.1. Avalon -MM Interface Widths in the RapidIO IP Core
- I/O Logical layer master and slave interfaces have a databus width of 32 bits in 1x variations and a databus width of 64 bits in 2x and 4x variations.
- Maintenance module has a databus width of 32 bits.
- Doorbell module has a databus width of 32 bits.
4.1.2.2. 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 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].
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] | 32-Bit Word[0:31] | |||||||
wdptr=0 | wdptr=1 | |||||||
Double Word[0:63] | ||||||||
RapidIO 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] | 32-Bit Word[31:0] | |||||||
Avalon® -MM Address = N+4 | Avalon® -MM Address = N | |||||||
64-bit Double Word0[63:0] | ||||||||
Avalon® -MM Address = N |
In variations of the RapidIO IP core that have 32-bit wide Avalon® -MM interfaces, the order in which the two 32-bit words in a double word appear on the Avalon® -MM interface in a burst transaction, is inverted from the order in which they appear inside a RapidIO packet. The RapidIO 32-bit word with wdptr=0 is the most significant half of the double word at RapidIO address N, and the 32-bit word with wdptr=1 is the least significant 32-bit word at RapidIO address N. Therefore, in a burst transaction on the Avalon® -MM interface, the 32-bit word with wdptr=0 corresponds to the Avalon® -MM 32-bit word at address N+4 in the Avalon® -MM address space, and must follow the 32-bit word with wdptr=1 which corresponds to the Avalon® -MM 32-bit word at address N in the Avalon® -MM address space. Thus, when a burst of two or more 32-bit Avalon® -MM words is transported in RapidIO packets, the order of the pair of 32-bit words is inverted so that the most significant word of each pair is transmitted or received first in the RapidIO packet.
4.1.3. Avalon Streaming ( 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 either 32 or 64 bits wide depending on the RapidIO lane width. This interface is available to create custom Logical layer functions like message passing.
4.2. Clocking and Reset Structure
4.2.1. RapidIO IP Core Clocking
- sysclk: Avalon® system clock.
- clk: : reference clock for the transceiver Tx PLL and Rx PLL. In Intel® Arria® 10 and Intel® Cyclone® 10 GX variations, this clock port drives only the Rx PLL.
- cal_blk_clk: transceiver calibration-block clock (Arria II GX, Arria II GZ, Cyclone IV GX, and Stratix IV GX variations only).
- reconfig_clk: transceiver reconfiguration interface clock (Arria II GX, Arria II GZ, Cyclone IV GX, and Stratix IV GX variations only).
- phy_mgmt_clk: transceiver software interface clock ( Arria® V, Arria® V GZ, Cyclone® V, and Stratix® V variations only).
- tx_bonding_clocks_chN: Intel® Arria® 10 and Intel® Cyclone® 10 GX devices transceiver channel clocks for the transceiver channel that corresponds to RapidIO lane N ( Intel® Arria® 10 and Intel® Cyclone® 10 GX variations only)
In addition, if you turn on Enable transceiver dynamic reconfiguration for your RapidIO Intel® Arria® 10 and Intel® Cyclone® 10 GX variations, the IP core includes a reconfig_clk_chN input clock for each RapidIO lane N . Each reconfig_clk_chN clocks the Intel® Arria® 10 and Intel® Cyclone® 10 GX Native PHY dynamic reconfiguration interface for RapidIO lane N.
The RapidIO IP core supports ±100 ppm reference clock difference and can handle a maximum difference of ±200 ppm between the rxclk and txclk clocks.
The RapidIO IP core provides the following clock outputs from the transceiver:
- Transceiver receiver clock (recovered clock) (rxgxbclk)
- Recovered data clock (rxclk). Recovered clock that drives the receiver modules in the Physical layer.
- Transceiver transmit-side clock (txclk). Main clock for the transmitter modules in the Physical layer.
RapidIO IP core 2x and 4x variations are implemented in the transceiver TX bonded mode. All channels of a 2x or 4x variation, on any supported device, must reside in a single transceiver block.
To support this requirement in Arria II GX, Arria II GZ, Cyclone IV GX, and Stratix IV GX variations, the starting channel number for a 4x variation must be a multiple of four.
When you generate a custom IP core for variations other than Intel® Arria® 10 and Intel® Cyclone® 10 GX, the < variation name >_constraints.tcl script contains the required assignments. When you run the script, the constraints are applied to your project.
4.2.1.1. Avalon System Clock
4.2.1.2. Reference Clock
The reference clock signal drives the transceiver and the Physical layer. By default, this clock is called clk in the generated IP core. Platform Designer (Standard) allows you to export the clk signal with a name of your choice.
The reference clock, clk, is the incoming reference clock for the transceiver’s PLL. The frequency of the input clock must match the value you specify for the Reference clock frequency parameter. The transceiver PLL converts the reference clock frequency to the internal clock speed that supports the RapidIO IP core baud rate.
The RapidIO parameter editor lets you select one of the supported frequencies. The selection allows you to use an existing clock in your system as the reference clock for the RapidIO IP core.
This source must be within ±100 ppm of its nominal value, to ensure the difference between any two devices in the RapidIO system is within ±200 ppm.
The above figure shows how the transceiver uses the reference clock in variations other than Intel® Arria® 10 and Intel® Cyclone® 10 GX. In Intel® Arria® 10 and Intel® Cyclone® 10 GX variations, clk is the reference clock only for the RX PLL. The reference clock for the TX PLL is an input signal to the TX PLL IP core that you connect to the RapidIO IP core.
The PLL generates the high-speed transmit clock and the input clocks to the receiver high-speed deserializer clock and recovery unit (CRU). The CRU generates the recovered clock (rxclk) that drives the receiver logic.
For more information about the supported frequencies for the reference clock in your RapidIO variation, refer to the relevant device handbook.
4.2.1.3. Other Input Clocks
In variations that target a device for which the transceivers are configured with the ALTGX megafunction, and not with a Transceiver PHY IP core, the transceiver's calibration-block clock is called cal_blk_clk.
In Arria® V, Cyclone® V, and Stratix® V devices, the transceiver has an additional clock, phy_mgmt_clk, which clocks the software interface to the transceiver. In Intel® Arria® 10 and Intel® Cyclone® 10 GX devices, the transceiver has an input clock bus tx_bonding_clocks_ch N. These clocks should be driven by the external TX transceiver PLL. Intel® Arria® 10 and Intel® Cyclone® 10 GX variations also have an option interface, the Intel® Arria® 10 and Intel® Cyclone® 10 GX Native PHY dynamic reconfiguration interface, which includes a clock signal for each transceiver channel.
4.2.1.4. Clock Domains
In systems created with Platform Designer (Standard), the system interconnect manages clock domain crossing if some of the components of the system run on a different clock. For optimal throughput, run all the components in the datapath on the same clock.
4.2.1.5. Baud Rates and Clock Frequencies
Baud Rate (Gbaud) |
rxgxbclk (MHz) | txclk, rxclk (MHz) |
Avalon® system clock (sysclk) | |||
1x | 2x | Minimum (MHz) | Typical (MHz) |
Maximum (MHz) 19 |
||
1.25 | 62.5 | 31.25 | 31.25 | 15.625 | 31.25 | 46.875 |
2.5 | 125 | 62.5 | 62.5 | 31.25 | 62.5 | 93.75 |
3.125 | 156.25 | 78.125 | 78.125 | 39.065 | 78.125 | 117.19 |
5.0 | 25020 | 125 | 125 | 62.50 | 125 | 187.50 |
Baud Rate (Gbaud) |
rxgxbclk (MHz) | Avalon® System Clock (sysclk) | ||
Minimum (MHz) | Typical (MHz) |
Maximum (MHz)19 |
||
1.25 | 62.5 | 31.25 | 62.5 | 93.75 |
2.5 | 125 | 62.5 | 125 | 187.5 |
3.125 | 156.25 | 78.125 | 156.25 | 234.275 |
5.0 | 250 | 125 | 250 | 250 |
The reference clock is called clk.
4.2.2. Reset for RapidIO IP Cores
- reset_n: main active-low reset signal
- phy_mgmt_clk_reset: transceiver software management interface signal to reset the Custom PHY IP core included in the RapidIO Arria® V, Cyclone® V, or Stratix® V variation ( Arria® V, Cyclone® V, and Stratix® V variations only)
- tx_analogreset, rx_analogreset, tx_digitalreset, rx_digitalreset: transceiver reset signals ( Intel® Arria® 10 and Intel® Cyclone® 10 GX variations only)
In addition, if you turn on Enable transceiver dynamic reconfiguration for your RapidIO Intel® Arria® 10 and Intel® Cyclone® 10 GX variations, the IP core includes reconfig_reset_chN input clock to reset the Intel® Arria® 10 or Intel® Cyclone® 10 GX Native PHY dynamic reconfiguration interface for each RapidIO lane N.
4.2.2.1. General RapidIO Reset Signal Requirements
All reset signals can be asserted asynchronously to any clock. However, most reset signals must be deasserted synchronously to a specific clock.
The reset_n input signal can be asserted asynchronously, but must last at least one Avalon® system clock period and be deasserted synchronously to the rising edge of the Avalon® system clock.
In systems generated by Platform Designer (Standard), this circuit is generated automatically. However, if your RapidIO IP core variation is not generated by Platform Designer (Standard), you must implement logic to ensure the minimal hold time and synchronous deassertion of the reset_n input signal to the RapidIO IP core.
4.2.2.2. Reset Controller
All RapidIO IP core variations other than Intel® Arria® 10 and Intel® Cyclone® 10 GX include a dedicated reset control module to handle the specific requirements of the internal transceiver module. Intel® Arria® 10 and Intel® Cyclone® 10 GX RapidIO IP core variations do not include a reset controller.
The reset control module is named riophy_reset. This riophy_reset module is defined in the riophy_reset.v clear-text Verilog HDL source file, and is instantiated inside the top-level module found in the clear text < variation name >_riophy_xcvr.v Verilog HDL source file.
The riophy_reset module controls all of the RapidIO IP core's internal reset signals. In particular, it generates the recommended reset sequence for the transceiver. The reset sequence and requirements vary among device families. For details, refer to the relevant device handbook.
4.2.2.3. Reset Requirements for Arria V, Cyclone V, and Stratix V Variations
- The Custom PHY IP core phy_mgmt_clk_reset signal and the RapidIO IP core reset_n signal must be driven from the same source, with the caveat that the phy_mgmt_clk_reset signal is active high and the reset_n signal is active low. The two reset signals must be asserted synchronously, but deasserted each according to its corresponding clock. The following figure shows a circuit that ensures the requirements for these two reset signals are met.
- You must ensure that the system does not deassert reset_n and phy_mgmt_clk_reset when the Transceiver Reconfiguration Controller reconfig_busy signal is asserted. The RapidIO IP core must remain in reset until the Transceiver Reconfiguration Controller is available.
The assertion of reset_n causes the whole IP core to reset. In Arria V, Cyclone® V, and Stratix® V devices, the requirement that phy_mgmt_clk_reset be asserted with reset_n ensures that the PHY IP core resets with the RapidIO IP core. While the module is held in reset, the Avalon® -MM waitrequest outputs are driven high and all other outputs are driven low. When the module comes out of the reset state, all buffers are empty.
In Arria® V, Cyclone® V, and Stratix® V devices, phy_mgmt_clk_reset must be asserted with reset_n. However, each signal is deasserted synchronously with its corresponding clock.
In systems generated by Platform Designer (Standard), this circuit is generated automatically. However, if your Arria® V, Cyclone® V, or Stratix® V RapidIO IP core variation is not generated by Platform Designer (Standard), you must implement logic to ensure that reset_n and phy_mgmt_clk_reset are driven from the same source, and that each meets the minimal hold time and synchronous deassertion requirements.
4.2.2.4. Reset Requirements for Intel Arria 10 and Intel Cyclone 10 GX Variations
To implement the reset sequence correctly for your RapidIO IP core configured on Intel® Arria® 10 and Intel® Cyclone® 10 GX devices, you must connect the tx_analogreset, tx_digitalreset, rx_analogreset, and rx_digitalreset signals to Transceiver PHY Reset Controller IP core. User logic must drive the following signals from a single reset source:
- RapidIO IP core reset_n (active low) input signal.
- Transceiver PHY Reset Controller reset (active high) input signal.
- TX PLL mcgb_rst (active high) input signal. However, Intel® Arria® 10 and Intel® Cyclone® 10 GX device requirements take precedence. Depending on the TX PLL configuration, your design might need to drive TX PLL mcgb_rst with different constraints.
4.2.2.5. RapidIO IP Core Reset Behavior
Consistent with normal operation, following the IP core reset sequence, the Initialization state machine transitions to the SILENT state.
If two communicating RapidIO IP cores are reset one after the other, one of the IP cores may enter the Input Error Stopped state because the other IP core is in the SILENT state while this one is already initialized. The initialized IP core enters the Input Error Stopped state and subsequently recovers.
4.3. Physical Layer
4.3.1. Features
- Port initialization
- Transmitter and receiver with the following features:
- One, two, or four lane high-speed data serialization and deserialization (up to 5.0 Gbaud for 1x variations with 32-bit Atlantic interface; up to 5.0 Gbaud for 2x and 4x variations with 64-bit Atlantic interface)
- Clock and data recovery (receiver)
- 8B10B encoding and decoding
- Lane synchronization (receiver)
- Packet/control symbol assembly and delineation
- Cyclic redundancy code (CRC) generation and checking on packets
- Control symbol CRC-5 generation and checking
- Error detection
- Pseudo-random idle sequence generation
- Idle sequence removal
- Software interface (status/control registers)
- Flow control (ackID tracking)
- Time-out on acknowledgments
- Order of retransmission maintenance and acknowledgments
- ackID assignment
- ackID synchronization after reset
- Error management
- Clock decoupling
- FIFO buffer with level output port
- Adjustable buffer sizes (4 KBytes to 32 KBytes)
- Four transmission queues and four retransmission queues to handle packet prioritization
- Can be configured to send link-request control symbols with cmd set to reset-device on fatal error
- Attempts link-request link-response control symbol pair a configurable number of times before declaring fatal error, when a link-response is not received
4.3.2. Physical Layer Architecture
4.3.3. Low-level Interface Receiver
- Separates packets and control symbols
- Removes idle sequence characters
- Detects multicast-event and stomp control symbols
- Detects packet-size errors
- Checks the control symbol 5-bit CRC and asserts symbol_error if the CRC is incorrect
4.3.3.1. Receiver Transceiver
- Feeds serial data from differential input pins to the CRU to detect clock and data.
- Deserializes recovered data into 10-bit code groups.
- Sends the code groups to the pattern detector and word-aligner block to detect word boundaries.
- Performs 8B10B decoding on properly aligned 10-bit code groups to convert them to 8-bit characters.
- Converts 8-bit characters to 16-bit or 32-bit data in the 8-to-16 or 8-to-32 demultiplexer.
4.3.3.2. CRC Checking and Removal
- For packets of 80 bytes or fewer—header and payload data included—a single 16-bit CRC is appended to the end of the packet.
- For packets longer than 80 bytes—header and payload data included—two 16-bit CRCs are inserted; one after the 80th transmitted byte and the other at the end of the packet.
Two null padding bytes are appended to the packet if the resulting packet size is not an integer multiple of four bytes.21
In variations of the RapidIO IP core that include the Transport layer, the Transport layer removes the CRC after the 80th byte (if present), but does not remove the final CRC nor the padding bytes. Therefore, a packet sent to the Avalon® -ST pass-through receiver interface by the Transport layer is two or four bytes longer than the equivalent packet received by the Transport layer from the Avalon® -ST pass-through interface. When processing the received packets, the Logical layer modules must ignore the final CRC and padding bytes (if present). In variations of the RapidIO IP core that include only the Physical layer, the 80th byte CRC of a received packet is not removed.
The receiver uses the CCITT polynomial x16 + x12 + x5 + 1 to check the 16-bit CRCs that cover all packet header bits (except the first 6 bits) and all data payload, and flags CRC and packet size errors.
4.3.4. Low-Level Interface Transmitter
- Assembles packets and control symbols into a proper output format
- Generates the 5-bit CRC to cover the 19-bit symbol and appends the CRC at the end of the symbol
- Transmits an idle sequence during port initialization and when no packets or control symbols are available to transmit
- Transmits outgoing multicast-event control symbols in response to user requests
- Transmits status control symbols and the rate compensation sequence periodically as required by the RapidIO specification
The low-level transmitter block creates and transmits outgoing multicast-event control symbols. Each time the multicast_event_tx input signal changes value, this block inserts a multicast-event control symbol in the outgoing bit stream as soon as possible.
In 1.25, 2.5, and 3.125 Gbaud variations, the internal transmitters are not turned off while the initialization state machine is in the SILENT state. Instead, while in SILENT state, the transmitters send a continuous stream of K28.5 characters, all of the same disparity. This behavior causes the receiving end to declare numerous disparity errors and to detect a loss of lane_sync as intended by the specification.
In 5.0 Gbaud variations, the internal transmitters are turned off while the initialization state machine is in the SILENT state. This behavior also causes the link partner to detect the need to reinitialize the RapidIO link.
4.3.4.1. Transmitter Transceiver
The transmitter transceiver is an embedded megafunction in the Arria II GX, Arria II GZ, Cyclone IV GX, or Stratix IV GX device, or an embedded Custom PHY IP core in the Arria® V, Cyclone® V, or Stratix® V device, or an embedded Intel® Arria® 10 or Intel® Cyclone® 10 GX Native PHY IP core in the Intel® Arria® 10 or Intel® Cyclone® 10 GX devices.
- Multiplexes the 16-bit or 32-bit parallel input data to the transmitter to 8-bit data.
- Performs 8B10B encoding on the 8-bit data to convert it to 10-bit code groups.
- Serializes the 10-bit encoded data and sends it to differential output pins.
4.3.5. Protocol and Flow Control Engine
- Monitors incoming and outgoing packet ackIDs to maintain proper flow
- Processes incoming control symbols
- Creates and transmits outgoing control symbols
On the receiver side, this block keeps track of the sequence of ackIDs and determines which packets are acknowledged and which packets to retry or drop. On the transmitter side, it keeps track of the sequence of ackIDs, tells the transmit buffer control block which packet to send, and sets the outgoing packets’ ackID. It also tells the transmit buffer control block when a packet has been acknowledged—and can therefore be discarded from the buffers.
The Physical layer protocol and flow control engine ensures that a maximum of 31 unacknowledged packets are transmitted, and that the ackIDs are used and acknowledged in sequential order.
If the receiver cannot accept a packet due to buffer congestion, a packet-retry control symbol with the packet’s ackID is sent to the transmitter. The sender then sends a restart-from-retry control symbol and retransmits all packets starting from the specified ackID. The RapidIO IP core supports receiver-controlled flow control in both directions.
If the receiver or the protocol and flow control block detects that an incoming packet or control symbol is corrupted or a link protocol violation has occurred, the protocol and flow control block enters an error recovery process. Link protocol violations include acknowledgement time-outs based on the timers the protocol and flow control block sets for every outgoing packet. In the case of a corrupted incoming packet or control symbol, and some link protocol violations, the block instructs the transmitter to send a packet-not-accepted symbol to the sender. A link-request link-response control symbol pair is then exchanged between the link partners and the sender then retransmits all packets starting from the ackID specified in the link-response control symbol. The transmitter attempts the link-request link-response control symbol pair exchange as many times as specified by the value N that you provided for the Link-request attempts parameter in the RapidIO parameter editor. If the protocol and control block times out awaiting the response to the Nth link-request control symbol, it declares a fatal error.
The Physical layer can retransmit any unacknowledged packet because it keeps a copy of each transmitted packet until the packet is acknowledged with a packet-accepted control symbol.
When a time-out occurs for an outgoing packet, the protocol and flow control block treats it as an unexpected acknowledge control symbol, and starts the recovery process. If a packet is retransmitted, the time-out counter is reset.
4.3.6. Physical Layer Receive Buffer
The Physical layer passes data to the Transport layer through a Physical layer receive buffer.. The data passes between the buffer and the Transport layer on a bus that is 32 bits wide in 1x variations and 64 bits wide in 2x and 4x variations.
The Physical layer receiver block accepts packet data from the low-level interface receiver module and stores the data in its receive buffer. The receive buffer provides clock decoupling between the Physical layer rxclk clock domain and the Transport layer sysclk clock domain.
You can specify a value of 4, 8, 16, or 32 KBytes to configure the receive buffer size in devices other than Intel® Arria® 10 and Intel® Cyclone® 10 GX. RapidIO Intel® Arria® 10 and Intel® Cyclone® 10 GX variations have a receive buffer size of 32 KBytes. The receiver buffer is partitioned into 64-byte blocks that are allocated from a free queue and returned to the free queue when no longer needed. The IP core provides the current number of 64-byte blocks in the free queue in the arxwlevel output signal.
As many as five 64-byte blocks may be required to store a packet.
4.3.6.1. Error Conditions that Flush the Receive Buffer
- Receive a port-response control symbol with the port_status set to Error.
- Receive a port-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).
- Transmitter times out while waiting for link-response.
- Receiver times out while waiting for link-request.
- Receive four consecutive link-request control symbols with the cmd set to reset-device.
4.3.6.2. Error Conditions Flagged for the Transport Layer
- CRC error—when a CRC error is detected, the packet_crc_error signal is asserted for one rxclk clock period. If the packet size is at least 64 bytes, the Physical layer flags the error. If the packet size is less than 64 bytes, the Physical layer identifies and drops the errored packet before it begins sending the packet to the Transport layer.
- Stomp—the Physical layer flags an error if it receives a stomp control symbol in the midst of a packet, causing the packet to be prematurely terminated.
- Packet size—if a received packet exceeds the allowable size, the Physical layer cuts it short to the maximum allowable size (276 bytes total), and flags the error.
- Outgoing symbol buffer full—under some congestion conditions, the outgoing symbol buffer has no space available for the packet_accepted control symbol. In this case, the RapidIO IP core cannot acknowledge the packet, and the link partner must retry transmission. The Physical layer flags an error to indicate to the Transport layer that it should ignore the received packet because it will be retried.
- Control symbol error —if an embedded or packet-delimiting control symbol is errored, the Physical layer flags the error. The packet in which the errored control symbol is embedded should be retransmitted by the link partner as part of the error recovery process.
- Character error—if the Physical layer receives an errored character (an invalid 10-bit code, or a character of wrong disparity) or an illegal character (any control character other than the non-delimiting Start of Control (SC) character inside a packet) within a packet. In this case the Physical layer flags the error and drops the rest of the packet.
4.3.6.3. Receive Priority Threshold Values
- Packets of priority 0 (lowest priority) are retried if the number of available free 64-byte blocks is less than the Priority 0 Threshold.
- Packets of priority 1 are retried only if the number of available free 64-byte blocks is less than the Priority 1 Threshold.
- Packets of priority 2 are retried only if the number of available free 64-byte blocks is less than the Priority 2 Threshold.
- Packets of priority 3 (highest priority) are retried only if the receiver buffer is full.
The default threshold values are:
- Priority 2 Threshold = 10
- Priority 1 Threshold = 15
- Priority 0 Threshold = 20
You can specify other threshold values by turning off Auto-configured from receiver buffer size on the Physical Layer page in the RapidIO parameter editor.
The RapidIO parameter editor enforces the following constraints to ensure the threshold values increase monotonically by at least the maximum size of a packet (five buffers), as required by the deadlock prevention rules:
- Priority 2 Threshold > 9
- Priority 1 Threshold > Priority 2 Threshold + 4
- Priority 0 Threshold > Priority 1 Threshold + 4
- Priority 0 Threshold < Number of available buffers
4.3.7. Physical Layer Transmit Buffer
The Physical layer accepts packet data from the Transport layer and stores it in the transmit buffer for the RapidIO link low-level interface transmitter. The data passes from the Transport layer to the Physical layer on a bus that is 32 bits wide in 1x variations and 64 bits wide in 2x and 4x variations.
The transmit buffer implements the following features:
- Provides clock decoupling between the Transport layer sysclk clock domain and the Physical layer txclk clock domain.
- Implements the RapidIO specification requirements for packet priority handling and deadlock avoidance, by configuring individual priority transmit and retransmit queues.
The transmit buffer is the main memory in which the packets are stored before they are transmitted. You can specify a value of 4, 8, 16, or 32 KBytes to configure the total memory space available for the transmit buffer in devices other than Intel® Arria® 10 and Intel® Cyclone® 10 GX. RapidIO Intel® Arria® 10 and Intel® Cyclone® 10 GX devices have a total transmit buffer size of 32 KBytes.
The transmit buffer space is partitioned into 64-byte blocks that are allocated from a free queue and returned to the free queue when no longer needed. The 64-byte blocks are used on a first-come, first-served basis by the individual transmit and retransmit queues.
The IP core provides the current number of 64-byte blocks in the free queue in the atxwlevel output signal. The transmit buffer also has an output signal, atxovf, which indicates a transmit buffer overflow condition.
4.3.7.1. Transmit and Retransmit Queues
To meet the RapidIO specification requirements for packet priority handling and deadlock avoidance, the Physical layer transmit buffer implements four transmit queues and four retransmit queues, one for each priority level.
As the Transport layer writes packets to the Physical layer, the Physical layer adds them to the end of the appropriate priority transmit queue. The transmitter always transmits the packet at the head of the highest priority non-empty queue. After the packet is transmitted, the Physical layer moves the packet from the transmit queue to the corresponding priority retransmit queue.
When a packet-accepted control symbol is received for a non-acknowledged transmitted packet, the transmit buffer block removes the accepted packet from its retransmit queue.
If a packet-retry control symbol is received, all of the packets in the retransmit queues are returned to the head of the corresponding transmit queues. The transmitter sends a restart-from-retry symbol, and the transmission resumes with the highest priority packet available, possibly not the same packet that was originally transmitted and retried. The Transport layer might have written higher priority packets to the Physical layer since the retried packet was originally transmitted. In that case, the higher priority packets are chosen automatically to be transmitted before lower priority packets are retransmitted.
The Physical layer protocol and flow control engine ensures that a maximum of 31 unacknowledged packets are transmitted, and that the ackIDs are used and acknowledged in ascending order.
4.3.7.2. Error Conditions that Flush the Transmit Buffer
- Receive a link-response control symbol with the port_status set to Error.
- Receive 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).
- Transmitter times out while waiting for link-response.
- Receiver times out while waiting for link-request.
- Receive four consecutive link-request control symbols with the cmd set to reset-device.
4.3.7.3. Forced Compensation Sequence Insertion
As packet data is written to the transmit buffer, it is stored in 64-byte blocks. To minimize the latency introduced by the RapidIO IP core, transmission of the packet starts as soon as the first 64-byte block is available (or the end of the packet is reached, for packets shorter than 64 bytes). Should the next 64-byte block not be available by the time the first one has been completely transmitted, status control symbols are inserted in the middle of the packet instead of idles as the true idle sequence can be inserted only between packets and cannot be embedded inside a packet. Embedding these status control symbols along with other symbols, such as packet-accepted symbols, causes the transmission of the packet to be stretched in time.
The RapidIO specification requires that compensation sequences be inserted every 5,000 code groups or columns, and that they be inserted only between packets. The RapidIO IP core checks whether the 5,000 code group quota is approaching before the transmission of every packet and inserts a compensation sequence when the number of code groups or columns remaining before the required compensation sequence insertion falls below a specified threshold.
The threshold is chosen to allow time for the transmission of a packet of maximum legal size—276 bytes—even if it is stretched by the insertion of a significant number of embedded symbols. The threshold assumes a maximum of 37 embedded symbols, or 148 bytes, which is the number of status control symbols that are theoretically embedded if the traffic in the other direction consists of minimum-sized packets.
Despite these precautions, in some cases—for example when using an extremely slow Avalon® system clock—the transmission of a packet can be stretched beyond the point where a RapidIO link protocol compensation sequence must be inserted. In this case, the packet transmission is aborted with a stomp control symbol, the compensation sequence is inserted, and normal transmission resumes.
When the receive side receives a stomp control symbol in the midst of a packet, it provides an error indication to the Transport layer. Because the packet was prematurely terminated at transmission, no traffic is lost and no protocol violation occurs.
4.4. Transport Layer
The Transport layer is a required module of the RapidIO IP core. The Transport layer is intended for use in an endpoint processing element and must be used with at least one Logical layer module or the Avalon® -ST pass-through interface.
You can optionally turn on the following two Transport layer parameters:
- Enable Avalon® -ST pass-through interface—If you turn on this parameter, the Transport layer routes all unrecognized packets to the Avalon® -ST pass-through interface.
-
Disable Destination ID checking by default—If
you turn on this parameter, request packets are considered recognized even if the
destination ID does not match the value programmed in the base device ID CSR-Offset:
0x60. This feature enables the RapidIO IP core to process multi-cast transactions
correctly. This parameter is turned on in RapidIO
Intel®
Arria® 10
and
Intel®
Cyclone® 10 GX
variations.
You can also turn on and turn off destination ID checking in the PROMISCUOUS_MODE field of the Rx Transport Control register at offset 0x10600.
The Transport layer module is divided into receiver and transmitter submodules.
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.
Packets with a destination ID different from the content of the relevant Base Device ID CSR ID field are routed to the Avalon® -ST pass-through interface, unless you disable destination ID checking and the packet is a request packet with a tt field that matches the device ID width setting of the IP core. If you disable destination ID checking, the packet is a request packet with a supported ftype, and the tt field matches the device ID width setting of the current RapidIO IP core, the packet is routed to the appropriate Logical layer.
- Packets with unsupported ftype are routed to the
Avalon®
-ST
pass-through interface. Request packets with a supported ftype and a tt value that matches the RapidIO IP core’s device
ID width, but an unsupported ttype are routed to the Logical layer supporting the ftype. The Logical layer module
then performs the following tasks:
- Sends an ERROR response for request packets that require a response.
- Records an unsupported_transaction error in the Error Management extension registers.
- Packets that would be routed to the Avalon® -ST pass-through interface, in the case that the RapidIO IP core does not implement an Avalon® -ST pass-through interface, are dropped. In this case, the Transport layer module asserts the rx_packet_dropped signal.
- ftype=13 response packets are routed based on the value of their target transaction ID (targetTID) field. Each Logical layer module is assigned a range of transaction IDs. If the transaction ID of a received response packet is not within one of the ranges assigned to one of the enabled Logical layer modules, the packet is routed to the pass-through interface.
Packets marked as errored by the Physical layer (for example, packets with a CRC error or packets that were stomped) are filtered out and dropped from the stream of packets sent to the Logical layer modules or pass-through interface. In these cases, the rx_packet_dropped output signal is not asserted.
4.4.2. Transaction ID Ranges
To limit the required storage, a single pool of transaction IDs is shared between all destination IDs, although the RapidIO specification allows for independent pools for each Source-Destination pair. Further simplifying the routing of incoming ftype=13 response packets to the appropriate Logical layer module, the Input-Output Avalon® -MM slave module and the Doorbell Logical layer module are each assigned an exclusive range of transaction IDs that no other Logical layer module can use for transmitted request packets that expect an ftype=13 response packet.
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. |
Response packets of ftype=13 with transaction IDs outside the 64–143 range are routed to the Avalon® -ST pass-through interface. Transaction IDs in the 0-63 range should not be used if the Maintenance Logical layer Avalon® -MM slave module is instantiated because their use might cause the uniqueness of transaction ID rule to be violated.
If the Input-Output Avalon® -MM slave module or the Doorbell Logical layer module is not instantiated, response packets in the corresponding Transaction IDs ranges for these layers are routed to the Avalon® -ST pass-through interface.
4.4.3. Transmitter
On the transmit side, the Transport layer module uses a round-robin scheduler to select the Logical layer module to transmit packets. The Transport layer polls the various Logical layer modules to determine whether a packet is available. When a packet is available, the Transport layer transmits the whole packet, and then continues polling the next logical modules.
In a variation with a user-defined Logical layer connected to the Avalon® -ST pass-through interface, you can abort the transmission of an errored packet by asserting the Avalon® -ST pass-through interface gen_tx_error signal and gen_tx_endofpacket.
4.5. Logical Layer Modules
- Concentrator module that consolidates register access.
- Maintenance module that initiates and terminates MAINTENANCE transactions.
- I/O slave and master modules that initiate and terminate NREAD, NWRITE, SWRITE, and NWRITE_R transactions.
- Doorbell module that transacts RapidIO DOORBELL messages.Figure 15. RapidIO IP Core Functional Block Diagram
4.5.1. Concentrator Register Module
The Concentrator module provides access to the Avalon® -MM slave interface and the RapidIO IP core register set. The interface supports simple reads and writes with variable latency. Accesses are to 32-bit words addressed by a 17-bit wide byte address. When accessed, the lower 2 bits of the address are ignored and assumed to be 0, which aligns the transactions to 4-byte words. The interface supports an interrupt line, sys_mnt_s_irq. When enabled, the following interrupts assert the sys_mnt_s_irq signal:
- Received port-write
- I/O read out of bounds
- I/O write out of bounds
- Invalid write
- Invalid write burstcount
A local host can access these registers using one of the following methods:
- Platform Designer (Standard) interconnect
- Custom logic
A local host can access the RapidIO registers from a Platform Designer (Standard) system. In this figure, a Nios II processor is part of the Platform Designer (Standard) system and is configured as an Avalon® -MM master that accesses the RapidIO IP core registers through the System Maintenance Avalon® -MM slave. Alternatively, you can implement custom logic to access the RapidIO registers.
A remote host can access the RapidIO registers by sending MAINTENANCE transactions targeted to this local RapidIO IP core. The Maintenance module processes MAINTENANCE transactions. If the transaction is a read or write, the operation is presented on the Maintenance Avalon® -MM master interface. This interface must be routed to the System Maintenance Avalon® -MM slave interface. This routing can be done with a Platform Designer (Standard) system shown by the routing to the Concentrator's system Maintenance Avalon® -MM slave in the previous figure. If you do not use a Platform Designer (Standard) system, you can create custom logic as shown below.
4.5.2. Maintenance Module
- Type 8 – MAINTENANCE reads and writes
- Type 8 – Port-write packets
When you create your custom RapidIO IP core variation in the parameter editor, you have the two or four choices for this module.
Option | Use |
---|---|
Avalon® -MM Master and Slave | Allows your IP core to initiate and terminate MAINTENANCE transactions. |
Avalon® -MM Master | Restricts your IP core to terminating MAINTENANCE transactions. This option is not available for Intel® Arria® 10 and Intel® Cyclone® 10 GX variations. |
Avalon® -MM Slave | Restricts your IP core to initiating MAINTENANCE transactions. This option is not available for Intel® Arria® 10 and Intel® Cyclone® 10 GX variations. |
None | Prevents your IP core from initiating or terminating MAINTENANCE transactions. |
The Maintenance module can be segmented into the following four major submodules:
- Maintenance register
- Maintenance slave processor
- Maintenance master processor
- Port-write processor
The following interfaces are supported:
- Avalon® -MM slave interface—User-exposed interface
- Avalon® -MM master interface—User-exposed interface
- Tx interface—Internal interface used to communicate with the Transport layer
- Rx interface—Internal interface used to communicate with the Transport layer
- Register interface—Internal interface used to communicate with the Concentrator ModuleFigure 19. Maintenance Module Block Diagram
4.5.2.1. Maintenance Register
The Maintenance Register module implements all of the control and status registers required by this module to perform its functions. These registers are accessible through the System Maintenance Avalon® -MM interface.
4.5.2.2. Maintenance Slave Processor
- For an Avalon® read, composes the RapidIO logical header fields of a MAINTENANCE read request packet
- For an Avalon® write, composes the RapidIO logical header fields of a MAINTENANCE write request packet
- Maintains status related to the composed MAINTENANCE packet
- Presents the composed MAINTENANCE packet to the Transport layer for transmission
The Avalon® -MM slave interface allows you to initiate a MAINTENANCE read or write operation. The Avalon® -MM slave interface supports the following Avalon® transfers:
- Single slave write transfer with variable wait-states
- Pipelined read transfers with variable latency
Reads and writes on the Avalon® -MM slave interface are converted to RapidIO maintenance reads and writes. The following fields of a MAINTENANCE type packet are assigned by the Maintenance module:
- prio
- tt
- ftype is assigned a value of 4'b1000
- dest_id
- src_id
- ttype is assigned a value of 4'b0000 for reads and a value of 4'b0001 for writes
- rdsize/wrsize field is fixed at 4'b1000, because only 4-byte reads and writes are supported
- source_tid
- hop_count
- config_offset is generated by using the values programmed in the Tx Maintenance Address Translation Window registers.
- wdptr
Each window is enabled if the window enable (WEN) bit of the Tx Maintenance Window n Mask register is set. Each window is defined by the following registers:
- A base register: Tx Maintenance Mapping Window n Base
- A mask register: Tx Maintenance Mapping Window n Mask
- An offset register: Tx Maintenance Mapping Window n Offset
- A control register: Tx Maintenance Mapping Window n Control
For each defined and enabled window, the Avalon® -MM address's least significant bits are masked out by the window mask and the resulting address is compared to the window base. If the addresses match, config_offset is created based on the following equation:
If (mnt_s_address[23:1] & mask[25:3]) == base[25:3] then config_offset = (offset[23:3] & mask[23:3])| (mnt_s_address[21:1] & ~mask[23:3])
where:
- mnt_s_address[23:0] is the Avalon® -MM slave interface address
- config_offset[20:0] is the outgoing RapidIO register double-word offset
- base[31:0] is the base address register
- mask[31:0] is the mask register
- offset[23:0] is the window offset register
If the address matches multiple windows, the lowest number window register set is used.
The following fields are inserted from the control register of the mapping window that matches.
- prio
- dest_id
- hop_count
The tt value is determined by your selection of device ID width at the time you create this RapidIO IP core variation. The source_tid is generated internally and the wdptr is assigned the negation of mnt_s_address[0].
For a MAINTENANCE Avalon® -MM slave write, the value on the mnt_s_writedata[31:0] bus is inserted in the payload field of the MAINTENANCE write packet.
4.5.2.3. Maintenance Master Processor
- For a MAINTENANCE read, converts the received request packet to an Avalon® read and presents it across the Maintenance Avalon® -MM master interface.
- For a MAINTENANCE write, converts the received request packet to an Avalon® write and presents it across the Maintenance Avalon® -MM master interface.
- Performs accounting related to the received RapidIO MAINTENANCE read or write operation.
- For each MAINTENANCE request packet received from remote endpoints, generates a Type 8 Response packet and presents it to the Transport layer for transmission.
The Avalon® -MM master interface supports the following Avalon® transfers:
- Single master write transfer
- Pipelined master read
transfersFigure 22. Signal Relationships for Four Write Transfers on the Maintenance Avalon® -MM Master InterfaceFigure 23. Timing of a Read Request on the Maintenance Avalon® -MM Master Interface
When a MAINTENANCE packet is received from a remote device, it is first processed by the Physical layer. After the Physical layer processes the packet, it is sent to the Transport layer. The Maintenance module receives the packet on the Rx interface. The Maintenance module extracts the fields of the packet header and uses them to compose the read or write transfer on the Maintenance Avalon® -MM master interface. The following packet header fields are extracted:
- ttype
- rdsize/wrsize
- wdptr
- config_offset
- payload
The Maintenance module only supports single 32-bit word transfers, that is, rdsize and wrsize = 4’b1000; other values cause an error response packet to be sent.
The wdptr and config_offset values are used to generate the Avalon® -MM address. The following expression is used to derive the address:
mnt_m_address = {rx_base, config_offset, wdptr, 2'b00}
where rx_base is the value programmed in the Rx Maintenance Mapping register at location 0x10088.
The payload is presented on the mnt_m_writedata[31:0] bus.
4.5.2.4. Port-Write Processor
- Composes the RapidIO logical header of a MAINTENANCE port-write request packet.
- Presents the port-write request packet to the Transport layer for transmission.
- Processes port-write request packets received from a remote device.
- Alerts the user of a received port-write using the sys_mnt_s_irq signal.
The port-write processor is controlled through the use of the receive and transmit port-write registers.
4.5.2.4.1. Port-Write Transmission
- DESTINATION_ID
- priority
- wrsize
The other fields of the MAINTENANCE port-write packet are assigned as follows. The ftype is assigned a value of 4'b1000 and the ttype field is assigned a value of 4'b0100. The wdptr and wrsize fields of the transmitted packet are calculated from the size of the payload to be sent as defined by the size field of the Tx Port Write Control register. The source_tid and config_offset are reserved and set to zero.
The payload is written to a Tx Port Write Buffer starting at address 0x10210. This buffer can store a maximum of 64 bytes. The port-write processor starts the packet composition and transmission process after the PACKET_READY bit in the Tx Port Write Control register is set. The composed Maintenance port-write packet is sent to the Transport layer for transmission.
4.5.2.4.2. Port-Write Reception
- wrsize
- wdptr
- payload
The wrsize and the wdptr determine the value of the PAYLOAD_SIZE field in the Rx Port Write Status register. The payload is written to the Rx Port Write Buffer starting at address 0x10260. A maximum of 64 bytes can be written. While the payload is written to the buffer, the PORT_WRITE_BUSY bit of the Rx Port Write Status register remains asserted. After the payload is completely written to the buffer, the interrupt signal sys_mnt_s_irq is asserted by the Concentrator on behalf of the Port Write Processor. The interrupt is asserted only if the RX_PACKET_STORED bit of the Maintenance Interrupt Enable register is set.
4.5.2.5. Maintenance Module Error Handling
The Maintenance Interrupt register (at 0x10080) and the Maintenance Interrupt Enable register (at 0x10084), determine the error handling and reporting for MAINTENANCE packets.
The following errors can also occur for MAINTENANCE packets:
- A MAINTENANCE read or MAINTENANCE write request time-out occurs and a PKT_RSP_TIMEOUT interrupt (bit 24 of the Logical/Transport Layer Error Detect CSR) is generated if a response packet is not received within the time specified by the Port Response Time-Out Control register.
- The IO_ERROR_RSP (bit 31 of the Logical/Transport Layer Error Detect CSR) is set when an ERROR response is received for a transmitted MAINTENANCE packet.
4.5.3. Input/Output Logical Layer Modules
This section describes the following Input/Output Logical layer modules:
- Input/Output Avalon® -MM Master Module
- Input/Output Avalon® -MM Slave Module
4.5.3.1. Input/Output Avalon -MM Master Module
To maintain full-duplex bandwidth, two independent Avalon® -MM interfaces are used in the I/O master module—one for read transactions and one for write transactions.
The I/O Avalon® -MM master module can process a mix of as many as seven NREAD or NWRITE_R requests simultaneously. If the Transport layer module receives an NREAD or NWRITE_R request packet while seven requests are already pending in the I/O Avalon® -MM master module, the new packet remains in the Transport layer until one of the pending transactions completes.
4.5.3.1.1. Input/Output Avalon -MM Master Address Mapping Windows
Address mapping or translation windows are used to map windows of 34-bit RapidIO addresses into windows of 32-bit Avalon® -MM addresses.
Registers | Location |
---|---|
Input/Output master base address | 0x10300, 0x10310, 0x10320, 0x10330, 0x10340,0x10350, 0x10360, 0x10370, 0x10380, 0x10390, 0x103A0, 0x103B0, 0x103C0, 0x103D0, 0x103E0, 0x103F0 |
Input/Output master address mask | 0x10304, 0x10314, 0x10324, 0x10334, 0x10344,0x10354, 0x10364, 0x10374, 0x10384, 0x10394, 0x103A4, 0x103B4, 0x103C4, 0x103D4, 0x103E4, 0x103F4 |
Input/Output master address offset | 0x10308, 0x10318, 0x10328, 0x10338, 0x103480x10358, 0x10368, 0x10378, 0x10388, 0x10398, 0x103A8, 0x103B8, 0x103C8, 0x103D8, 0x103E8, 0x103F8 |
Your variation must have at least one translation window. Intel® Arria® 10 and Intel® Cyclone® 10 GX variations have 16 address translation windows. You can change the values of the window defining registers at any time. You should disable a window before changing its window defining registers.
A window is enabled if the window enable (WEN) bit of the I/O Master Mapping Window n Mask register is set.
The number of mapping windows is defined by the Number of receive address translation windows parameter, which supports up to 16 sets of registers. Each set of registers supports one address mapping window.
For each window that is defined and enabled, the least significant bits of the incoming RapidIO address are masked out by the window mask and the resulting address is compared to the window base. If the addresses match, the Avalon® -MM address is made of the least significant bits of the RapidIO address and the window offset using the following equation:
Let rio_addr[33:0] be the 34-bit RapidIO address, and address[31:0] the local Avalon® -MM address.
Let base[31:0], mask[31:0] and offset[31:0] be the three window-defining registers. The least significant three bits of these registers are always 3’b000.
Starting from window 0, for the first window in which ((rio_addr & {xamm, mask}) == ({xamb, base} & {xamm, mask}), where xamm and xamb are the Extended Address MSB fields of the I/O Master Mapping Window n Mask and the I/O Master Mapping Window n Base registers, respectively, let address[31:3] = (offset[31:3] & mask[31:3]) | (rio_addr[31:3] & ~mask[31:3])
The value of address[2] is zero for variations with 64-bit wide datapath Avalon® -MM interfaces.
The value of address[2] is determined by the values of wdptr and rdsize or wrsize for variations with 32-bit wide datapath Avalon® -MM interfaces.
The value of address[1:0] is always zero.
For each received NREAD or NWRITE_R request packet that does not match any enabled window, an ERROR response packet is returned.
RapidIO Packet Data wdptr and Data Size Encoding in Avalon® -MM Transactions
The RapidIO IP core converts RapidIO packets to Avalon® -MM transactions. The RapidIO packets’ read size, write size, and word pointer fields are translated to the Avalon® -MM burst count and byteenable values.
RapidIO Values | Avalon® -MM Burstcount Value | ||
---|---|---|---|
rdsize (4'bxxxx) |
wdptr (1'bx) |
in 32-Bit Datapath | In 64-Bit Datapath |
0000 | 0 | 1 | 1 |
1 | 1 | 1 | |
0001 | 0 | 1 | 1 |
1 | 1 | 1 | |
0010 | 0 | 1 | 1 |
1 | 1 | 1 | |
0011 | 0 | 1 | 1 |
1 | 1 | 1 | |
0100 | 0 | 1 | 1 |
1 | 1 | 1 | |
0101 | 0 | 1 | 1 |
1 | 1 | 1 | |
0110 | 0 | 1 | 1 |
1 | 1 | 1 | |
0111 | 0 | 2 | 1 |
1 | 2 | 1 | |
1000 | 0 | 1 | 1 |
1 | 1 | 1 | |
1001 | 0 | 2 | 1 |
1 | 2 | 1 | |
1010 | 0 | 2 | 1 |
1 | 2 | 1 | |
1011 | 0 | 2 | 1 |
1 | 4 | 2 | |
1100 | 0 | 8 | 4 |
1 | 16 | 8 | |
1101 | 0 | 24 | 12 |
1 | 32 | 16 | |
1110 | 0 | 40 | 20 |
1 | 48 | 24 | |
1111 | 0 | 56 | 28 |
1 | 64 | 32 |
RapidIO Values | Avalon® -MM Values | |||
---|---|---|---|---|
wrsize (4'bxxxx) |
wdptr (1'bx) |
Maximum Burstcount | Byteenable (8’b0000xxxx) | |
First Cycle or All Cycles | Second Cycle (If Different) | |||
0000 | 0 | 1 | 1000 | — |
1 | 1 | 1000 | — | |
0001 | 0 | 1 | 0100 | — |
1 | 1 | 0100 | — | |
0010 | 0 | 1 | 0010 | — |
1 | 1 | 0010 | — | |
0011 | 0 | 1 | 0001 | — |
1 | 1 | 0001 | — | |
0100 | 0 | 1 | 1100 | — |
1 | 1 | 1100 | — | |
0101 | 0 22 | 1 | 1110 | — |
122 | 1 | 0111 | — | |
0110 | 0 | 1 | 0011 | — |
1 | 1 | 0011 | — | |
0111 | 0 | 2 | 1000 | 1111 |
1 | 2 | 1111 | 0001 | |
1000 | 0 | 1 | 1111 | — |
1 | 1 | 1111 | — | |
1001 | 0 | 2 | 1100 | 1111 |
1 | 2 | 1111 | 0011 | |
1010 | 022 | 2 | 1110 | 1111 |
122 | 2 | 1111 | 0111 | |
1011 | 0 | 2 | 1111 | 1111 |
1 | 4 | 1111 | — | |
1100 | 0 | 8 | 1111 | — |
1 | 16 | 1111 | — | |
1101 | 0 23 | — | — | — |
1 | 32 | 1111 | — | |
1110 | 023 | — | — | — |
123 | — | — | — | |
1111 | 023 | — | — | — |
1 | 64 | 1111 | — |
RapidIO Values | Avalon® -MM Values | ||
---|---|---|---|
wrsize (4'bxxxx) |
wdptr (1'bx) |
Maximum Burstcount | Byteenable (8’bxxxxxxxx) |
0000 | 0 | 1 | 1000_0000 |
1 | 1 | 0000_1000 | |
0001 | 0 | 1 | 0100_0000 |
1 | 1 | 0000_0100 | |
0010 | 0 | 1 | 0010_0000 |
1 | 1 | 0000_0010 | |
0011 | 0 | 1 | 0001_0000 |
1 | 1 | 0000_0001 | |
0100 | 0 | 1 | 1100_0000 |
1 | 1 | 0000_1100 | |
0101 | 022 | 1 | 1110_0000 |
122 | 1 | 0000_0111 | |
0110 | 0 | 1 | 0011_0000 |
1 | 1 | 0000_0011 | |
0111 | 022 | 1 | 1111_1000 |
122 | 1 | 0001_1111 | |
1000 | 0 | 1 | 1111_0000 |
1 | 1 | 0000_1111 | |
1001 | 022 | 1 | 1111_1100 |
122 | 1 | 0011_1111 | |
1010 | 022 | 1 | 1111_1110 |
122 | 1 | 0111_1111 | |
1011 | 0 | 1 | 1111_1111 |
1 | 2 | 1111_1111 | |
1100 | 0 | 4 | 1111_1111 |
1 | 8 | 1111_1111 | |
1101 | 023 | — | — |
1 | 16 | 1111_1111 | |
1110 | 023 | — | — |
123 | — | — | |
1111 | 023 | — | — |
1 | 32 | 1111_1111 |
This combination of wdptr and wrsize values should be avoided, because the resulting byteenable value is not allowed by the Avalon® -MM specification.
4.5.3.2. Input/Output Avalon -MM Master Module Timing Diagrams
Below figures shows the timing dependencies. Both transaction requests are received on the RapidIO link and sent on to the Logical layer Avalon® -MM master module. If the RapidIO link partner is also an Intel® RapidIO IP core, the input/output avalon-MMslave module timing diagrams show the same transactions as they originate on the Avalon® -MM interface of the RapidIO link partner’s Input/Output Avalon® -MM slave module.
4.5.3.3. 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) supported is 26 (14 read requests + 12 write requests).
To maintain full-duplex bandwidth, two independent Avalon® -MM interfaces are used in the I/O slave module—one for read transactions and one for write transactions.
When the read Avalon® -MM slave creates a read request packet, the request is sent to both the Pending Reads buffer to wait for the corresponding response packet, and to the read request transmit buffer to be sent to the remote processing element through the Transport layer. When the read response is received, the packet’s payload is used to complete the read transaction on the read Avalon® -MM slave.
For a read operation, one of the following responses occurs:
- The read was successful. After a response packet is received, the read response and data are passed from the Pending Reads buffer back through the read Avalon® -MM slave interface.
- The remote processing element is busy and the request packet is resent.
- An error or time-out occurs, which causes io_s_rd_readerror to be asserted on the read Avalon® -MM slave interface and some information to be captured in the Error Management Extension registers.
How the write request is handled depends on the type of write request sent. For example, unlike a read request, not all write requests send tracking information to the Pending Writes buffer. NWRITE and SWRITE requests do not send write tracking information to the Pending Writes buffer. Only write requests such as NWRITE_R, that require a response, are sent to both the Pending Writes and Transmit buffers. Write requests are sent through the Transport and Physical layers to the remote processing element.
An outbound request that requires a response—an NWRITE_R or an NREAD transaction—is assigned a time-out value that is the sum of the VALUE field of the Port Response Time-Out Control register and the current value of a free-running counter. When the counter reaches the time-out value, if the transaction has not yet received a response, the transaction times out.
If you turn off the I/O read and write order preservation option in the RapidIO parameter editor, if a read and a write request arrive simultaneously or one clock cycle apart on the Avalon® -MM interfaces, the order of transaction completion is undefined. However, if you turn on the I/O read and write order preservation option, the read requests buffer and the write requests buffer shown in the figure are combined, to preserve the relative order of read and write requests that appear on the Avalon® -MM interface. In Intel® Arria® 10 and Intel® Cyclone® 10 GX variations, the read and write request buffers are combined.
4.5.3.3.1. Keeping Track of I/O Write Transactions
- The Input/Output Slave Avalon® -MM Write Transactions register holds a count of the write transactions that have been initiated on the write Avalon® -MM slave interface.
- The Input/Output Slave RapidIO Write Requests register holds a count of the RapidIO write request packets that have been transferred to the Transport layer.
- The Input/Output Slave Pending NWRITE_R Transactions register holds a count of the NWRITE_R requests that have been issued but have not yet completed.
In addition, the NWRITE_RS_COMPLETED bit of the Input/Output Slave Interrupt Enable register controls a maskable interrupt in the Input/Output Slave Interrupt register that can be generated when the final pending NWRITE_R transaction completes.
You can use these registers to determine if a specific I/O write transaction has been issued or if a response has been received for any or all issued NWRITE_R requests.
4.5.3.3.2. Input/Output Avalon -MM Slave Address Mapping Windows
Registers | Location |
---|---|
Input/Output slave base address |
0x10400, 0x10410, 0x10420, 0x10430, 0x10440, 0x10450, 0x10460, 0x10470, 0x10480, 0x10490, 0x104A0, 0x104B0, 0x104C0, 0x104D0, 0x104E0, 0x104F0 |
Input/Output slave address mask |
0x10404, 0x10414, 0x10424, 0x10434, 0x10444, 0x10454, 0x10464, 0x10474, 0x10484, 0x10494, 0x104A4, 0x104B4, 0x104C4, 0x104D4, 0x104E4, 0x104F4 |
Input/Output slave address offset |
0x10408, 0x10418, 0x10428, 0x10438, 0x10448, 0x10458, 0x10468, 0x10478, 0x10488, 0x10498, 0x104A8, 0x104B8, 0x104C8, 0x104D8, 0x104E8, 0x104F8 |
Input/Output slave packet control information (for packet header) |
0x1040C, 0x1041C, 0x1042C, 0x1043C, 0x1044C, 0x1045C, 0x1046C, 0x1047C, 0x1048C, 0x1049C, 0x104AC, 0x104BC, 0x104CC, 0x104DC, 0x104EC, 0x104FC |
A base register, a mask register, and an offset register define a window. The control register stores information used to prepare the packet header on the RapidIO side of the transaction, including the target device’s destination ID, the request packet's priority, and selects between the three available write request packet types: NWRITE, NWRITE_R and SWRITE.
You can change the values of the window-defining registers at any time, even after sending a request packet and before receiving its response packet. However, you should disable a window before changing its window-defining registers. A window is enabled if the window enable (WEN) bit of the Input/Output Slave Mapping Window n Mask register is set, where n is the number of the transmit address translation window.
The number of mapping windows is defined by the parameter Number of transmit address translation windows; up to 16 windows are supported. Each set of registers supports one external host or entity at a time. Your variation must have at least one translation window. Intel® Arria® 10 and Intel® Cyclone® 10 GX variations have 16 transmit address translation windows.
For each window that is enabled, the least significant bits of the Avalon® -MM address are masked out by the window mask and the resulting address is compared to the window base. If the addresses match, the RapidIO address in the outgoing request packet is made of the least significant bits of the Avalon® -MM address and the window offset using the following equation:
Let avalon_address[31:0] be the 32-bit Avalon® -MM address, and rio_addr[33:0] be the RapidIO address, in which rio_addr[33:32] is the 2-bit wide xamsbs field, rio_addr[31:3] is the 29-bit wide address field in the packet, and rio_addr[2:0] is implicitly defined by wdptr and rdsize or wrsize.
Let base[31:0], mask[31:0], and offset[31:0] be the values defined by the three corresponding window-defining registers. The least significant 3 bits of base, mask, and offset are fixed at 3’b000 regardless of the content of the window-defining registers.
Let xamo be the Extended Address MSBits Offset field in the Input/Output Slave Window n Offset register (the two least significant bits of the register).
Starting with window 0, find the first window for which
(({address,Nb’0} & mask) == (base & mask))
where N is 2 in 1x variations and 3 in 2x and 4x variations.
Let rio_addr [33:3] = {xamo, (offset [31:3] & mask [31:3]) | ({avalon_address,Nb’0} [31:3]])}
If the address matches multiple windows, the lowest number window register set is used. The Avalon® -MM slave interface’s burstcount and byteenable signals determine the values of wdptr and rdsize or wrsize.
The priority and DESTINATION_ID fields are inserted from the control register.
If the address does not match any window the following events occur:
- An interrupt bit, either WRITE_OUT_OF_BOUNDS or READ_OUT_OF_BOUNDS in the Input/Output Slave Interrupt register, is set.
- The interrupt signal sys_mnt_s_irq is asserted if enabled by the corresponding bit in the Input/Output Slave Interrupt Enable register.
- The COMPLETED_OR_CANCELLED_WRITES field of the Input/Output Slave RapidIO Write Requests register is incremented if the transaction is a write request.
An interrupt is cleared by writing 1 to the interrupt register’s corresponding bit location.
4.5.3.3.3. Input/Output Slave Translation Window Example
The two most significant bits of the Avalon® -MM address are used to differentiate between the processing endpoints. Figures in the following sections show the address translation implemented for each window. Each figure shows the value for the destination ID of the control register for one window.
4.5.3.3.4. Translation Window 0
4.5.3.3.5. Translation Window 1
4.5.3.3.6. Translation Window 2
4.5.3.4. Avalon -MM Burstcount and Byteenable Encoding in RapidIO Packets
The RapidIO IP core converts Avalon® -MM transactions to RapidIO packets. The Avalon® -MM burst count, byteenable, and, in 32-bit variations, address bit 2 values are translated to the RapidIO packets' read size, write size, and word pointer fields.
Avalon® -MM Values | RapidIO Values | ||
---|---|---|---|
burstcount 24 | address[0] (1'bx) 25 |
wdptr (1'bx) |
rdsize (4'bxxxx)25 |
1 | 1 | 0 | 1000 |
1 | 0 | 1 | 1000 |
2 | 0 | 0 | 1011 |
3–4 | 0 | 1 | 1011 |
5–8 | 0 | 0 | 1100 |
9–16 | 0 | 1 | 1100 |
17–24 | 0 | 0 | 1101 |
25–32 | 0 | 1 | 1101 |
33–40 | 0 | 0 | 1110 |
41–48 | 0 | 1 | 1110 |
49–56 | 0 | 0 | 1111 |
57–64 | 0 | 1 | 1111 |
Avalon® -MM Values | RapidIO Values | |||
---|---|---|---|---|
burstcount26 | byteenable (4'bxxxx) |
address [0] (1'bx)27 |
wdptr (1'bx) |
wrsize (4'bxxxx) |
1 | 1000 | 1 | 0 | 0000 |
1 | 0100 | 1 | 0 | 0001 |
1 | 0010 | 1 | 0 | 0010 |
1 | 0001 | 1 | 0 | 0011 |
1 | 1000 | 0 | 1 | 0000 |
1 | 0100 | 0 | 1 | 0001 |
1 | 0010 | 0 | 1 | 0010 |
1 | 0001 | 0 | 1 | 0011 |
1 | 1100 | 1 | 0 | 0100 |
1 | 1110 28 | 1 | 0 | 0101 |
1 | 0011 | 1 | 0 | 0110 |
1 | 1100 | 0 | 1 | 0100 |
1 | 011128 | 0 | 1 | 0101 |
1 | 0011 | 0 | 1 | 0110 |
1 | 1111 | 1 | 0 | 1000 |
1 | 1111 | 0 | 1 | 1000 |
2 | 111129 | 0 | 0 | 1011 |
4 | 1 | 1011 | ||
6 or 8 | 0 | 1100 | ||
10, 12, 14, 16 | 1 | 1100 | ||
18, 20, 22, 24 | 1 | 1101 | ||
26, 28, 30, 32 | 1 | 1101 | ||
34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64 | 1 | 1111 |
Avalon® -MM Values | RapidIO Values |
|
---|---|---|
burstcount24 | wdptr (1'bx) |
rdsize (4'bxxxx)24 |
1 | 1'b0 | 4'b1011 |
2 | 1'b1 | 4'b1011 |
3–4 | 1'b0 | 4'b1100 |
5–8 | 1'b1 | 4'b1100 |
9–12 | 1'b0 | 4'b1101 |
13–16 | 1'b1 | |
17–20 | 1'b0 | 4'b1110 |
21–24 | 1'b1 | |
25–28 | 1'b0 | 4'b1111 |
29–32 | 1'b1 |
The following table lists the allowed burst count and byteenable combinations for RapidIO IP core variations with a 64-bit Avalon® -MM interface. Avalon® -MM value combinations not listed flag interrupts in the RapidIO IP core.
Avalon® -MM Values | RapidIO Values | ||
---|---|---|---|
burstcount | byteenable (8'bxxxx_xxxx) |
wdptr (1'bx) |
wrsize (4'bx) |
1 | 1000_0000 | 0 | 0000 |
1 | 0100_0000 | 0 | 0001 |
1 | 0010_0000 | 0 | 0010 |
1 | 0001_0000 | 0 | 0011 |
1 | 0000_1000 | 1 | 0000 |
1 | 0000_0100 | 1 | 0001 |
1 | 0000_0010 | 1 | 0010 |
1 | 0000_0001 | 1 | 0011 |
1 | 1100_0000 | 0 | 0101 |
1 | 1110_000028 | 0 | 0110 |
1 | 0011_0000 | 0 | 0111 |
1 | 1111_100028 | 0 | 1000 |
1 | 0000_1100 | 1 | 1000 |
1 | 0000_011128 | 1 | 1001 |
1 | 0000_0011 | 1 | 1001 |
1 | 0001_111128 | 1 | 1010 |
1 | 1111_0000 | 0 | 1000 |
1 | 0000_1111 | 1 | 1000 |
1 | 1111_1100 | 0 | 1001 |
1 | 0011_1111 | 1 | 1001 |
1 | 1111_111028 | 0 | 1010 |
1 | 0111_111128 | 1 | 1010 |
1 | 1111_1111 | 0 | 1011 |
2 | 1111_111130 | 1 | 1011 |
3–4 | 0 | 1100 | |
5–8 | 1 | 1100 | |
9–12 | 1 | 1101 | |
13–16 | |||
17–20 | 1 | 1111 | |
21–24 | |||
25–28 | |||
29–32 |
4.5.3.5. Input/Output Avalon -MM Slave Module Timing Diagrams
The following figures show the timing dependencies on the Avalon® -MM slave interface for an outgoing RapidIO NREAD request and the timing dependencies on the Avalon® -MM slave interface for an outgoing NWRITE transaction, respectively. Both transaction requests originate on the Avalon® -MM interface of the slave module. The timing diagrams in “Input/Output Avalon® -MM Master Module Timing Diagrams” show the same transactions after they are transmitted on the RapidIO link and received by an Intel® RapidIO IP core link partner, when they are sent out as Avalon® -MM requests by an Input/Output Avalon® -MM master module in the partner RapidIO IP core.
4.5.4. Doorbell Module
The Doorbell module provides support for Type 10 packet format (DOORBELL class) transactions, allowing users to send and receive short software-defined messages to and from other processing elements connected to the RapidIO interface.
The RapidIO block diagram shows how the Doorbell module is connected to the Transport layer module. In a typical application the Doorbell module’s Avalon® -MM slave interface is connected to the system interconnect fabric, allowing an Avalon® -MM master to communicate with RapidIO devices by sending and receiving DOORBELL messages.
When you configure the RapidIO IP core, you can enable or disable the DOORBELL operation feature, depending on your application requirements. If you do not need the DOORBELL feature, disabling it reduces device resource usage. If you enable the feature, a 32–bit Avalon® -MM slave port is created that allows the RapidIO IP core to receive, generate, or both receive and generate RapidIO DOORBELL messages.
4.5.4.1. Doorbell Module Block Diagram
The Doorbell module contains the following logic blocks:
- Register and FIFO interface that allows an external Avalon® -MM master to access the Doorbell module’s internal registers and FIFO buffers.
- Tx output FIFO that stores the outbound DOORBELL and response packets waiting for transmission to the Transport layer module.
- Acknowledge RAM that temporarily stores the transmitted DOORBELL packets pending responses to the packets from the target RapidIO device.
- Tx time-out logic that checks the expiration time for each outbound Tx DOORBELL packet that is sent.
- Rx control that processes DOORBELL packets received from the Transport layer module. Received packets include the following packet types:
- Rx DOORBELL request.
- Rx response DONE to a successfully transmitted DOORBELL packet.
- Rx response RETRY to a transmitted DOORBELL message.
- Rx response ERROR to a transmitted DOORBELL message.
- Rx FIFO that stores the received DOORBELL messages until they are read by an external Avalon® -MM master device.
- Tx FIFO that stores DOORBELL messages that are waiting to be transmitted.
- Tx staging FIFO that stores DOORBELL messages until they can be passed to the Tx FIFO. The staging FIFO is present only if you select Prevent doorbell messages from passing write transactions in the RapidIO parameter editor. Intel® Arria® 10 and Intel® Cyclone® 10 GX variations have a staging FIFO and prevent DOORBELL messages from passing write transactions.
- Tx completion FIFO that stores the transmitted DOORBELL messages that have received responses. This FIFO also stores timed out Tx DOORBELL requests.
- Error Management module that reports detected errors, including the following errors:
- Unexpected response (a response packet was received, but its TransactionID does not match any pending request that is waiting for a response).
- Request time-out (an outbound DOORBELL request did not receive a response from the target device).
4.5.4.2. Preserving Transaction Order
- You select Prevent doorbell messages from passing write transactions in the RapidIO parameter editor.
- Your RapidIO IP core targets Intel® Arria® 10 and Intel® Cyclone® 10 GX devices.
If the module has a Tx staging FIFO, each DOORBELL message from the Avalon® -MM interface is kept in the Tx staging FIFO until all I/O write transactions that started on the write Avalon® -MM slave interface before this DOORBELL message arrived on the Doorbell module Avalon® -MM interface have been transmitted to the Transport layer. An I/O write transaction is considered to have started before a DOORBELL transaction if the io_s_wr_write and io_s_wr_chipselect signals are asserted while the io_s_wr_waitrequest signal is not asserted, on a cycle preceding the cycle on which the drbell_s_write and drbell_s_chipselect signals are asserted for writing to the Tx Doorbell register while the drbell_s_waitrequest signal is not asserted.
If you do not select Prevent doorbell messages from passing write transactions in the RapidIO parameter editor, the Doorbell Tx staging FIFO is not configured in the RapidIO IP core.
4.5.4.3. Doorbell Message Generation
- 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.
After a write to the Tx Doorbell register is detected, internal control logic generates and sends a Type 10 packet based on the information in the Tx Doorbell and Tx Doorbell Control registers. A copy of the outbound DOORBELL packet is stored in the Acknowledge RAM.
When the response to an outbound DOORBELL message is received, the corresponding copy of the outbound message is written to the Tx Doorbell Completion FIFO (if enabled), and an interrupt is generated (if enabled) on the Avalon® -MM slave interface by asserting the drbell_s_irq signal of the Doorbell module. The ERROR_CODE field in the Tx Doorbell Completion Status register indicates successful or error completion.
The corresponding interrupt status bit is set each time a valid response packet is received, and resets itself when the Tx Completion FIFO is empty. Software optionally can clear the interrupt status bit by writing a 1 to this specific bit location of the Doorbell Interrupt Status register.
Upon detecting the interrupt, software can fetch the completed message and determine its status by reading the Tx Doorbell Completion register and Tx Doorbell Completion Status register, respectively.
An outbound DOORBELL message is assigned a time-out value based on the VALUE field of the Port Response Time-Out Control register and a free-running counter. When the counter reaches the time-out value, if the DOORBELL transaction has not yet received a response, the transaction times out.
An outbound message that times out before its response is received is treated in the same manner as an outbound message that receives an error response: if enabled, an interrupt is generated by the Error Management module by asserting the sys_mnt_s_irq signal, and the ERROR_CODE field in the Tx Doorbell Completion Status register is set to indicate the error.
If the interrupt is not enabled, the Avalon® -MM master must periodically poll the Tx Doorbell Completion Status register to check for available completed messages before retrieving them from the Tx Completion FIFO.
DOORBELL request packets for which RETRY responses are received are resent by hardware automatically. No retry limit is imposed on outbound DOORBELL messages.
4.5.4.4. Doorbell Message Reception
DOORBELL request packets received from the Transport layer module are stored in an internal buffer, and an interrupt is generated on the DOORBELL Avalon® -MM slave interface, if the interrupt is enabled.
The corresponding interrupt status bit is set every time a DOORBELL request packet is received and resets itself when the Rx FIFO is empty. Software can clear the interrupt status bit by writing a 1 to this specific bit location of the Doorbell Interrupt Status register.
An interrupt is generated when a valid response packet is received and when a request packet is received. Therefore, when the interrupt is generated, you must check the Doorbell Interrupt Status register to determine the type of event that triggered the interrupt.
If the interrupt is not enabled, the external Avalon® -MM master must periodically poll the Rx Doorbell Status register to check the number of available messages before retrieving them from the Rx doorbell buffer.
Appropriate Type 13 response packets are generated internally and sent for all the received DOORBELL messages. A response with DONE status is generated when the received DOORBELL packet can be processed immediately. A response with RETRY status is generated to defer processing the received message when the internal hardware is busy, for example when the Rx doorbell buffer is full.
4.5.5. Avalon -ST Pass-Through Interface
The Avalon® -ST pass-through interface is an optional interface that is generated when you select the Avalon® -ST pass-through interface in the Transport and Maintenance page of the RapidIO parameter editor. If destination ID checking is enabled, all packets received by the Transport layer whose destination ID does not match this RapidIO IP core’s base device ID or whose ftype is not supported by this IP core’s variation are routed to the Rx Avalon® -ST pass-through interface. If you disable destination ID checking, request packets are instead routed to the Rx Avalon® -ST pass-through interface only if they have ftypes that are not supported by this IP core’s variation. After packets are routed to the Rx Avalon® -ST pass-through interface, they can be further examined by a local processor or parsed and processed by a custom user function.
The following applications can use the Avalon® -ST pass-through interface:
- User implementation of a RapidIO function not supported by this IP core (for example, data message passing)
- User implementation of a custom function not specified by the RapidIO protocol, but which may be useful for the system application
4.5.5.1. Pass-Through Interface Examples
This section contains two examples, one receiving and the other transmitting a packet through the Avalon® -ST pass-through interface. The RapidIO IP core variation in the receiving example uses 8-bit device ID, and the variation in the transmitting example uses 16-bit device ID.
Packet Routed Through Rx Port on Avalon® -ST Pass-Through Interface
The following example of a packet routed to the receiver Avalon® -ST pass-through interface is for a variation that only has the Maintenance module and the Avalon® -ST pass-through interface enabled. A packet received on the RapidIO interface with an ftype that does not indicate a MAINTENANCE transaction is routed to the receiver port of the Avalon® -ST pass-through interface.
In cycle 0, the user logic indicates to the RapidIO IP core that it is ready to receive a packet transfer by asserting gen_rx_ready. In cycle 1, the IP core asserts gen_rx_valid and gen_rx_startofpacket. During this cycle, gen_rx_size is valid and indicates that five cycles are required to transfer the packet.
Cycle | Field | gen_rx_data bus | Value | Comment |
---|---|---|---|---|
1 | ackID | [63:59] | 5'h00 | |
rsvd | [58:57] | 2'h0 | ||
CRF | [56] | 1'b0 | ||
prio | [55:54] | 2'h0 | ||
tt | [53:52] | 2'h0 | Indicates 8-bit device IDs. | |
ftype | [51:48] | 4'h5 | A value of 5 indicates a Write Class packet. | |
destinationID | [47:40] | 8'haa | 31 | |
sourceID | [39:32] | 8'hcc | 31 | |
ttype | [31:28] | 4'h4 | The value of 4 indicates a NWRITE transaction. | |
wrsize | [27:24] | 4'hc | The wrsize and wdptr values encode the maximum size of the payload field. In this example, they decode to a value of 32 bytes. For details, refer to Table 4-4 in Part 1: Input/Output Logical Specification of the RapidIO Interconnect Specification, Revision 2.1 | |
srcTID | [23:16] | 8'h00 | ||
address[28:13] | [15:0] | 16'h5a5a | The 29 bit address composed is 29’hb4b5959. This becomes 32'h5a5acac8, the double-word physical address. | |
2 | address[12:0] | [63:51] | 13'h1959 | |
wdptr | [50] | 1'b0 | See description for the size field. | |
xamsbs | [49:48] | 2'h0 | ||
Payload Byte0,1 | [47:32] | 16'h0001 | ||
Payload Byte2,3 | [31:16] | 16'h0203 | ||
Payload Byte4,5 | [15:0] | 16'h0405 | ||
3 | Payload Byte6,7 | [63:48] | 16'h0607 | |
Payload Byte8,9 | [47:32] | 16'h0809 | ||
Payload Byte10,11 | [31:16] | 16'h0a0b | ||
Payload Byte12,13 | [15:0] | 16'h0c0d | ||
4 | Payload Byte14,15 | [63:48] | 16'h0e0f | |
Payload Byte16,17 | [47:32] | 16'h1011 | ||
Payload Byte18,19 | [31:16] | 16'h1213 | ||
Payload Byte20,21 | [15:0] | 16'h1415 | ||
5 | CRC[15:0] | [63:48] | 16'hd37c | For packets with a payload greater than 80 bytes, the first CRC field is removed but the final CRC field is not removed. For packets smaller than 80 bytes, the CRC field is not removed. |
Pad bytes | [47:32] | 16'h0000 | The RapidIO requires that Pad bytes be added for the payload to adhere to 32-bit alignment. | |
Bits [31:0] of the gen_rx_data bus are ignored in cycle 5 as the gen_rx_empty signals indicates that 4 bytes are not used in the end-of-packet word. In the case of a RapidIO IP core variation with 16-bit device ID, the value of gen_rx_empty would be 2, and only bits [15:0] of the gen_rx_data bus would be ignored in cycle 5.
NREAD Example Using Tx Port on Avalon® -ST Pass-Through Interface
The next example shows the response to an NREAD transaction in a RapidIO IP core variation with 16-bit device ID. The response is presented on the Tx port of the Avalon® -ST pass-through interface. The transaction diagram below shows the packet presented on this interface. The values captured on a rising clock edge are those shown in the previous clock cycle, because values change after the rising clock edge.
The figure shows a response to a 32-byte NREAD request in a RapidIO IP core with 16-bit device ID. The following table shows the composition of the fields in the RapidIO packet header and the payload as they correspond to each clock cycle. The gen_tx_empty bits indicate a value of 0, because all bytes of the last word are read.
Cycle | Field | gen_tx_data bus | Value | Comment |
---|---|---|---|---|
1 | ackID | [63:59] | 5'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. |
rsvd | [58:57] | 2'h0 | ||
CRF | [56] | 1'b0 | ||
prio | [55:54] | 2'b10 | Priority of the RESPONSE packet. Value must be incremented from the priority value of the REQUEST packet. For example, prio value 2’b10 indicates that the original request had a priority value of 2’b01. | |
tt | [53:52] | 2'h1 | Indicates 16-bit device IDs. | |
ftype | [51:48] | 4'hd | A value of 4'hd (13 decimal) indicates a Response Class packet. | |
destinationId | [47:32] | 16'hccdc | In the case of a RapidIO IP core variation with a 8-bit device ID width, the destinationID and sourceID fields shrink to a width of 8 bits each, and the fields described in the following table rows shift to the left and to an earlier clock cycle if appropriate. | |
sourceId | [31:16] | 16'haaba | ||
ttype | [15:12] | 4'h8 | A value of 8 indicates a RESPONSE transaction with data payload. | |
status | [11:8] | 4'h0 | A value of 0 indicates DONE. Requested transaction has been successfully completed. | |
targetTID | [7:0] | 8'h00 | Value in the response packet matches the sourceTID of the corresponding request packet. | |
2 | Payload Byte0,1 | [63:48] | 16'h0102 | Payload double word 0 |
Payload Byte2,3 | [47:32] | 16'h0304 | ||
Payload Byte4,5 | [31:16] | 16'h0506 | ||
Payload Byte6,7 | [15:0] | 16'h0708 | ||
3 | Payload Byte8,9 | [63:48] | 16'h090a | Payload double word 1 |
Payload Byte10,11 | [47:32] | 16'h0b0c | ||
Payload Byte12,13 | [31:16] | 16'h0d0e | ||
Payload Byte14,15 | [15:0] | 16'h0f10 | ||
4 | Payload Byte16,17 | [63:48] | 16'h1112 | Payload double word 2 |
Payload Byte18,19 | [47:32] | 16'h1314 | ||
Payload Byte20,21 | [31:16] | 16'h1516 | ||
Payload
Byte22,23 |
[15:0] | 16'h1718 | ||
5 |
Payload
Byte24,25 |
[63:48] | 16'h191a | Payload double word 3 |
Payload
Byte26,27 |
[47:32] | 16'h1b1c | ||
Payload
Byte28,29 |
[31:16] | 16'h1d1e | ||
Payload
Byte30,31 |
[15:0] | 16'h1f20 |
4.6. Error Detection and Management
The error detection and management mechanisms in the RapidIO specification and those built into the RapidIO IP core provide a high degree of reliability. In addition to error detection, management, and recovery features, the RapidIO IP core also provides debugging and diagnostic aids. This section describes the error detection and management features in the RapidIO IP core.
4.6.1. Physical Layer Error Management
- Protocol violations
- Transmission errors
Protocol violations can be caused by a link partner that is not fully compliant to the specification, or can be a side effect of the link partner being reset.
Transmission errors can be caused by noise on the line and consist of one or more bit errors. The following mechanisms exist for checking and detecting errors:
- The receiver checks the validity of the received 8B10B encoded characters, including the running disparity.
- The receiver detects control characters changed into data characters or data characters changed into control characters, based on the context in which the character is received.
- The receiver checks the CRC of the received control symbols and packets.
The RapidIO IP core Physical layer transparently manages these errors for you. The RapidIO specification defines both input and output error detection and recovery state machines that include handshaking protocols in which the receiving end signals that an error is detected by sending a packet-not-accepted control symbol, the transmitter then sends an input-status link-request control symbol to which the receiver responds with a link-response control symbol to indicate which packet requires transmission. The input and output error detection and recovery state machines can be monitored by software that you create to read the status of the Port 0 Error and Status CSR.
In addition to the registers defined by the specification, the RapidIO 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 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
- Receive a link-response control symbol with the port_status set to error.
- Receive a link-response control Symbol with the port_status set to OK but the ackID_status set to an ackID that is not pending.
- Transmitter times out while waiting for link-response control
symbol.Note: An output port enters the Output Error Stop state when it receives a packet-not-accepted control Symbol. To exit from this state, the port issues link-request/input-status (restart-from-error) control symbol. The port waits in the Output Error Stop State for a link-response control symbol.
- Receiver times out while waiting for a
link-request/input-status control
symbolNote:
Upon detection of an error, the input port enters the Input Error Stop state. To recover, the input port performs the following:
- Issues a packet-not-acceptedcontrol symbol
- Waits for link-request/Input-Status control symbol
- Sends link-response control symbol
If Send link-request reset-device on fatal errors is turned on in the RapidIO parameter editor, fatal errors cause the transmitter to send link-request control symbols with cmd set to reset-device to the link partner.
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. Any packet with an error detected in the Physical layer is dropped in the Physical layer or the Transport layer before it reaches the Logical layer modules.
The RapidIO specification defines the following common errors and the protocols for managing them:
- Malformed request or response packets
- Unexpected Transaction ID
- Missing response (time-out)
- Response with ERROR status
The RapidIO IP core implements part of the optional Error Management Extensions as defined in Part 8 of the RapidIO Interconnect Specification Revision 2.1. However, because the registers defined in the Error Management Extension specification are not all implemented in the RapidIO IP core, the error management registers are mapped in the Implementation Defined Space instead of being mapped in the Extended Features Space.
The following Error Management registers are implemented in the RapidIO IP core and provide the most useful information for error management:
- Logical/Transport Layer Error Detect CSR
- Logical/Transport Layer Error Enable CSR
- Logical/Transport Layer Address Capture CSR
- Logical/Transport Layer Device ID Capture CSR
- Logical/Transport Layer Control Capture CSR
When enabled, each error defined in the Error Management Extensions triggers the assertion of an interrupt on the sys_mnt_s_irq output signal of the System Maintenance Avalon® -MM slave interface 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
The following sections describe these channels.
4.6.2.1.1. Standard Error Management Registers
- IO Error Response is declared when a response with ERROR status is received for a pending MAINTENANCE read or write request.
- Unsolicited Response is declared when a response is received that does not correspond to any pending MAINTENANCE read or write request.
- Packet Response Timeout is declared when a response is not received within the time specified by the Port Response Time-Out CSR for a pending MAINTENANCE read or write request.
-
Illegal Transaction
Decode is declared for malformed received response packets occurring
from any of the following events:
- Response packet to pending MAINTENANCE read or write request with status not DONE nor ERROR.
- Response packet with payload with a transaction type different from MAINTENANCE read response.
- Response packet without payload, with a transaction type different from MAINTENANCE write response.
- Response to a pending MAINTENANCE read request with more than 32 bits of payload. (The RapidIO IP core issues only 32-bit read requests.)
4.6.2.1.2. Registers in the Implementation Defined Space
- WRITE_OUT_OF_BOUNDS
- READ_OUT_OF_BOUNDS
These bits are set when the address of a write or read transfer on the Maintenance Avalon® -MM slave interface falls outside of all the enabled address mapping windows. When these bits are set, the system interrupt signal sys_mnt_s_irq is also asserted if the corresponding bit in the Maintenance Interrupt Enable register is set.
4.6.2.1.3. Maintenance Avalon -MM Slave Interface's Error Indication Signal
The mnt_s_readerror output 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, described in 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
4.6.2.5.1. Standard Error Management Registers
- IO Error Response is declared when a response with ERROR status is received for a pending NREAD or NWRITE_R request.
- Unsolicited Response is declared when a response is received that does not correspond to any pending NREAD or NWRITE_R request.
- Packet Response Time-Out is declared when a response is not received within the time specified by the Port Response Time-Out Response CSR for an NREAD or NWRITE_R request.
-
Illegal Transaction
Decode is declared for malformed received response packets occurring
from any of the following events:
- NREAD or NWRITE_R response packet with status not DONE nor ERROR.
- NWRITE_R response packet with payload or with a transaction type indicating the presence of a payload.
- NREAD response packet without payload, with incorrect payload size, or with a transaction type indicating absence of payload.
4.6.2.5.2. Registers in the Implementation Defined Space
The I/O Avalon® -MM slave module defines the Input/Output slave interrupt registers with the following bits. For details on when these bits are set.
- INVALID_WRITE_BYTEENABLE
- INVALID_WRITE_BURSTCOUNT
- WRITE_OUT_OF_BOUNDS
- READ_OUT_OF_BOUNDS
When any of these bits are set, the system interrupt signal sys_mnt_s_irq is also asserted if the corresponding bit in the Input/Output Slave Interrupt Enable register is set.
4.6.2.5.3. The Avalon -MM Slave Interface's Error Indication Signal
The io_s_rd_readerror 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 io_s_rd_readerror 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
4.6.2.6.1. Standard Error Management Registers
- Unsupported Transaction is declared when a request packet carries a transaction type that is not supported in the Destination Operations CAR, whether an ATOMIC transaction type, a reserved transaction type, or an implementation defined transaction type.
-
Illegal Transaction
Decode is declared when a request packet for a supported transaction
is too short or if it contains illegal values in some of its fields such as in these
examples:
- Request packet with priority = 3.
- NWRITE or NWRITE_R 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.
4.6.2.6.2. Response Packets with ERROR Status
An ERROR response packet is sent for NREAD and NWRITE_R and Type 5 ATOMIC request packets that cause an Illegal Transaction Decode error to be declared. An ERROR response packet is also sent for NREAD requests if the io_m_rd_readerror 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 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.
The transmit side of the Avalon® -ST pass-through interface provides the gen_tx_error input signal that behaves essentially the same way as the atxerr input signal.
If Enable Avalon® -ST pass-through interface is enabled and at least one of the Data Messages options Source Operation and Destination Operation is turned on in the RapidIO parameter editor, the message passing error management input ports are added to the IP core to enable integrated error management.
5. Signals
Platform Designer (Standard) allows you to export signals with different names or prefixes. Refer to the Platform Designer (Standard) System Contents tab for the signals that support this capability individually, and to the Platform Designer (Standard) HDL Example tab for the list of signals that are bundled together as exported_connections. The signals bundled in exported_connections all take the prefix you specify in the Platform Designer (Standard) System Contents tab.
A yes entry in the Exported by Platform Designer (Standard) column in the following tables indicates that the signal is included in the exported_connections conduit in Platform Designer (Standard). A no entry indicates that the signal is not included in the exported_connections conduit in Platform Designer (Standard).
5.1. Physical Layer Signals
Below tables lists the pins used by the Physical layer of the RapidIO IP core.
Signal | Direction | Description | Exported by Platform Designer (Standard) |
---|---|---|---|
rd | Input | Receive data—a unidirectional data receiver. It is connected to the td bus of the transmitting device. | yes |
td | Output | Transmit data—a unidirectional data driver. The td bus of one device is connected to the rd bus of the receiving device. | yes |
Signal | Direction | Description |
---|---|---|
sysclk 32 | Input | Avalon® system clock |
clk | Input | Physical layer
reference clock. In Intel® Arria® 10 and Intel® Cyclone® 10 GX variations, 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. |
Signal | Direction | Description |
---|---|---|
reset_n | Input | Active-low system
reset. In variations that implement only the Physical layer, this reset signal
is associated with the reference clock. In variations with a Transport layer
this reset is associated with the
Avalon®
system clock. reset_n can be asserted asynchronously, but must stay asserted at least one clock cycle and must be de-asserted synchronously with the clock with which it is associated. Intel® recommends that you apply an explicit 1 to 0 transition on the reset_n input port in simulation, to ensure that the simulation model is properly reset. In the Platform Designer (Standard) flow, this signal is named clock_reset by default. In Arria® V, Cyclone® V, and Stratix® V devices, the reset_n signal must be asserted synchronously with the embedded PHY IP core phy_mgmt_clk_reset signal. In addition, reset_n should not be deasserted when the Transceiver Reconfiguration Controller reconfig_busy signal is high. |
rxclk | Output | Receive-side recovered clock. This signal is derived from the rxgxbclk clock—a clock driven by the transceiver—by division by 1 or 2, depending on the configuration of the IP core. For the frequency of this clock for each baud rate and mode. |
txclk | Output | The internal clock
of the Physical layer. This signal is derived from the txgxbclk clock—a clock driven by the
transceiver—by division by 1 or 2, depending on the configuration of the IP
core. For the frequency of this clock for each baud rate and mode. This clock runs reliably only after the transceiver transmitter PLL is locked to the reference clock, which you can detect by monitoring the gxbpll_locked signal. If you use this clock to drive the Avalon® system clock, you must ensure you do not deassert reset_n before gxbpll_locked is asserted. |
Output Signal | Clock Domain | Description | Exported by Platform Designer (Standard) |
---|---|---|---|
packet_transmitted | txclk | Pulsed high for one clock cycle when a packet’s transmission completes normally. | yes |
packet_cancelled | txclk | Pulsed high for one clock cycle when a packet’s transmission is canceled by sending a stomp, a restart-from-retry, or a link-request control symbol. | yes |
packet_accepted | rxclk | Pulsed high for one clock cycle when a packet-accepted control symbol is being transmitted. | yes |
packet_retry | rxclk | Pulsed high for one clock cycle when a packet-retry control symbol is being transmitted. | yes |
packet_not_accepted | rxclk | Pulsed high for one clock cycle when a packet-not-accepted control symbol is being transmitted. | yes |
packet_crc_error | rxclk | Pulsed high for one clock cycle when a CRC error is detected in a received packet. | yes |
symbol_error | rxclk | Pulsed high for one clock cycle when a corrupted symbol is received. | yes |
port_initialized | txclk | This signal
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.6 of Part VI of the RapidIO Specification. |
yes |
port_error | txclk | This signal holds the value of the PORT_ERR bit of the Port 0 Error and Status CSR (offset 0x158) described in Table 6–10 on page 6–7. | yes |
char_err | rxclk | Pulsed for one clock cycle when an invalid character or a valid but illegal character is detected. | yes |
5.1.1. Status Packet and Error Monitoring Signals
Output Signal | Clock Domain | Description | Exported by Platform Designer (Standard) |
---|---|---|---|
packet_transmitted | txclk | Pulsed high for one clock cycle when a packet’s transmission completes normally. | yes |
packet_cancelled | txclk | 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. | yes |
packet_accepted | rxclk | Pulsed high for one clock cycle when a packet-accepted control symbol is being transmitted. | yes |
packet_retry | rxclk | Pulsed high for one clock cycle when a packet-retry control symbol is being transmitted. | yes |
packet_not_accepted | rxclk | Pulsed high for one clock cycle when a packet-not-accepted control symbol is being transmitted. | yes |
packet_crc_error | rxclk | Pulsed high for one clock cycle when a CRC error is detected in a received packet. | yes |
symbol_error | rxclk | Pulsed high for one clock cycle when a corrupted symbol is received. | yes |
port_initialized | txclk | This signal 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.6 of Part VI of the RapidIO Specification. |
yes |
port_error | txclk | This signal holds the value of the PORT_ERR bit of the Port 0 Error and Status CSR (offset 0x158) | yes |
char_err | rxclk | Pulsed for one clock cycle when an invalid character or a valid but illegal character is detected. | yes |
no_sync_indicator | rxclk | Deasserted to indicate that at least one lane is not synchronized. | yes |
5.1.2. Multicast Event Signals
Signal | Direction | Clock Domain | Description | Exported by Platform Designer (Standard) |
---|---|---|---|---|
multicast_event_tx | Input | txclk | Change the value of this signal to indicate the RapidIO IP core should transmit a multicast-event control symbol. This signal should remain stable for at least 10 txclk cycles. |
yes |
multicast_event_rx | Output | rxclk | Changes value when a multicast-event control symbol is received. | yes |
5.1.3. Receive Priority Retry Threshold-Related Signals
Signal33 | Direction | Description | Exported by Platform Designer (Standard) |
---|---|---|---|
buf_av0 | Output | Buffers available for priority 0 retry packets. | yes |
buf_av1 | Output | Buffers available for priority 1 retry packets. | yes |
buf_av2 | Output | Buffers available for priority 2 retry packets. | yes |
buf_av3 | Output | Buffers available for priority 3 retry packets. | yes |
5.1.4. Physical Layer Buffer Status Signals
Signal34 | Direction | Description |
---|---|---|
atxwlevel 35 | Output | Transmit buffer write level (number of free 64-byte blocks in the transmit buffer). |
atxovf | Output | Transmit buffer overflow.status. |
arxwlevel 35 | Output | Receive buffer write level (number of free 64-byte blocks in the receive buffer). |
5.1.5. Transceiver Signals
Transceiver signals are connected directly to the transceiver block. In some cases these signals must be shared by multiple transceiver blocks that are implemented in the same device.
Signal | Direction | Description |
---|---|---|
cal_blk_clk 36 | Input | The Arria II GX,
Arria II GZ, Cyclone IV GX, and Stratix IV GX transceiver’s on-chip
termination resistors are calibrated by a single calibration block. This
circuitry requires a calibration clock. The frequency range of the cal_blk_clk is 10–125
MHz. This signal is not present in Arria® V, Intel® Arria® 10, Cyclone® V, Intel® Cyclone® 10 GX, or Stratix® V variations. |
phy_mgmt_clk36 | Input | Clocks the Custom
PHY IP core software interface. The expected maximum frequency of this clock
is 250 MHz. This signal is present only in Arria® V, Cyclone® V, and Stratix® V variations. |
phy_mgmt_clk_reset | Input | Resets the Custom
PHY IP core. This signal is present only in
Arria® V,
Cyclone® V, and Stratix
V variations. phy_mgmt_clk_reset can be asserted asynchronously, but must stay asserted at least one clock cycle and must be de-asserted synchronously with phy_mgmt_clk. In addition, this signal must be driven by the same source as reset_n, to ensure that the two signals are asserted—but not deasserted—together. Fig: Circuit to Also Ensure Synchronous Assertion of phy_mgmt_clk_reset with reset_n shows how to enforce the synchronous assertion with reset_n and the minimal removal time and synchronous deassertion with phy_mgmt_clk. In addition, phy_mgmt_clk_reset should not be deasserted when the Transceiver Reconfiguration Controller reconfig_busy signal is high. |
rxgxbclk | Output | Transceiver receiver clock (recovered clock). |
reconfig_clk | Input | Reference clock
for the dynamic reconfiguration controller. The frequency range for this
clock is 2.5–50 MHz. If you use a dynamic reconfiguration block in your
design to dynamically control the transceiver, then this clock is required
by the dynamic reconfiguration block and the RapidIO IP core. If no external dynamic reconfiguration block is used, this input should be tied low. This signal is not present in Arria® V, Intel® Arria® 10, Cyclone® V, Intel® Cyclone® 10 GX, or Stratix® V variations. |
reconfig_togxb | 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. In Arria® V, Cyclone® V, and Stratix® V devices, 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 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 signal is not present in Intel® Arria® 10 and Intel® Cyclone® 10 GX variations. |
reconfig_fromgxb | 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. However, not using a dynamic
reconfiguration block that enables offset cancellation results in a
non-functional hardware design. In Arria® V, Cyclone® V, and Stratix® V devices, 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 Reconfiguration Controller, one interface dedicated to each channel and an additional interface for the transceiver PLL. This signal is not present in Intel® Arria® 10 and Intel® Cyclone® 10 GX variations. |
gxbpll_locked | Output / Input | Indicates the transceiver transmitter PLL is locked to the reference clock. In Intel® Arria® 10 and Intel® Cyclone® 10 GX variations, this is an input signal to the RapidIO IP core that is intended to be connected to the external PLL; in all other variations, this is an output signal from the transceiver PLL in the RapidIO IP core. |
gxb_powerdown | Input | Transceiver block
reset and power down. This resets and powers down all circuits in the
transceiver block. This signal does not affect the refclk buffers and reference clock
lines. All the gxb_powerdown input signals of IP cores intended to be placed in the same quad should be tied together. The gxb_powerdown should be tied low or should remain asserted for at least 2 ms whenever it is asserted. This signal is not present in Arria® V, Intel® Arria® 10, Cyclone® V, Intel® Cyclone® 10 GX, or Stratix® V variations. |
rx_errdetect | Output | Transceiver 8B10B code group violation signal bus. The signal width depends on the IP core mode. |
tx_bonding_clocks_ch0[5:0] | Input | Transceiver channel TX input clocks for RapidIO lane 0. This signal is available only in Intel® Arria® 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 only in Intel® Arria® 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 only in Intel® Arria® 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 only in Intel® Arria® 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_analogreset [<number of lanes>-1:0] | Input |
You must connect these signals to Transceiver PHY Reset Controller IP core, which implements the appropriate reset sequence for the device. Connect each signal to the corresponding signal in the Transceiver PHY Reset Controller IP core. These signals are available only in Intel® Arria® 10 and Intel® Cyclone® 10 GX IP core variations. |
rx_analogreset [<number of lanes>-1:0] | Input | |
tx_digitalreset [<number of lanes>-1:0] | Input | |
rx_digitalreset [<number of lanes>-1:0] | Input | |
rx_is_lockedtodata [<number of lanes>-1:0] | Output | |
tx_cal_busy [<number of lanes>-1:0] | Output | |
rx_cal_busy [<number of lanes>-1:0] | Output |
Each of these individual interfaces is an Avalon® -MM interface you use to access the hard registers for the corresponding transceiver channel on the Intel® Arria® 10 and Intel® Cyclone® 10 GX devices. These signals are available if you turn on Enable transceiver dynamic reconfiguration in the RapidIO parameter editor.
Signal | Direction | Description |
---|---|---|
reconfig_clk_ch0 | Input | Intel® Arria® 10/ Intel® Cyclone® 10 GX dynamic reconfiguration interface clock for the transceiver channel configured for RapidIO lane 0. |
reconfig_reset_ch0 | Input | Intel® Arria® 10/ Intel® Cyclone® 10 GX dynamic reconfiguration interface reset for the transceiver channel configured for RapidIO lane 0. |
reconfig_waitrequest_ch0 | Output | Intel® Arria® 10/ Intel® Cyclone® 10 GX dynamic reconfiguration slave wait request for the transceiver channel configured for RapidIO lane 0. The RapidIO IP core uses this signal to stall the requestor on the interconnect. |
reconfig_read_ch0 | Input | Intel® Arria® 10/ Intel® Cyclone® 10 GX dynamic reconfiguration slave read request for the transceiver channel configured for RapidIO lane 0. |
reconfig_write_ch0 | Input | Intel® Arria® 10/ Intel® Cyclone® 10 GX dynamic reconfiguration slave write request for the transceiver channel configured for RapidIO lane 0. |
reconfig_address_ch0[9:0] | Input | Intel® Arria® 10/ Intel® Cyclone® 10 GX dynamic reconfiguration slave address bus for the transceiver channel configured for RapidIO lane 0. The address is a word address, not a byte address. |
reconfig_writedata_ch0[31:0] | Input | Intel® Arria® 10/ Intel® Cyclone® 10 GX dynamic reconfiguration slave write data bus for the transceiver channel configured for RapidIO lane 0. |
reconfig_readdata_ch0[31:0] | Output | Intel® Arria® 10/ Intel® Cyclone® 10 GX dynamic reconfiguration slave read data bus for the transceiver channel configured for RapidIO lane 0. |
reconfig_clk_ch1 | Input | Intel® Arria® 10/ Intel® Cyclone® 10 GX dynamic reconfiguration interface clock for the transceiver channel configured for RapidIO lane 1. This signal is available only in 2x and 4x variations. |
reconfig_reset_ch1 | Input | Intel® Arria® 10/ Intel® Cyclone® 10 GX dynamic reconfiguration interface reset for the transceiver channel configured for RapidIO lane 1. This signal is available only in 2x and 4x variations. |
reconfig_waitrequest_ch1 | Output |
Intel®
Arria® 10/
Intel®
Cyclone® 10 GX dynamic reconfiguration slave wait
request for the transceiver channel configured for RapidIO lane 1. The
RapidIO IP core uses this signal to stall the requestor on the
interconnect. This signal is available only in 2x and 4x variations. |
reconfig_read_ch1 | Input | Intel® Arria® 10/ Intel® Cyclone® 10 GX dynamic reconfiguration slave read request for the transceiver channel configured for RapidIO lane 1. This signal is available only in 2x and 4x variations. |
reconfig_write_ch1 | Input | Intel® Arria® 10 dynamic reconfiguration slave write request for the transceiver channel configured for RapidIO lane 1. This signal is available only in 2x and 4x variations. |
reconfig_address_ch1[9:0] | Input |
Intel®
Arria® 10/
Intel®
Cyclone® 10 GX dynamic reconfiguration slave
address bus for the transceiver channel configured for RapidIO lane 1. The
address is a word address, not a byte address. This signal is available only in 2x and 4x variations. |
reconfig_writedata_ch1[31:0] | Input | Intel® Arria® 10/ Intel® Cyclone® 10 GX dynamic reconfiguration slave write data bus for the transceiver channel configured for RapidIO lane 1. This signal is available only in 2x and 4x variations. |
reconfig_readdata_ch1[31:0] | Output | Intel® Arria® 10/ Intel® Cyclone® 10 GX dynamic reconfiguration slave read data bus for the transceiver channel configured for RapidIO lane 1. This signal is available only in 2x and 4x variations. |
reconfig_clk_ch2 | Input | Intel® Arria® 10/ Intel® Cyclone® 10 GX dynamic reconfiguration interface clock for the transceiver channel configured for RapidIO lane 2. This signal is available only in 4x variations. |
reconfig_reset_ch2 | Input | Intel® Arria® 10 dynamic reconfiguration interface reset for the transceiver channel configured for RapidIO lane 2. This signal is available only in 4x variations. |
reconfig_waitrequest_ch2 | Output |
Intel®
Arria® 10/
Intel®
Cyclone® 10 GX dynamic reconfiguration slave wait
request for the transceiver channel configured for RapidIO lane 2. The
RapidIO IP core uses this signal to stall the requestor on the
interconnect. This signal is available only in 4x variations. |
reconfig_read_ch2 | Input | Intel® Arria® 10/ Intel® Cyclone® 10 GX dynamic reconfiguration slave read request for the transceiver channel configured for RapidIO lane 2. This signal is available only in 4x variations. |
reconfig_write_ch2 | Input | Intel® Arria® 10/ Intel® Cyclone® 10 GX dynamic reconfiguration slave write request for the transceiver channel configured for RapidIO lane 2. This signal is available only in 4x variations. |
reconfig_address_ch2[9:0] | Input |
Intel®
Arria® 10/
Intel®
Cyclone® 10 GX dynamic reconfiguration slave
address bus for the transceiver channel configured for RapidIO lane 2. The
address is a word address, not a byte address. This signal is available only in 4x variations. |
reconfig_writedata_ch2[31:0] | Input | Intel® Arria® 10/ Intel® Cyclone® 10 GX dynamic reconfiguration slave write data bus for the transceiver channel configured for RapidIO lane 2. This signal is available only in 4x variations. |
reconfig_readdata_ch2[31:0] | Output | Intel® Arria® 10/ Intel® Cyclone® 10 GX dynamic reconfiguration slave read data bus for the transceiver channel configured for RapidIO lane 2. This signal is available only in 4x variations. |
reconfig_clk_ch3 | Input | Intel® Arria® 10/ Intel® Cyclone® 10 GX dynamic reconfiguration interface clock for the transceiver channel configured for RapidIO lane 3. This signal is available only in 4x variations. |
reconfig_reset_ch3 | Input | Intel® Arria® 10 dynamic reconfiguration interface reset for the transceiver channel configured for RapidIO lane 3. This signal is available only in 4x variations. |
reconfig_waitrequest_ch3 | Output |
Intel®
Arria® 10/
Intel®
Cyclone® 10 GX dynamic reconfiguration slave wait
request for the transceiver channel configured for RapidIO lane 3. The
RapidIO IP core uses this signal to stall the requestor on the
interconnect. This signal is available only in 4x variations. |
reconfig_read_ch3 | Input | Intel® Arria® 10/ Intel® Cyclone® 10 GX dynamic reconfiguration slave read request for the transceiver channel configured for RapidIO lane 3. This signal is available only in 4x variations. |
reconfig_write_ch3 | Input | Intel® Arria® 10/ Intel® Cyclone® 10 GX dynamic reconfiguration slave write request for the transceiver channel configured for RapidIO lane 3. This signal is available only in 4x variations. |
reconfig_address_ch3[9:0] | Input |
Intel®
Arria® 10/
Intel®
Cyclone® 10 GX dynamic reconfiguration slave
address bus for the transceiver channel configured for RapidIO lane 3. The
address is a word address, not a byte address. This signal is available only in 4x variations. |
reconfig_writedata_ch3[31:0] | Input | Intel® Arria® 10/ Intel® Cyclone® 10 GX dynamic reconfiguration slave write data bus for the transceiver channel configured for RapidIO lane 3. This signal is available only in 4x variations. |
reconfig_readdata_ch3[31:0] | Output | Intel® Arria® 10/ Intel® Cyclone® 10 GX dynamic reconfiguration slave read data bus for the transceiver channel configured for RapidIO lane 3. This signal is available only in 4x variations. |
In addition to customization of the transceiver through the parameter editor (in variations that target a device for which the transceivers are configured with the ALTGX megafunction, and not with the Transceiver PHY IP core), you can use the transceiver reconfiguration block to dynamically modify the parameter interface. The dynamic reconfiguration block lets you reconfigure the following PMA settings:
- Pre-emphasis
- Equalization
- Offset cancellation
- VOD on a per channel basis
The dynamic reconfiguration block is required for many device families, including Arria® V, Cyclone® V, and Stratix® V devices. For details, go to the appropriate device handbook. For more information about offset cancellation, refer to the relevant device handbook.
5.1.6. Register-Related Signals
Signal | Direction | Clock Domain | Description |
---|---|---|---|
ef_ptr[15:0] | Input | txclk | Most significant bits [31:16] of the PHEAD0 register. |
master_enable | Output | txclk | This output reflects the value of the Master Enable bit of the Port General Control CSR, which indicates whether this device is allowed to issue request packets. If the Master Enable bit is not set, the device may only respond to requests. User logic connected to the Avalon® -ST pass-through interface should honor this value and not cause the Physical layer to issue request packets when it is not allowed. |
port_response_timeout [23:0] | Output | txclk | Most significant bits [31:8] of PRTCTRL register. User logic connected to the pass-through interface that results in request packets requiring a response can use this value to check for request to response time-out. This signal is present in variations that include the Avalon® -ST pass-through interface. |
input_enable 37 | input | txclk | Enables the port to respond
to any RapidIO packets. There are two ways the user can enable the port:
|
output_enable 37 | input | txclk | Enables the port to issue
RapidIO packets. There are two ways the user can enable the port:
|
5.2. Transport and Logical Layer Signals
5.2.1. Avalon -MM Interface Signals
Signal | Direction | Description |
---|---|---|
sys_mnt_s_clk | Input | This signal is not used, therefore it can be left open. The Avalon® clock is used internally to sample this interface. |
sys_mnt_s_chipselect | Input | System maintenance slave chip select |
sys_mnt_s_waitrequest | Output | System maintenance slave wait request |
sys_mnt_s_read | Input | System maintenance slave read enable |
sys_mnt_s_write | Input | System maintenance slave write enable |
sys_mnt_s_address[16:0] | Input | System maintenance slave address bus. This address is a word address (addresses a 4-byte (32-bit) word), not a byte address. |
sys_mnt_s_writedata[31:0] | Input | System maintenance slave write data bus |
sys_mnt_s_readdata[31:0] | Output | System maintenance slave read data bus |
sys_mnt_s_irq | Output | System maintenance slave interrupt request |
Signal | Direction | Description |
---|---|---|
mnt_m_clk | Input | This signal is not used, therefore it can be left open. The Avalon® clock is used internally to sample this interface. |
mnt_m_waitrequest | Input | Maintenance master wait request |
mnt_m_read | Output | Maintenance master read enable |
mnt_m_write | Output | Maintenance master write enable |
mnt_m_address[31:0] | Output | Maintenance master address bus |
mnt_m_writedata[31:0] | Output | Maintenance master write data bus |
mnt_m_readdata[31:0] | Input | Maintenance master read data bus |
mnt_m_readdatavalid | Input | Maintenance master read data valid |
Signal | Direction | Description |
---|---|---|
mnt_s_clk | Input | This signal is not used, therefore it can be left open. The Avalon® clock is used internally as the clock reference for this interface. |
mnt_s_chipselect | Input | Maintenance slave chip select. |
mnt_s_waitrequest | Output | Maintenance slave wait request. |
mnt_s_read | Input | Maintenance slave read enable. |
mnt_s_write | Input | Maintenance slave write enable. |
mnt_s_address[23:0] | Input | Maintenance slave address bus. This address is a word address (addresses a 4-byte (32-bit) word), not a byte address. |
mnt_s_writedata[31:0] | Input | Maintenance slave write data bus. |
mnt_s_readdata[31:0] | Output | Maintenance slave read data bus. |
mnt_s_readdatavalid | Output | Maintenance slave read data valid. |
mnt_s_readerror | Output | Maintenance slave read error, which indicates that the read transfer did not complete successfully. This signal is valid only when the mnt_s_readdatavalid signal is asserted. |
The following parameters are used in some signal width definitions:
- n = (internal datapath width - 1)
- m = (internal datapath width/8) - 1
- k = 6 for 32-bit internal datapath width, and 5 for 64-bit internal datapath width
- j = ((I/O slave address width minus N) - 1) — the I/O slave address width value is defined in the RapidIO parameter editor. N is 2 for 1x variations and 3 for 2x and 4x variations.
The internal datapath width is 32 bits in RapidIO 1x variations, and 64 bits in RapidIO 2x and 4x variations.
Signal | Direction | Description |
---|---|---|
io_m_wr_clk | Input | This signal is not used, therefore it can be left open. The Avalon® clock is used internally as the clock reference for this interface. |
io_m_wr_waitrequest | Input | Input/Output master wait request. |
io_m_wr_write | Output | Input/Output master write enable. |
io_m_wr_address[31:0] | Output | Input/Output master address bus. |
io_m_wr_writedata[n:0] | Output | Input/Output master write data bus. |
io_m_wr_byteenable[m:0] | Output | Input/Output master byte enable. |
io_m_wr_burstcount[k:0] | Output | Input/Output master burst count. |
Signal | Direction | Description |
---|---|---|
io_m_rd_clk | Input | This signal is not used, therefore it can be left open. The Avalon® clock is used internally as the clock reference for this interface. |
io_m_rd_waitrequest | Input | Input/Output master wait request. |
io_m_rd_read | Output | Input/Output master read enable. |
io_m_rd_address[31:0] | Output | Input/Output master address bus. |
io_m_rd_readdata[n:0] | Input | Input/Output master read data bus. |
io_m_rd_readdatavalid | Input | Input/Output master read data valid. |
io_m_rd_burstcount[k:0] | Output | Input/Output master burst count. |
io_m_rd_readerror | Input | Input/Output master indicates that the burst read transfer did not complete successfully. This signal should be asserted through the final cycle of the read transfer. |
Signal | Direction | Description |
---|---|---|
io_s_wr_clk | Input | This signal is not used, therefore it can be left open. The Avalon® clock is used internally as the clock reference for this interface. |
io_s_wr_chipselect | Input | Input/Output slave chip select. |
io_s_wr_waitrequest | Output | Input/Output slave wait request. |
io_s_wr_write | Input | Input/Output slave write enable. |
io_s_wr_address[j:0] | Input | Input/Output slave address bus. In 1x variations, this address is a word address (addresses a 4-byte (32-bit) word), not a byte address. In 2x and 4x variations, this address is a double-word address (addresses an 8-byte (64-bit) word). |
io_s_wr_writedata[n:0] | Input | Input/Output slave write data bus. |
io_s_wr_byteenable[m:0] | Input | Input/Output slave byte enable. |
io_s_wr_burstcount[k:0] | Input | Input/Output slave burst count. |
Signal | Direction | Description |
---|---|---|
io_s_rd_clk | Input | This signal is not used, therefore it can be left open. The Avalon® clock is used internally as the clock reference for this interface. |
io_s_rd_chipselect | Input | Input/Output slave chip select. |
io_s_rd_waitrequest | Output | Input/Output slave wait request. |
io_s_rd_read | Input | Input/Output slave read enable. |
io_s_rd_address[j:0] | Input | Input/Output slave address bus. In 1x variations, this address is a word address (addresses a 4-byte (32-bit) word), not a byte address. In 2x and 4x variations, this address is a double-word address (addresses an 8-byte (64-bit) word). |
io_s_rd_readdata[n:0] | Output | Input/Output slave read data bus. |
io_s_rd_readdatavalid | Output | Input/Output slave read data valid. |
io_s_rd_burstcount[k:0] | Input | Input/Output slave burst count. |
io_s_rd_readerror | Output | Input/Output slave read error indicates that the burst read transfer did not complete successfully. This signal is valid only when the io_s_rd_readdatavalid signal is asserted. |
Signal | Direction | Description |
---|---|---|
drbell_s_clk | Input | This signal is not used, therefore it can be left open. The Avalon® clock is used internally as the clock reference for this interface. |
drbell_s_chipselect | Input | Doorbell chip select |
drbell_s_write | Input | Doorbell write enable |
drbell_s_read | Input | Doorbell read enable |
drbell_s_address[3:0] | Input | Doorbell address bus. This address is a word address (addresses a 4-byte (32-bit) word), not a byte address. |
drbell_s_writedata[31:0] | Input | Doorbell write data bus |
drbell_s_readdata[31:0] | Output | Doorbell read data bus |
drbell_s_waitrequest | Output | Doorbell wait request |
drbell_s_irq | Output | Doorbell interrupt |
5.2.2. Avalon -ST Pass-Through Interface Signals
Signal | Type | Function | |
---|---|---|---|
gen_tx_ready | Output | Indicates that the IP core is ready to receive data on the next 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 IP core, READY_LATENCY is equal to 1, so the cycle immediately following the rising clock edge on which gen_tx_ready is detected as asserted is the ready cycle. This signal may alternate between 0 and 1 when the Avalon® -ST pass-through transmitter interface is idle. After gen_tx_valid is asserted, gen_tx_ready remains asserted for the duration of the packet transmission, unless the Physical layer transmit buffer fills. |
|
gen_tx_valid 40 | Input | Used to qualify all the other transmit side of the Avalon® -ST pass-through interface input signals. On every ready cycle in which gen_tx_valid is high, data is sampled by the IP core. | |
gen_tx_startofpacket | Input | Marks the active cycle containing the start of the packet40 | |
gen_tx_endofpacket | Input | Marks the active cycle containing the end of the packet.40 | |
gen_tx_data | Input | A 32-bit wide data bus for 1x variations, or a 64-bit wide data bus for 2x or 4x variations. Carries the bulk of the information transferred from the source to the sink.40 | |
gen_tx_empty | Input | This bus identifies the number of empty bytes on the last data transfer of the gen_tx_endofpacket. For a 32-bit wide data bus, this bus is 2 bits wide. For a 64-bit wide data bus, this bus is 3 bits wide. The least significant bit is ignored and assumed to be 0. The following values are supported: | |
32-bit bus: 2'b0X none 2'b1X [15:0] |
64-bit bus: 3'b00X none 3'b01X [15:0] 3'b10X [31:0] 3'b11X [47:0] |
||
gen_tx_error | Input | If asserted any time during the packet transfer, this signal indicates the corresponding data has an error and causes the packet to be dropped by the IP core. A value of zero on any beat indicates the data on that beat is error-free.40 |
Signal | Type | Function | |
---|---|---|---|
gen_rx_ready | Input | Indicates to the IP core that the user’s custom logic is ready to receive data on the next 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 IP core is designed for READY_LATENCY equal to1. | |
gen_rx_valid 41 | Output | Used to qualify all the other output signals of the receive side pass-through interface. On every rising edge of the clock where gen_rx_valid is high, gen_rx_data can be sampled. | |
gen_rx_startofpacket | Output | Marks the active cycle containing the start of the packet.41 | |
gen_rx_endofpacket | Output | Marks the active cycle containing the end of the packet.41 | |
gen_rx_data | Output | A 32-bit wide data bus for 1x mode, or a 64-bit wide data bus for 2x or 4x mode.41 | |
gen_rx_empty | Output | This bus identifies the number of empty bytes on the last data transfer of the gen_rx_endofpacket. For a 32-bit wide data bus, this bus is 2 bits wide. For a 64-bit wide data bus, this bus is 3 bits wide. The least significant bit is ignored and assumed to be 0. The following values are supported: | |
32-bit bus: 2'b0X none 2'b1X [15:0] |
64-bit bus: 3'b00X none 3'b01X [15:0] 3'b10X [31:0] 3'b11X [47:0] |
||
If the received number of bytes, including padding and CRC, is a
multiple of four (for a 32-bit wide data bus) or a multiple of eight (for
a 64-bit wide data bus), the value of gen_rx_empty is zero. The value of gen_rx_empty does not tell you whether the final 16 bits of the data transfer are padding or CRC bits; your custom logical layer application must decode the header fields to determine how to interpret the received bits. |
|||
gen_rx_size 42 | Output | Identifies the number of cycles the current packet transfer requires. This signal is only valid on the start of packet cycle when gen_rx_startofpacket is asserted.41 | |
gen_rx_error | Output | Indicates that the corresponding data has an error. This signal is never asserted by the RapidIO IP core.41 |
5.2.3. Error Management Extension Signals
Signal43, 44 | Description |
---|---|
Message Passing Error Management Inputs | |
error_detect_message_error_response | Sets the MESSAGE ERROR RESPONSE bit in the Logical/Transport Layer Error Detect CSR and triggers capture into the Error Management registers of the captured fields below. |
error_detect_message_format_error | Sets the MESSAGE ERROR RESPONSE bit in the Logical/Transport Layer Error Detect CSR and triggers capture into the Error Management registers of the captured fields below. |
error_detect_message_request_timeout | Sets the MESSAGE REQUEST TIME-OUT bit in the Logical/Transport Layer Error Detect CSR and triggers capture into the Error Management registers of the captured fields below. |
error_capture_letter [1:0] | Field captured into the Logical/Transport Layer Control Capture CSR. |
error_capture_mbox [1:0] | Field captured into the Logical/Transport Layer Control Capture CSR. |
error_capture_msgseg_or_xmbox [3:0] | Field captured into the Logical/Transport Layer Control Capture CSR. |
Common Error Management Inputs | |
error_detect_illegal_transaction_decode | Sets the ILLEGAL TRANSACTION DECODE bit in the Logical/Transport Layer Error Detect CSR and triggers capture into the Error Management registers of the captured fields below. |
error_detect_illegal_transaction_target | Sets the ILLEGAL TRANSACTION TARGET ERROR bit in the Logical/Transport Layer Error Detect CSR and triggers capture into the Error Management registers of the captured fields below. |
error_detect_packet_response_timeout | Sets the PACKET RESPONSE TIME-OUT bit in the Logical/Transport Layer Error Detect CSR and triggers capture into the Error Management registers of the captured fields below. |
error_detect_unsolicited_response | Sets the UNSOLICITED RESPONSE bit in the Logical/Transport Layer Error Detect CSR and triggers capture into the Error Management registers of the captured fields below. |
error_detect_unsupported_transaction | Sets the UNSUPPORTED TRANSACTION bit in the Logical/Transport Layer Error Detect CSR and triggers capture into the Error Management registers of the captured fields below. |