This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AIF2 FAST Ethernet 4B/5B Enc/DecHi,

Hi,

Do you have verified 4B/5B Enc/Dec program for Fast ethernet packets? I am using "4B5BEncdec.c" under "pdk_keystone2_3_01_01_04_18\packages\ti\drv\aif2\test\cprifastcm" and I get some issues that it might be caused by this program. Here is my programming details:

->CpriCwPktDelimitor =  CSL_AIF2_CW_DELIM_NULLDELM;

-> CpriCwNullDelimitor = 0xFF;

I am using loopback mode. SFP TX is directly connected to the same SFP RX via fiber cable.

Issues found:

1. For RX side, some packets come with wrong length, and descriptor does not have full data. Descriptor size enough to hold send-data. When I check the TX side,     I see that descriptor has all 4B/5B encoded data in it.

2. Although rx descriptor contains all data , program could not find ESD sometimes?

Please let me know if you have any answer for these issues.

Thanks

Mustafa 

  • 4b5bencdec.c is used by the example program: C:\ti\pdk_keystone2_3_01_01_04\packages\exampleProjects\aif2CpriFastCMK2KTestProject.  I have run this example multiple times in a row and it consistently passes.  I haven't looked at what null delimiter is used by the example, but I suggest comparing your configuration to the example.

  • Hi,

    For the given test project, one length is used only. The problem is that I do not get any issues with that length, but when I try to run the program for all lengths (between 46-1500), for the some lengths sometimes, I receive wrong data in RX side. Somehow  the AIF2 can not capture whole data. When I look at the upcoming packet, it does not have the rest of the data either. this means, I thought that it is not caused by delimiter? 

    Another point is that inside of 4b5bencdec.c line #198, there is a small missing operator.

    #198   output[j+3] = ((esdPart1<6)|(temp2<<1)|(temp1>>4)); that should be left shift operator (<<). Without this I could not get any packets which fall into that part of the code in TX side.

    Please let me know if you have any other suggestions?

    Thanks

    Mustafa

  • Good catch on the 4b5bencdec.c!  Definitely a problem. I have created an internal ticket so it will be fixed, hopefully in the next PDK release.

    It is difficult to give a response without more information.  Have you read through section 7.8.2 of the AIF2 UG, and are following the limitations mentioned there?  Are you running the example code, or your own (and what is the configuration)?  Are the errors consistent in specific message lengths?  If you test the lengths in different orders, do the errors follow?

  • Hi,

    - I am running my code, but it is exactly the same as the example one. it has the same configuration during init.

    - Yes, the problem occurs in specific lengths only.

    -  Yes, even I tried to run the problematic lengths for many times in a row. for example, 162-byte length is one of them. I send the packets having this length for 10000 times from tx side, but some packets arrive with wrong lengths.

    I have another important question about Fast C&M.

    We can send Ethernet packets from TX side for all links over CM channel 0, however when two links are connected two different RRU, and when these RRUs want to send CM data to the AIF2 over CM ch#0 at the same time, the AIF2 does not get any packets, in fact it does not aware of it. Therefore, how can we solve this issue? or how can RRUs send CM data in any time?

    Thanks,

    Mustafa

  • Not all packet lengths are valid: (from AIF2 UG section 7.8.2)

    Packets:

    • Minimum 4 bytes

    • Minimum one Null delimiter between packets

    AxC packets must be nx4 bytes in length

    • CW packets can be any length of four bytes or more

     

    Perhaps your 162 byte packets are AxC?

  • Hi,

    AxC packets are sent/received in every symbol time. There is no problem here. CW packets run on the background task. 162 byte is for CW payload only. Payload size is between 46-1500. Therefore We should send/receive any lengths between those?

    Do you have an answer for my other question? it is mentioned previous post as "We can send Ethernet packets from TX side for all links over CM channel 0, however when two links are connected two different RRU, and when these RRUs want to send CM data to the AIF2 over CM ch#0 at the same time, the AIF2 does not get any packets, in fact it does not aware of it. Therefore, how can we solve this issue? or how can RRUs send CM data in any time?".

    Thanks
    Mustafa
  • Yes, that limitation shouldn't exist for control packets.  As for your other question, AIF2 should be able to receive control packets from multiple CPRI links.

    AIF2 needs to be programmed so that each ingress control stream is associated with a different multicore navigator queue number.

     

    .

  • Hi,

    The AIF2 has 4 separate control stream flows, but we have 6 links in total. If we map 4 control streams to 6 Links, 2 Links will be out. Is , we cannot receive CW from those 2 links? I want to run 6 links in parallel, each link should receive CW simultaneously. is that possible with AIF2 HW module?

    Thanks,
    Mustafa