AIF2 CPRI Control and Management Channel

Mehly

Hi,

we try to recieve CPRI C&M from AIF2 with PktDma.

Inside of our Test C&M data we use a counter from 0x00 to 0xFF.

So normally the Delimiter value 0xFB is omitted. The result is that the Packet length is 1020 Bytes instead of 1024 Bytes (4x CPRI Rate).

We tried to configure Packet Boundaries on hyper-frame boundaries with:

aifObj.hAif2Setup->linkSetup[0]->pPdLinkSetup->CpriCwPktDelimitor[0] = CSL_AIF2_CW_DELIM_HYP_FRM;

But this results in a Packet length of 0 Bytes.

This is a behaviour we have not expected !

Who can help?

over 13 years ago

0 Seb Tomas over 13 years ago

TI__Intellectual 2975 points

Hi,

We made number of fixes on Cpri CW word handling in AIF2 LLD v1.0.0.8. I enclosed the updated LLD for c6670 here (you can untar it and replace the aif2 folder from you existing PDk install).

.2818.aif2_C6670_1_0_0_8.tar

Please note that the test example in the cprifastcm folder uses by default: CSL_AIF2_CW_DELIM_4B5B for fast c&M, and CSL_AIF2_CW_DELIM_NULLDELM for vendor specific packets. We don't recommend using the CSL_AIF2_CW_DELIM_HYP_FRM option on c6670 devices as it is not reliable.

Best Rgds/Seb.

0 Mehly over 13 years ago in reply to Seb Tomas

Intellectual 920 points

Thanks for your help.

We tried with the provides LLD but it didn't work. Further inspections showed,
that the PE LinkSetup seems to be faulty.
In the attached picture you can see the CSL_Aif2PeLinkSetup right after the
AIF_initHw() call. The values are shifted, such as CpriAxCPack should have the
value of CpriCwNullDelimitor, CpriCwNullDelimitor should have the value of
CpriCwPktDelimitor[0] and so on.
Are we missing a struct member in our setup, which could cause this behaviour?

Kind regards

0 Seb Tomas over 13 years ago in reply to Mehly

TI__Intellectual 2975 points

Hi,

It looks like I used a more recent AIF2 csl to generate the 1.0.0.8 package, hence the misalignment for the CpriCwNullDelimitor.

One way to solve that to rebuild the AIF2 LLD within your PDK environment.

Open a command prompt and go to <pdk_install_path>\ti\drv. Then call pdksetupenv.bat, and rebuild the AIF2 LLD:

gmake -C aif2 LIBDIR=./lib clean

gmake -C aif2 LIBDIR=./lib all

Please tell me how it does.

Best Rgds/Seb.

0 Mehly over 13 years ago in reply to Seb Tomas

Intellectual 920 points

Hi Seb,

thanks for your reply. After recompilation of the AIF2 LLD, the structs were
filled with the expected values and the we could successfully run the cprifastcm
test.

Now what we want to do is, read and write the values of the CPRI CW [16-19],
[80-83], [144-147] and [208-211].

The idea is that we insert a NULLDELIM on the RX side into CW 212 and with the CSL_AIF2_CW_DELIM_NULLDELM setting we would get all the
desired CW in one descriptor per hyperframe, is this correct?

But how do we ensure the same on the TX side, that the first word of each descriptor is
put in CW 16, the second in CW 17 and so on? Is this even possible?

By the way The LLD set the NULLDELM to 0xFB and not to 0x1FB (To mark a special character).

We think CpriCwNullDelimitor must be set to 0x1FB, can you explain why do you use 0xFB?
We test it, as it works as expected.

Do you plan to implement the option CSL_AIF2_CW_DELIM_HYP_FRM in the near future?

kind regards
Matthias

0 Seb Tomas over 13 years ago in reply to Mehly

TI__Intellectual 2975 points

Matthias,

Ok. This is great news.

The use of delimiters was done to actually allocate some bandwidth by selecting given Cpri control word positions, 16, 17, ... and then rely on delimiters to identify the packets. So using AIF2 and NULL delimiters guaranty the BW is allocated for a given control word stream, but does not guaranty the exact positions of the packet payload data within the allocated control word positions. So when transmitting packets, you'll need on the other side some logic to identify the NULL delimiters. I agree that what you propose for the RX side should work.

About the delimiter value, the AIF2 UG doc mentions:
(Chapter 5.2.1.4) The Programmable Null Delimiter is a unique character that identifies a null (empty
byte). The value can be any byte or any non-comma K-character (e.g. K27.7 or K29.7).
It is not permissible to have this character appear within a packet. AIF2 allows the user
to choose which null value is to be used by programming a 9-bit MMR field. Any data
that does not match the Null Delimiter is considered valid control data. There must be
at least one Null Delimiter between “packets” of control data. All characters that do not
contain valid control data should be filled with the chosen Null delimiter.

(Chapter 7.8.2.1.1) [6]PD_LINK_B.CPRI_NULLDELM: 9 bit field indicating which pattern of 9 bit data
should be used as the Null Delimiter. Bit[8] is used to indicate K-char. If this bit is zero
and that means this null delimiter is not K char, but in this case, user can not use this
8bit delimiter as a data because some data might have same value as delimiter. So User
can use unused K char like K27.7 (0xFB) for this purpose. In this case, Bit[8] should be
set as 1. Well known K char for AIF like K28.5 or K28.7 can not be used for null
delimiter.

So i understand from these chapters that bit8 needs to be zero, so that the chosen NULL delimiter is a non-comma K-character.

Finally, CSL_AIF2_CW_DELIM_HYP_FRM option can not be reliably used for TX on AIF2. We experimented that option for Vendor specific info packets with AIF2 LLD, and found out Hyperframe boundary delimiters on AIF2 cannot be used. So you need to go for NULL delimiter option. That's why you don't see this option in current LLD versions.

Best Rgds/Seb.

0 Mehly over 12 years ago in reply to Seb Tomas

Intellectual 920 points

Hi,

I'm also interested in version c6670_1_0_0_9 with superpacket workaround.

Can I download it somewhere?

Thanks
Mehly

Processors

Processors forum

AIF2 CPRI Control and Management Channel