cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor
460 Views
Registered: ‎07-03-2018

Questions about roe_framer IP Core

Jump to solution

Hi everyone,

 

I have several questions about roe_framer IP Core:

1, what will roe_framer IP core do when eCPRI packet lost? or when subsequent packets don’t have the expect format? IP core will drop this packet and continue running?

2, Size of each Data Buffer/FIFO Antenna carrier and Framer/De-framer FIFO Ethernet port?

3, In roe_framer_radio_top.v, the signal fram_radio_start was created with counter signal named fram_radio_counter, but I don't understand what does the comment mean?

// Sized to deal with a max antenna rate of 500MHz

With s_axis_fram_aclk is 10MHz, why counter start from 500 downto 0? (501 cycles?)

4, Related fram_radio_start singal, with a picture attached below, we see discarded words before detecting falling edge and valid words after detecting falling edge on fram_radio_start singal. So, after first fram_radio_start pulse, we will have all data valid? If not, how many data will be valid between 2 pulse?

Anyone who know answer for any question, let post your answer to discuss.

Thank you,

Yurivn

fram_radio_start.PNG
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
353 Views
Registered: ‎08-02-2007

@yurivn 

1. This behavior is defined in eCPRI protocol 2.0 :Table 20: Summary of link faults. We plan to support IWF (probably in next release) but not in the current version.

2. If you are talking about non-Oran mode De-framer Data Buffer, the buffer size is the number of Ethernet packets, which can be specified by user. It has been documented in PG312

"The last available option consists of specifying the number of Ethernet packets to be included in each antenna-carrier buffer. The reception window parameter, Number of Ethernet packets to buffer, when dealing with time domain traffic, can be set to either 1, 2, or 3, which defines a buffer capable of holding four, six, or eight payloads respectively."

3. I have checked the code but I notice the fram_radio_start signal was generated when the counter is trying to count up to SOF_LEN. The radio top code depends on your xci settings.  Can you attached xci file, so I can generate the same radio top file?

4. As you are aware, all data arriving before fram_radio_start falling edge is lost, and data collection and packet delivery starts as soon as the RoE Framer is enabled.

The antenna-carrier traffic is expected to be constant bit rate; in a working system, it should never be larger than the bandwidth available on the provided Ethernet links. Under this assumption, the respective s<XXX>_fram_data_tready and s<XXX>_fram_ctrl_tready signals are always asserted during normal behavior.

If you have constant bit rate on antenna-carrier traffic, the data should be valid.

You can follow the instructions in https://www.xilinx.com/support/answers/72466.html, generate simulation example, and then evaluate the tvalid and tready behavior.

 

 

 

View solution in original post

1 Reply
Highlighted
Xilinx Employee
Xilinx Employee
354 Views
Registered: ‎08-02-2007

@yurivn 

1. This behavior is defined in eCPRI protocol 2.0 :Table 20: Summary of link faults. We plan to support IWF (probably in next release) but not in the current version.

2. If you are talking about non-Oran mode De-framer Data Buffer, the buffer size is the number of Ethernet packets, which can be specified by user. It has been documented in PG312

"The last available option consists of specifying the number of Ethernet packets to be included in each antenna-carrier buffer. The reception window parameter, Number of Ethernet packets to buffer, when dealing with time domain traffic, can be set to either 1, 2, or 3, which defines a buffer capable of holding four, six, or eight payloads respectively."

3. I have checked the code but I notice the fram_radio_start signal was generated when the counter is trying to count up to SOF_LEN. The radio top code depends on your xci settings.  Can you attached xci file, so I can generate the same radio top file?

4. As you are aware, all data arriving before fram_radio_start falling edge is lost, and data collection and packet delivery starts as soon as the RoE Framer is enabled.

The antenna-carrier traffic is expected to be constant bit rate; in a working system, it should never be larger than the bandwidth available on the provided Ethernet links. Under this assumption, the respective s<XXX>_fram_data_tready and s<XXX>_fram_ctrl_tready signals are always asserted during normal behavior.

If you have constant bit rate on antenna-carrier traffic, the data should be valid.

You can follow the instructions in https://www.xilinx.com/support/answers/72466.html, generate simulation example, and then evaluate the tvalid and tready behavior.

 

 

 

View solution in original post