Showing results for 
Search instead for 
Did you mean: 
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.

SRIO gen1 1X 3.125 reference design

SRIO gen1 1X 3.125 reference design

Last Update

January 21, 2014

Downloadable Reference Design File

Reference Documents

RapidIO MegaCore Function User Guide (PDF)


This reference design demonstrates the functionality and operation of the Altera® Serial RapidIO (sRIO) 1.2 MegaCore v13.0sp1. The sRIO IP core is configured for a gen1, 3.125-Gbps, 1X solution. The design targets the Stratix V GT Signal Integrity Evaluation Board (Stratix V GT device 5SGTMC7K2F40C2ES) and is developed with the Altera Quartus II release 13.0sp1 development tool. 

This reference design includes the following RapidIO transaction types: 

1) NWRITEs (non-shareable memory write operations) 

2) NWRITE_Rs (write with response) 

3) SWRITEs (streaming write, double-word only version of NWRITE with less header overhead) 

4) NREADs 

5) Maintenance Writes (write data to SRIO registers) 

6) Maintenance Reads 

7) Doorbell Messages 

Note: The reference design is provided as is and is not supported by Altera. 

High Level Architecture

Figure 2-1 shows a top-level block diagram of the RapidIO reference design implemented on the Altera FPGAs. RapidIO reference design.png


The Control Unit is designed using QSYS Builder. The Control Unit runs at a lower frequency than the rest of the design. For the 3.125 Gbaud x1 solution, the RapidIO core runs at 156.25 MHz. The Control Unit had difficulty using this clock speed and this is the reason it was designed as a separate block. In this design the Control Unit is running at 50MHz. 

The adapters shown in the diagram are used to cross the two different clocks; 50 MHz Control Unit clock and the 156.25 MHz RapidIO Core System clock. The other blocks pkt_source, pkt_checker, srio_stats, each have their own control ports that are Avalon-MM Slaves. These ports run at the 50MHz clock. In addition, the blocks connect to the RapidIO core via the main datapath. This main datapath runs at 156.25 MHz. vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv

Control Unit

The following are components used in the Control Unit and a description of their function. 


This is an embedded processor core that can be synthesized on the FPGA. It is used to execute the RapidIO test application software included in this reference design. Using this test application, the user is able to program the RapidIO core and execute transactions to the local RapidIO core or to a remote link partner. 


This component provides the mechanism for communicating to the NIOS2-TERMINAL. The NIOS2-TERMINAL is the user interface to the RapidIO test application. 


This memory space is used to store program code. In this case the program code is the RapidIO test application. Once compiled, the program is stored in this memory where it is executed by the Nios II embedded processor. 


This is a custom SOPC Builder component. It allows the user to execute a “soft_reset” to the RapidIO core. 

AVALON-MM Master and Slave Bridges

Various bridges that allow communication of the single master port of NIOS processor with multiple components with like adapters, packet source etc, by the using of Address Mapping. These are described in more detail in the section, “Testing the Reference Design”. 


This module terminates write bursts and services read bursts which are a result of NWRITEs or NREADs being received by the RapidIO core. The module has a local 32x4Kbyte memory. 


Used to support RapidIO performance testing. Software is unable to generate packets at the required rates, so this is done by this hardware module instead. It generates writes bursts based on Avalon-MM Interface protocol. Each burst gets translated into a RapidIO write transaction. For more information please refer SRIO_FPGA_Functional_Document.doc 


Similar to to the PKT_SOURCE module, this module is to support performance testing. It generates read bursts based on Avalon-MM Interface protocol. Each burst gets translated into a RapidIO NREAD transaction. This module works together with the PKT_SOURCE. The PKT_SOURCE pushes packet descriptors into the PKT_CHECKER. The PKT_CHECKER, based on the packet descriptors, will generate read bursts to check that the write burst executed by the PKT_CHECKER was terminated correctly. 

For more information please refer SRIO_FPGA_Functional_Document.doc 

RapidIO MegaCore

The RapidIO MegaCore is the main component in this reference design. It is responsible for establishing a RapidIO link with the link partner. It will also convert the transactions presented to it on the Avalon-MM interfaces into the corresponding RapidIO transactions and transmit them on the RapidIO serial link. On reception, it will convert the RapidIO transactions into Avalon-MM bursts and present these bursts to the corresponding Avalon-MM Slave or Master interfaces. 

IO Slave Adaptor

Rapid IO 1.2 core’s IO Slave component is interfaced with the packet source and packet checker using a component called IO Slave Adaptor. The IO Slave Adaptor in turn uses either a single Avalon MM Interface for Read as well as Write, or a separate interface for Read and separate interface for Write, based on a hardware design-time parameter value 

IO Master Adaptor

Rapid IO 1.2 core’s IO Master component is interfaced with the RX_BUFFER using a component called IO Master Adaptor. Based on a hardware design-time parameter value, this IO Master Adaptor component in turn has either a single Read/Write Avalon MM Interface, or separate interfaces for Read and Write. The IO Master always supports both types of ports. Based on the provided parameter value, IO Master Adaptor will ensure to connect the proper type of IO Master port to the RX_BUFFER and provide the necessary arbitration in case of common read/write IO Master interface. 

Pass-through test Logic

Pass-thru port is a custom interface provided by SRIO core to handle packet types/transaction types other than those that it supports. If the SRIO core does not support the type of the packet that it has been asked to receive, then that packet is routed to the Pass-through port rather than the IO Master port. For transmit, the Custom Logical layer is directly connected (rather than routed) to the Pass-through port. The Pass-through test logic is used to test the performance on Pass-through port of RapidIO core. The main components of pass-through test logic are Custom Logical layer (created using the IO Master verilog files) and Pass-through RX_BUFFER. Custom logical layer will directly connect to the Transport layer of RapidIO core through Pass-through port. For more information, please refer SRIO_FPGA_Functional_Document.doc. 

Testing the Reference Design

All of the files, necessary for testing this reference design are included in the zip file “”. 

Extracting Package Files

Unzip the “” file. After unzipping, you will have the following folder structure. Please refer Figure 3-1 : Extracted Packet File image. 


Software Application

This section will describe the code flow of software for the version 1.2 

Code Flow

1) Through the “Nios II Command Shell” user can give input command from command line for the desired operations. 

2) User can get the command list by typing “h” on command line. This will display list of commands available for the operations. Table 4.1 list downs the available commands for the operation. 

3) The input command given on command line is saved in buffer and is compared as string with list of available commands. If it matches, then the program executes the respective functionality associated for the command. 

4) The functionalities may be grouped as high-level or low-level, and can also be grouped into operations, tests and configuration commands. The user is expected to use only the high-level tests and operations. All other commands are provided for the purpose of troubleshooting and backward compatibility. 

The SRIO megacore registers will be read and write depending upon the command. Table 4.1 shows commands which can be given as input through command line. The commands are case-insensitive. 



Register Used in Software

Table below shows the registers used for version 1.2. They are separated as per layer. 



Stratix V SI Board Setting

Clock Setting

The reference design is using 156.25MHz for PHY and core logic, 50MHz for system. The reconfigure control close is 125MHz and it is from 50MHz to 125MHz PLL. 


1. Set SW6 to OSC and use on board clock. 

2. Install Transceiver Signal Integrity Development kit rev11.1.2. See link below. 

Transceiver Signal Integrity Development kit 

Note: rev 12.0 would not work. 

3. Open the clock control program and program the Y3 clock to 156.23MHz. See example of clock program below. 



Installing the Software

Please install the following software: 

• Quartus II 13.0sp1 or higher software 

• Nios II software 

• Altera IP 

• USB Byte Blaster driver 

Programming the Altera FPGA

Invoke a “Nios II Command Shell”. Go to the folder where you unzipped the Altera Reference Design Package. 

1. Change your directory to “ rio1_1x_3125_reference_design/qsys_design/”. 

2. Go to the sub directory, “software_bsp”. To build all of the necessary HAL drivers required by this reference design. 

3. execute the file, “create-this-bsp” in the Nios II Command Shell. 


4. Go up one directory and down into the directory “software_app”. 

5. Run “create-this-app” in the Nios II Command Shell. 


This will create a new makefile for the .c and .h files and compile them using this makefile. The srio_regs.h file contains mnemonics for the SRIO registers in the Altera RapidIO core. Verify that there are no compilation errors. You should now see the following additional contents in that directory: 

obj (folder) 




You are now ready to program the FPGA and to run the RapidIO test application. 

6. To program the FPGA, execute the following command at the Nios II Command Shell. 

nios2-configure-sof –d 1 ../../output_file/rio_hw.sof

7. To download the software image i.e. the .elf file, execute the following at the command shell. 

nios2-download –g srio_test.elf 

8. To invoke a nios2-terminal, execute the following at the command shell. 

nios2-terminal device=1

9. Type “init” before generate traffic. 

The Altera RapidIO core is now at your command. Before executing any of the tests, you must power on the link partner. 

Go ahead and type “H” at the prompt. This will display the available commands supported by the test application as well as a short description. 

The above steps described the method for preparing the FPGA on the Altera Stratix V GX Development Board. Once you have done this, you have programmed the FPGA and there should be a live RapidIO link. 

High-Level System Configuration

Configuring the Test Parameters

This is done by the following command: 

Param_Info – programs the test parameters of the Rapid IO core

Similar to the Config_Switch command, the above command is common across all per-transaction-type tests and will be programmatically called at the start of each test (except if the test is being run as a sub-test). 

This command will internally call the following commands which will take the information from user through interactive command line or in some cases, take values from the hardware. For parameters to be input by the user, the last given value/default value of the parameter will also be displayed. If the user presses enter then that value will be used unchanged. 

rate (the per-lane megabaud rate used will be read from hardware) 

mode (the mode at start of test will be read from hardware) 

gap (the gap in clock cycles, between two consecutive burst cycles from packet generator into IO slave, - this will be a hardcoded value in the test application. Minimum value is 1.) 

clk (SRIO core’s clock frequency– will be hardcoded in the test application) 

pload (What should be the payload size, taken from user) – this will be NA if this Param_Info command is being directly invoked by the user, or for the outermost Test_All test. The payload size will neither by displayed or be editable by the user. 

The following values are expected to be provided for test configuration and will also be the default values wherever applicable: 

rate 3125 

mode 1

gap 3

pload 256 (Max size of payload) 

clk 156.25

Per_trans_test_time – 30 seconds

Nread_num_pkts - 1000000

Initialization of the Rapid IO core

The following command is programmatically invoked for any test, if it has never been invoked any time after ELF loading/last invocation of ’r’ command: 

init – initializes a subset of the Altera FPGA Rapidio CARs and CSRs. Please look at the file “srio_main_full.c” for the specific configuration registers. 

The default “init” setting generates NWRITEs. 

Test Steps

The test steps for test_all… type of tests are evident from this section. Apart from the sub tests the test_all_... tests also need to call the following commands before running any of the subtests: 

Init (if never called before or never called after ‘reset’ command) 

Link (if this test case is called from command line) 

Param_Info (if this test case is called from command line) 

This section deals with the test steps for the per-transaction-type tests. 


Following command will start the NWRITE transaction test


load 0x1040c 0x0008ff00

start (start generate traffic) 

stats (which runs till user presses ‘z’ key) 

stop (stop generate traffic) 


Following command will start the SWRITE transaction test


load 0x1040c 0x0008ff02

start (start generate traffic) 

stats (which runs till user presses ‘z’ key) 

stop (stop generate traffic) 


Following command will start the SWRITE transaction test


load 0x1040c 0x0008ff01


stats (which waits for user to press ‘z’ key) 


Please consult the RapidIO 11.1 User Guide for detailed information on the contents of register 0x1040c. 


The RapidIO test application supports a data integrity test. This test will generate NWRITEs. The payload of the NWRITEs is an incrementing pattern with the first word of payload being a packet identifier. The pkt_source is responsible for generating the write bursts which are converted to NWRITEs by the RapidIO core. For each write burst, the pkt_source will push a packet descriptor into a local buffer in the pkt_checker. The pkt_checker upon detecting a non-empty buffer will fetch a packet descriptor, and based on the content of the packet descriptor, it will generate a read request. This read request will get converted to an NREAD transaction by the RapidIO core. When the read data is returned to the pkt_checker, it confirms the data integrity. This is how NREAD transactions are tested. 

At the RapidIO test application prompt, type the following command. 

NREAD <num_pkts>

This command will internally call the below mentioned commands. 

dit (value got via Nread_num_pkts in case this NREAD test is called from Test_All_Trans, otherwise the given at the command prompt) 


The first command dit is used to send 1,000,000 packets through. The second command will gather stats and report good and bad packets transmitted. Of course the good packet count should be 1,000,000 and the bad packet count should be zero. If not, there is a problem and it should be debugged. 

Doorbell Test

This test is for transmission of doorbell messages and total number of doorbell message received. Since the setup used is loopback, all the doorbell messages will be received by the same endpoint. For a doorbell test, below mentioned commands needs to be executed. 

At the RapidIO test application prompt, type the following command. 


If error bit is set, the response for outbound doorbell message with error or being timeout will be stored in FIFO. This command initiates transmission of a set of 16 doorbell messages and reads status information such as total messages completed, total messages sent and status information for the doorbell message sent. This information is read through the doorbell registers. 


This command retrieves the total number of doorbell message received by reading the status of doorbell registers. This command will first internally call Init_All. 


© [2014] Altera Corporation. The material in this wiki page or document is provided AS-IS and is not supported by Altera Corporation. Use the material in this document at your own risk; it might be, for example, objectionable, misleading or inaccurate.

Version history
Last update:
‎06-26-2019 09:01 PM
Updated by: