Antenna Interface 2 training. Antenna Interface is one of the main IP and main interface with the [INAUDIBLE]. So we're going to transfer a lot of IQ data from the radio head and feed the data into the FFTC for all other applications. So we're going to look inside, more details how, again, Interface 2 is working and how it is different from the Antenna Interface 1.

This is the agenda of what I'm talking about Antenna Interface 2 today. So the first thing we're going to deal with is evolution from Antenna Interface 1 to Antenna Interface 2. So we're going to see what main difference between Antenna Interface 1 and Interface 2 and how it has evolved and how can we support like a packet-based stream for LTE and other gender cases. And second, we're going to look at a timer working mechanism. And the next thing will be our physical layer modules like SERDES, RM, TM, and RT retransmitter.

And next time, we're going to see some Protocol Layer Modules like Protocol Decoder, Protocol Encoder, and Data Buffer. And the next step is DMA Modules. So we're going to look at AD, AIF to DMA and a PKTDMA Module. And finally, we're going to look at all detail about Error and Exception Handling module inside.

Evolution of AIF2 from AIF1. There are several kinds of big differences between AIF1 and AIF2. The first thing-- first main difference-- is a clock strategy. So for AIF1, we were using just simple byte clock, and the frequency of the byte clock was very lower than AIF2. In AIF2 we are using a fixed size of the byte clock, which frequency is 307. 2 megahertz for OBSAI and 245.76 megahertz for CPRI.

And dual-byte clock can transport the data at the 16 bits per clock in case 8x speed link. In case of 4x speed link, they can transfer just 8-bit data. And in case of two 2x links, it can transfer 8-bit data every two clock cycles. That's the main difference between AIF1 and AIF2 byte clock.

And for AIF1, we were using byte clock for calculating delta and were using VBUS clock for calculating Pi. But in AIF2, we are using the same clock concept for all RM and TM. So all delta and pi will use the same value dual-byte clock. And the second difference is AIF2 supports 8x link speed. And 8x link speed is two times faster than 4x link, what was the maximum speed up of Faraday antenna interface 1. So we basically support 6 gigahertz SERDES with scrambling-- bit-level scrambling. And 8x link also supports the scramblers inside. So we can turn on in case of 8x link speed.

And the main problem from AIF1 was we cannot reset the internal all MMRs and other modules while running, because it was the reset isolation module. But in case of AIF2, we could easily clear and flush all MMR values by setting one reset register bit. So that is a newly added function of AIF2. And AIF2 also supports multiple radio standards with very much more flexibility. So AIF1 was basically supported WCDMA, and some cases it could support GSM and TDS-CDMA with a limited configuration.

But AIF2 flexibility can support WCDMA and LTE, WiMAX, like OFDM-based radio standard. And TDS-CDMA and GSM, they can much more flexibly support that like a base and hopping and some special timing for TDS-CDMA. So now we can say AIF2 is globally supporting with a multiple number of radio standards with very flexible manner.

AIF2 can fully support dual-bitmap rule for both OBSAI and CPRI. Actually dual-bitmap concept is coming from OBSAI spec 4.0, but we modified some part of the techniques to support CPRI with the dual-bitmap rule. So with this rule, we can easily support the generic packet transfer mode on CPRI protocol.

In AIF1, we normally supported just a link-by-link based data transfer, and we had each circular buffer for each link. And we could transfer maximum 16 antenna carriers for each circular RAM. But it was not efficient in many cases. So for AIF2, we support totally 128 channels. And that means it has 128 different FIFOs for each channel, for each antenna carrier channels. So it is supported for both ingress and egress. So we can transfer a maximum 128 channels for all six links. So it gives us great flexibility to separate each antenna carrier channel's data.

It was not possible for AIF1 because we were just transferring [INAUDIBLE] amount of all antenna carrier's data into the same memory partition. But in AIF2, we could separate the memory partition for each antenna carrier into the different-- 128 different channel buffers-- channel FIFOs. So that was much easier than AIF1's case.

And also for a DMA scheme, we have Multicore Navigator Packet Transfer, and we also support legacy mode Direct I/O for WCDMA antenna carrier DMA. So this navigator and packet DMA module inside AIF2 enable us to transfer the packet data or OFDM-style packet data very easily compared to AIF1. Direct IO is almost same to the old EDMA concept, but it's much easier to configure, and it has faster speeds than EDMA.

The next main change was, in case of AIF1, we had frame sync module outside the AIF2 core. But this time for AIF2, frame sync module is merged within the AIF2 core now, and we changed the name to AIF2 Timer. So now we can easily merge the configuration for timer and AIF2 core very easy manner.

For AIF1, we only had one timer. It's a kind of physical timer. But for AIF2 we had two kinds of timers. One physical timer is just same to AIF1 case, but we have another type of timer. It's a radio timer. So for this radio timer, we could support separate different size of frame at the same time. For example, if the phy timer frame size is always 10 milliseconds, like WCDMA case, but we can transfer different size of radio frame like a 1 millisecond, 2 millisecond, 4 or 5 millisecond. Those kind of various sizes of frame could be easily transferred with radio timer timing.

And we also support UL and DL Rad timer is supported. The basic mechanism is same just to radio timer. But UL and DL radio timer have its own initial offset. So DR timer could be started just before the radio timer, or UL timer could be started after the radio timer started. So for UL user, they can easily check the timing-- incoming frame timing for a RAC operation. And for DL user, downlink user, they can easily calculate the timing for a tag or FFTC module.

And one minor difference between AIF1 and AIF2 is dynamic configuration. Dynamic configuration means we can change some configuration while running. While running means while transferring the data. So we can change some factors or we can easily change the factor of configuration just stopping the event or just stopping the link and change something. And we can re-enable the link or channel. So we can easily add, delete antenna carrier channel to link all the external AT events. It will be explained in more detail later in this section.

This page shows the huge picture about how AIF2 looks like and what kind of modules inside and how it is connected to each other. So with the left side, you can see some phy layer, physical layer modules, like a SERDES, RM, CI, RT, CO, and TM, AT. So SERDES is the gateway to the outside of the AIF2. So SERDES is receiving some serial six links data, and SERDES will change it to the 8-bit parallel data. And the data will be transferred to RM and TM.

TM is a kind of transfer MAC module, and RM is the receiving MAC module. So TM will check delta timing whenever they transfer the data to outside. And RM will check phy timing whenever they are receiving the new frame boundary inside. And there's the CI and CO module right beside AR and TM. CI, CO is only used for CPRI protocol, so it's kind of a CPRI interleaver and outside CPRI interleaver. So it interleaves or de-interleaves the data for CPRI. So it's a very special module for CPRI protocol. And for egress side, there is a retransmitter on the egress side. A retransmitter is just sometimes just retransmitting the incoming data to the outbound side. In case of daisy chain mode, this retransmit function is usefully used to transfer the data to the next DSP.

And on protocol layer level, we have protocol decoder, protocol encoder, and data buffer FIFOs. So protocol decoder is used in inbound side, and protocol decoder will check incoming data and route the data to dedicated antenna carrier channel buffer. Protocol encoder is doing the opposite thing. So protocol encoder will select where does it insert. Well, does it have to insert some framed data into the slot? So protocol encoder is this very, very important module to make a new frame for outbound side. And as I explained before, data buffer FIFOs, we have 128 different FIFOs for each 128 antenna carrier channels or packet channels. And we have special module AIF timer.

In case of AIF1, we had some separate module like a frame sync module, Well but this time for AIF2, the timer is merged into the AIF2 and able to generate 11 external events and 6 internal events for DIM mode. And it also generates some very, very tricky parts of the module like a protocol encoder event 1 and 2 and some delta event also.

And for the DMA layer side, we have 80 AIF2 DMA modules and a CDMA. CDMA is kind of a packet DMA module. So its also included again in the AIF2. The packet DMA is used when we transfer the packet data like an RFDM radio standard case and the generic packet case. And a DIO is used for a WCDMA and some special LTE cases. And also we have some scheduler VBUSP [INAUDIBLE] modules, and the EE module also we have. EE module just detect [INAUDIBLE] and generate event. And for inside, the control line is connected to Queue Manager and SCR Bridge. So we're going to look at each layer one by one-- phy layer, protocol layer, and DMA layer to get more detailed knowledge about those modules.

For AIF1 case, we were using AIF reference clock to generate the SERDES serialized clock. So it is just same to AIF2. So we were using AIF underscore reference clock. It's a kind of LVDS signal-- differential signal. And its name is sys underscore clk for outside when we check in the Nyquist data sheet. But the only difference is we are generating the 307.2 megahertz maximum byte clock in case of OBSAI. And for CPRI, we are finally generating 2545.76 megahertz byte clock for internal modules. So all AIF2 internal modules except DBAD or some other module, we were using this byte clock as a basic operation clock.

And we have two SERDES macros like B8 and B4 and it is same to F1. And B8 is used for link 0, 1, 2, 3 and B4 is used for link 4 and 5. And one of those clocks can be used for activating internal module, which name is sys_clk-- sys_clk 0, 1, 2, 3, 4, 5. Those things are used for internal module operation.

And we have another clock option that is the AIF2 OP-1 clock, and that is exactly the same to what AIF1 requires. So we are using 30.72 megahertz differential signal, differential clock, and we also need some AIF1 [INAUDIBLE] RP1 frame burst from outside to activate RP1 interfaces. And we are receiving one more clock for AD, DB, and EE, and some other modules. It's a VBUS clock is a CPU clock divide by 3. So if we use one gigahertz CPRI clock, then the VBUS clock will be 333 megahertz. So we're going to deal some more details later when we talk about each module about the clock.

As I told you before, the main difference between AIF1 and AIF2 is AIF2 is supporting sometimes dynamic configuration. And dynamic configuration means we can set up some value, some configuration value on the fly or just turn down the antenna carrier or the link. And we can change something. Then we can just rebuild the change. So in this case, it requires a system down period, a little bit time, maybe one frame or two frames sometime.

But AIF1 doesn't support this normally. So our customer has to turn down all their system totally and configure all the things once again and re-enable all the links again. So it was one of the teaching jobs for our customer. But AIF2 can support on the fly change, all normal change, for any cases.

So here's what we can manually change for AIF2 dynamic configuration. The list are as follows-- first thing is Link Add/Delete. So we can add or delete link without resetting AIF2 timer. And we can also add antenna carrier or delete antenna carrier while running. In case of GSM Base Band Hopping, we can do that. We can change the Base Band Hopping address in real time.

And in case of LTE TDD and WiMAX TDD, we can also change the UL/DL ratio on the fly. So we can change it while the link is still running. We can change the UL/DL ratio or UL/DL timing. And in case AT timing, we can change the system event at delete. That means we can add one external event or internal event while running the link. And radio timer will do the resynchronization. Even though it lost some signals or lost some synchronization, it will be restored within one or two frame time or within one or two symbol time, many cases.

In case of AIF1, there was no reset function or reset register in the AIF2 register map. So there is no way to reset all the modules and flush the MMRs. So that was one of the most huge problem for AIF1 user. And it was not comfortable sometimes. They had to turn off the power and turn on the power again for AIF2-- for AIF. But for AIF2 has very special register-- AIF2 reset register and BC module. So we can easily set that register to one to flush all the MMRs and deactivate all modules just one time.

But there's some circuitry which is not reset during the software reset operation. The first thing is configuration VBUS. The second one is VBUSP interface. Third one is internal SCR circuit, and the fourth one is vbus_clk to sys_clk retiming bridge. Those things just stay even though we said this at the software reset MMR register. But normally all modules like [INAUDIBLE] encoder, decoder, and DB/AT timer value. All the things are just flushed and go back to 0 default status.

So we can easily reconfigure or reset AIF2 while running. This is a very useful function for cast tester and software designer and hardware designer. So that will be very useful use to turn on and turn off and reset and turn on and turn off over and over again for the test and then the debugging engineers. So I think this is the big change from AIF1.

Next thing we will look at is AIF2 timer. So we're going to look at how the AIF timer is working and how all eight external-- if you have an external event-- and the six internal event is working. Let's look at that on the next page.

As I mentioned before, AIF2 has two timers. One is radio timer and one is phy timer. Phy timer is the same concept. So it activates the physical-level timer. It has only 10-millisecond frame size, and it sets PE1 and PE2 events for PE preparation time. And it also sets delta for transmitting frame and also controls the Pi value-- Pi max value, Pi min value. So if we set the Pi min and Pi max, then the distance between the Pi min and max will be that Pi window size for RM.

Radio timer also could be separated into three-timer domain. One is radio timer, and second is UL radio timer, and third one is VL radio timer. The only difference between those three timers is initialization offset. So only initial value for clock symbol frame could be different between UL and DL and radio timer. So it is just time shifting between those three timers. So those timers can generate 11 external events. Maybe a event is used for a [? jam ?] program, CPU some special application. And we have some internal events like a delta and PE1 and PE2 events. And it is only generated by phy timer.

This figure shows how phy timer is working. Phy timer has two counters. One counter is clock counter. So the clock counter value normally should be one frame size. In case of off-side, it will be a 3071999 clock. After 3071999 clock, the clock counter will go back to 0 and frame counter-- 40-bit frame counter-- will increase, one value increased. And for initialization frame counter, we can use various offsets like in the figure. So sometimes we can use software MMR to set the frame in the value or sometimes we can use OP-1 system frame value for a frame counter initialization time.

And to feed phy sync-- phy frame sync-- we can use several options. We have some software trigger option and physical real [INAUDIBLE] trigger option from outside. And those two trigger options exist for phy sync. And we also have some different sync mechanisms for radio sync. It will be explained in the next page.

Radio timers look more complex than phy timer. We have three kinds of counters inside. One is clock counter, 19-bit clock counter, and the next one 8-bit symbol counter. The next one is 40-bit frame counter. Frame counter side the same, the 40-bit, like a phy timer. And we have also several kinds of options-- RP1 radio frame or software MMR frame. We can use those two things-- two options-- for setting the frame counter initial value.

And for sync option, we have three sync options. One option is software sync, the second option is external physical sync [? purse. ?] And third option is phyt compare value. So if phyt is using special value, we can synchronize the timing between phy timer and radio timer using that phy compare sync option. And if we use that option, the radio timer will be started after the phy timer is started-- right after it a phy timer is started.

And look at that clock counter-- 19-bit clock counter. If the clock counter is counted the maximum value, and it goes and will increase the symbol counter number one, and its symbol counter number also reached to the symbol TC, terminal count value, then it will increase the frame counter number. And we also have very special LUT index counter here. It's a 7-bit, and this could be used for special solution like LTE or WiMAX or some OFDM radio standards, which is different symbol size.

If we have always the same symbol size like WCDMA, we don't need to use LUT index. But sometimes if symbols-- first symbol is big and second symbol is smaller like this, if we have multiple different symbol size, we need to have different clock counter for each symbol. And that's why we have several numbers of clock counters. And LUT index pointing what currently-- what symbol clock counter is working on. So this is very important lookup table index for LTE and all other OFEM radio standards.

This antenna carrier option is a new concept for AIF2 AIF1 reaches only supported antenna option 0. So antenna carrier option 0 means real thinking. There's no relative optical fiber delay between antennas and BTS rack. But current day, our customers are normally using remote radio head. Some antennas are very far away from BTS, like 30 kilometers or 50 kilometers. So in that case, there might be some slight difference-- time difference between antennas. So the very close antenna will have no offset. But the very far antenna will make just slight delay, like a 4-chip or 8-chip delay, because they have long fiber lengths.

So we have to consider that off the kind of time offset for AIF2. So each link and each antenna carrier has its own antenna carrier offset. So we can easily set it into the register for each antenna carrier channel. And that will make some time delay, some separate OBSAI slot delay or CPRI sample slot delay to insert the relative data into the right position.

This figure shows the basic time relation about Pi and delta for a Rad timer, UL Rad timer, and DL Rad timer. The top two blue graphs and red graph shows the physical frame and the radio frame. And radio frame shows-- the first boundary of radio frame shows the reference time when the radio timer is started. That's the basic reference time for calculating antenna carrier offset and Pi frame time.

So for the second paragraph, you can see that the graph-- all of Pi and the radio graph frame boundary is shifted to the right side like an antenna carrier offset amount and Pi amount. So in case of UL, it will be shifted to the right side. And conversely, in case of DL radio timer, that could be shifted to the left side. So Pi could be shifted to the left side, and then the difference between the audio reference time will be the delta value-- delta offset. And also we can say, for radio timer case, we can say the time difference between the radio frame radio reference boundary and DL radio frame boundary is antenna carrier offset. So this figure shows how we can calculate-- how we can check the delta, Pi, and antenna carrier offset for each timer.

There are eight external events and three special events and six DIO events, and all Phy-level events. So AT basically supports those kind of events at the same time. And the eight external events mainly used for GEM application. So our application users can use any of these eight events for their own [INAUDIBLE]. And AT also supports six kind of internal events for direct IO. We have three DIO engines, and each two events are corresponded to each DIO engine. And one event could be used for frame event, and the other one is 4-chip or 8-chip iteration event. So the usage of those events are in our AIF2 Users Guide. And you can get much more information about detail.

And we have some Phy-level events. It is delta PE1 and PE2 events. PE1 events let PE know when the incoming redirection data can arrive. And PE2 events, when [INAUDIBLE] encoder enable the antenna carriers and enable channels. And delta is lets TM know when the real frame can go outside.

And in case of event strobe selection, we have three selections. We can use radio symbol or radio frame time or UL radio symbol, UL radio frame time, or DL radio symbol, or DL radio frame time. For AIF1, we only have had frame time option for our event strobe. But AIF2 we added the symbol time strobe for each event. And the AT-- and the main difference between AIF2 and AIF1 is AIF1's frame sync module is using the mask-based event counter. But AIF2 is mainly using counter-based events generation.

So we are always counting some value and after some value has passed, we can generate some event. That's the modulo. So we can set the modulo. If we want much more events between symbol or between frames, we can set the modulo value. For example, if we set 320 modulo, then it means we want the event could be generated every 320 clock cycles. And offset is same to AIF1. If we set the offset, then the event will not be generated during that time. And after that, the offset time-- the event will be generated from that time. So it's kind of a time delay for initial time.

The table below shows the timer field usage for different radio standards. So in case of WCDMA, the frame count is 10 millisecond frame and symbol count is time slot, and clock count was clock per slot. In case of LTE, it's a little bit different. So symbol count is 1 millisecond subframe, and the clock counters clock for subframe. So you can see that kind of different information within the table.

This example shows how WCDMA events could be generated for UMTS case. So it shows the clock count and symbol count and frame count. And for clock count, we have 204799 clock with one WCDMA slot. And we have a total of 15 slots in one frame. So we can set 14 as a terminal count. And frame count we can set anything. So within one 10-millisecond WCDMA frame, we have 15 slots, and each slot has 204799 clock count. But normally we need 4-chip or 8-chip trigger to support the WCDMA. So within one slot, we also have to generate the modeless event every 320 clock cycles. So these figures show how to set those things.

Now this figure shows how to set up the event for LTE. All other are same except that we have 307199 clock count for one subframe, and we have totally 10 subframes. So that is the only difference. And in this case for LTE, we don't need to create so many model events or offset because for LTE we can push 7 or 14 descriptors-- TX descriptor-- into the queue at one time every 1 millisecond or we can just push seven descriptors every 0.5 milliseconds. It depends on our customer's policy and because LTE is packet based data transfer mechanism so we don't need to transfer 4-chip or 8-chip size-- very small size amount of data. We can just transfer several symbols at a time.

This figure shows how we can set up the TDS-CDMA frame count for 5-millisecond subframe. In case of TDS-CDMA, the symbol size between the first one, second one, and all other ones is different. So for the first clock count TC, we set 207359. And for the second one, 84479, for other one 207359. So we could have different sizes of symbols within one 5-millisecond subframe.

Then you can see the big difference between symbol one and other symbol. All other symbols have intermediate events in the middle of symbol time. So you can generate this event by adding modulo counter. So if you set the modulo counter number does the 1/2 size of symbol, we can generate one additional event in the middle of symbol size.

From now on, we're going to look at more physical layer modules like SERDES, RM, TM, and RT modules. SERDES has two macros. One macros is B8 and B4-- the other one is B4. B8 supports links 0, 1, 2, 3 and B4 supports link 4 and 5. And we have maximum line rate as 6.144 Gbps with data scrambling. Just in case of 8x speed link.

And we have very special PLL circuit for supporting 5x speed of CPRI. So it is only used for CPRI cases. And the problem of SERDES was consuming a lot of power when we turn on all links, even though we are not using some links. So we added some special function to disable the clock for some links. So user can disable configuration-- disable the clock power for each SERDES link if we are not using that link. So we can save a lot of energy and power.

And for digital loop back mode, in case of AIF1, we supported a bump pad loop back and internal loop back together. But for AIF2, we removed bump pad loop back. So only internal loop back is supported. And we support the several line rate like 8x, 4x, 5x, 2x. And we don't support 1x speed anymore. Instead, we are supporting 8x link speed. And 5x is added for CPRI case.

The important function of RM is receiving the 8-bit/10-bit data, and 10-bit undecoded data and decoded 10-bit to 8-bit. And we'll transfer the data to proper decoder. And also we'll check the frame boundary signal with the Pi window. So RM will check the clock and the Pi offset if the real frame boundary is within the Pi window or not. So that's a main function of RM module.

And in case of OBSAI, RM module will fully activate after one chunk physical frame time. In case of CPRI, we need at least two chunk frame time before activating RM to the fullest sync status.

TM is in the opposite side of RM. And TM has some special FIFO as a buffer of transmit data. So that's why we can set some delta little bit bigger value than we need. And this FIFO is not configurable from the program. It will be automatically controlled by hardware. User you can only move the delta value to select when TM can transmit real data to the SERDES.

And TM also doing some L1 inband control in case of CPRI. So for CPRI, we can set up the several combinations of those L1 inband signals like LOF, LOS, SDI, or RAI signals. And the important thing is TM is checking the delta and then the PE1 and PE2 preparation offset, which is controlled by AT. So checking delta and 10-bit encoding and checking the data transmit time is the main purpose of the TM module.

CI, CO is special CPRI input and output module. So it provides the convergence between the CPRI frame format and internal data format. So the raw IQ data will be interleaved or de-interleaved within antenna carrier samples. So it has several options like 7-bit, 15-bit egress, 7-bit for ingress. And the 8-bit, 16-bit option also has.

So it supports pass-through of reserved bits and 8-bit UL and 16-bit DL in case of 2x link rate. Also it provides I or Q saturation for the transmitter. Sometimes in case or TDS-CDMA, I and Q data will be saturated when they are aggregated from the RT module, and it also provided by CI, CO module.

Retransmitter is a little bit different to the aggregator module in AIF1. AIF1 we can only aggregate or the transmit P data through the egress side. But for RT, we have one more option. One more option is added. It is insertion mode. For WCDMA cases, insertion mode means just we're receiving the data from the PE. But in case of OFDM radio standards, we can insert some valid data into the frame, and we can also receive the other Nyquist valid data and insert it into the empty frame slot. So it's a little bit different to what WCDMA is doing.

We have also redirection mode and addition mode. Addition mode is the same. In case of WCDMA, addition mode is kind of aggregation. So [INAUDIBLE] signal will differ and antenna carrier signal will be aggregated. But in case of the OFDM, it's not aggregated. Only valid antenna carrier data will be inserted into the empty slot. So all the Nyquist on the board in the chain-- within the daisy chain-- should share the bandwidths between different Nyquist and different antenna carriers. And for AIF2, we removed combiner/de-combiner module. So now we don't support anymore the combiner, combining, and de-combining functions.

Now we're going to look at protocol layer modules like protocol encoder, protocol decoder and data buffer more detail on the next page. Well, OBSAI message, we have AD address and type and time stamp filled in the header. And it is used to make a decision for incoming data routing. So proper decoder will decide where should it transfer data, to which channel FIFOs based on the information in the header, like an address type and time stamp.

So time stamp should be the writing sequencer order, and the type should be one of the radio standards like WCDMA or LTE or whatever. And the address should be the unique one. Each antenna carrier for each Nyquist, each antenna carrier has its own special address number. So it shouldn't be the same like other antenna carrier offset address.

In the case of CPRI, it uses positional based predefined position for different antenna carrier data. So it easily differentiated which one is antenna carrier 0 and which one is antenna carrier 1. And control is also easy. We were going to use four special channels-- 124, 125, 126, 127-- to transfer the control data. So four channels could be assigned to each link to transfer packet data or control data.

The CPRI control data has special field, and it is same to AIF1 cases. Slow DCNM C&M and the fast C&M and for vendor-specific data and some L1 inband data. In case of slow C&M, it is not supported by AIF2, but say I have two supports which support fast C&M, fast ethernet data, so user can transfer ethernet data and AIF2 hardware will track the ethernet header and will also attach the CLC data at the end of the payload. So this ethernet header could be fetched or parsed if is set to register to use to ethernet mode, And it is fully configured by user program.

And CPRI also supports 4-bit/5-bit encoding/decoding for ethernet or packet users. So we need to know where is the start of the packet, and where is the end of the packet. But for CPRI, it's already packed in position data. So there's no way to set the SOP and EOP for CPRI cases. That's why we need to use 4-bit/5-bit encoding or null delimiter to special case. And we can insert some SOP information or EOP information for packet transmitting. Null delimiter use case is a little bit complex. So you'd better read the User Guide to get more detailed information.

The only difference between AIF1 and 2, AIF2 will not support 1x link rate and support 8x link rate. And message group number is same. For 2x link, we support 40 data message and two control messages. And in case of 4x link rate, we support 80 data messages, and at the end of the 80 data messages, we transfer four control messages.

In case of 8x, we transfer 160 data messages, and at the end of that, we also transfer 8 control messages continuously. But the different thing is for AIF1, we could change the position of the control messages at any place in the frame. But for AIF2, it is already fixed position, so we cannot change or move or shift control message position to different places. That's the major difference between AIF1 and AIF2 OBSAI protocol specific. And AIF2, CRC is supported. So AIF1 doesn't support any CRC, so we cannot guarantee any data redundancy. But in case of AIF2, we are using 16-bit or 8-bit or 32-bit CRC for ethernet cases or the packet traffic cases.

For OBSAI we can use time stamp not only as a normal time stamping but also for a special use for ethernet time stamp and general packet time stamp. For antenna carrier time stamp, we can just increase every OBSAI message, but for ethernet or generic packet [INAUDIBLE], we can use very special already defined time stamp value to differentiate if that slot is SOP or MOP or EOP.

So in case of ethernet, if you set 100000, we can say that OBSAI slot is SOP. And we set the other things, we can say check it like MOP or EOP. It is same to generic packet time stamp. The value is a little bit different, but the OBSAI machine can easily differentiate if that OBSAI slot is SOP or MOP or EOP. So it is easier solution than CPRI case.

For AIF1, we had very complex style of transmission rule. And AIF2 has totally different style of transmission rule, but it's also complex and not easy to understand. So we'd better separate the total rules into three pieces. The first one is modulo rules. The second one is dual bit map rules, and third one is channel lookup table.

So modulo rule is a user can assign one modulo rule to link or two modulo rules, one modulo for antenna carrier data and the other modulo rule for control data. So modulo rule is a kind of a base rule. And the dual bitmap rule can work on top of the modulo rules. So normally we can say we assign one modulo rule for one link. Then we can set the same dual-bitmap rule on top of it. If we use modulo 0, then the dual-bitmap rule 0 also will work on top of it.

Totally, we have 64 modulo rules and 64 dual-bitmap rules. And that's why we have 4096 channel lookup table. And channel lookup table matching the transmission rule index from the 64 rules into each DB channels and is split across eight different ramps. For CPRI we are using from RAM 0 to RAM 5 for six links. But for OBSAI, we are going to use totally eight different RAMs together.

So understanding this kind of thing is very important to understand how AIF2 transmission rule is working. So I have two users guide PE section spare a lot of pages to explain how to use 64 modulo rules and 64 dual-bit map rule and how each rule can match with each different channel lookup tables. So 64, multiply 64 as if 4096. And that's why we need a lot of channel lookup tables. And that 4096 channel lookup table is divided into eight different RAMs because designers have to support CPRI and OBSAI together. That's why we should separate it into the eight pieces. That may be only six pieces from that is used for CPRI.

Normally dual-bitmap rule-- dual-bitmap FSM concept is mainly used for a OBSAI, and it is in the OBSAI spec. But for CPRI we also developed something special. So our design team developed some very special dual-bitmap rule for CPRI. For OBSAI, the dual-bitmap rule, each rule is matching with each OBSAI slot. But in case of CPRI, each rule is mapping to the CPRI sample size, 4-byte sample.

So actually the DBMF is essentially very simple round robin TDM of antenna carrier the addition of programmable bubble insertion at the end of each cycle of round robin. So we can set the size of the bubble for each insertion time. This is not easy and very complex scheme. So you'd better check AIF2 Users Guide if you want to get more detail about this.

So basically basic transmission rule scheme is same to OBSAI. We're going to use only one dual-bitmap rule per link, but we don't use a modulo rule for CPRI because CPRI dual-bitmap rule is working link based. So each link base we're going to have one dual-bitmap rule. So totally we have six dual-bitmap rule. And on top of it, the 128 channel lookup table is using per link. So each channel lookup table or size is only 128 for each antenna carriers. And it is much easier to set up the channel lookup table than OBSAI cases.

This figure is coming from OBSAI spec 4.0, and this is kind of an illustration of OFDM data transmission through OBSAI link, 2x link speed cases. So let's say we set the three OBSAI [INAUDIBLE] as a group, and we set the bitmap 1 as 0x, 0004, 001, 004, 002, then we can say we normally transfer the just normal group, like a 1, 2, 3-- antenna carrier 1, 2, 3. And it will be repeated until this bitmap number is 0.

So we can transfer 1, 2, 3, 1, 2, 3, 1, 2, 3 over and over again, but when the bitmap is 1, then we can insert one bubble OBSAI slot. So we can only insert the bubble slot when the bitmap is 1. Like this, we can change some slight different-- we can use slight different timing for transmitting. And with this method, we can adjust the slight different timing for each different radio standard.

For WCDMA, we don't need to insert any bubbles, but for different radio standard like LTE and WiMAX, we need to insert some bubbles inside a frame to exactly match the frame data into WCDMA or the Pi frame size scale.

For both OBSAI and CPRI, we are using channel lookup table for finer transmission rule step. So for OBSAI, we have totally 4096 channel lookup table. And for CPRI cases, we have 128 channel lookup table per link. So for CPRI, we're going to use 6 channel LUT RAM, but we are using whole 8 channel LUT RAM for OBSAI cases.

So in case of CPRI link0 is using RAM 0. Link1 is using RAM 1 and link5 is using RAM 5. But for OBSAI, OBSAI is using all RAM 0, from RAM 0 to RAM 7 for their purpose. Actually AIF has its own AIF2 timer inside AIF2 Mega-Module. And the timer event is used for generating internal event and external event. But protocol encoder/decoder also has some special antenna carrier framing timer inside. And it is totally different one to AT timer event generator. It only generates some signal for protocol encoder and decoder when they are checking the OBSAI or CPRI frame timing.

So the main difference, the symbol counter and LUT index counter look similar, look almost same to AT timer concept. But the main difference is a clock counter. AT is using this clock counter, but this protocol encoder protocol decoder is using message counter. Message means the size of the OBSAI message or the CPRI simple sample message size. So we are counting the number of OBSAI messages. So how many OBSAI messages do we need to transfer to count one symbol size? So this is very important to check where is the start of the packet, where is the end of packet?

For LTE-- let's think about LTE. We don't know where is the start of packet and where is the end packet. But we know the length of the LTE symbol, how large is, how first symbol is large, and now second symbol is the size. So we already know the size of the symbol. So we can set this timer, protocol encoder/decoder, special symbol counter, and the messaging counter to check how many symbols we are receiving, how many symbols we are transmitting.

So in case of packet mode cases, we can use just a 4-bit/5-bit encoding/decoding or the time stamp field for checking the SOP and EOP. But in case of just normal antenna carrier data, we have no way to mark the SOP and EOP. And that's why we are using these PD/PE special framing counters.

Data buffer module is basically 16-byte interface. So we say the 16-byte as a quad word. So normally transfer the quad word per each antenna carrier. In case of DL data, they are transferring one quad word per antenna. In case of UL data, it transfers 2 quad word for antenna carrier. And basically DB is a kind of 128 number of FIFOs, but at the same time it is used for a circular buffer-like Faraday case. For direct IO for WCDMA, we can use a DB as the circular buffers. But basically it works like FIFOs.

So it supports up to 128 buffer channels. It's a maximum size. And each FIFO size is very flexible. So we can program the size of each FIFO reflexively. So the minimum FIFO size is 8 quad word, but the maximum is 128 quad word. So we can variously change this FIFO size by setting some MMRs and DB.

And we also can support some data swapping like a byte-level swapping word-level swapping, and IQ-order swapping. So if the data order is not good for some customer, then the customer used their own policy and can swap the data or to swap the IQ for big [? ND ?] and little [? nd ?] according to their system. We also have DB debug data RAM and DB debug sideband data RAM. It's a very special purpose like a logic analyzer. AIF1 also supports this kind of functionality but two users also can use this for some special case when they're debugging the incoming data.

We're going to look at more detail about DMA module. DMA module has AD module and packet DMA. We're going to look inside more detail from the next page. AD module means AIF2 DMA and it supports separate ingress scheduler and egress scheduler. Basically, for egress scheduler, is used to control Queue Manager and the packet DMA module inside AIF2. It's very special case. For all other interfaces like [INAUDIBLE] and PA, FFTC, the scheduler in the Queue Manager is used to transfer data.

But in case of AIF, AIF has its own scheduler inside the AD module. So it will schedule by consumption based. So even though [INAUDIBLE] pushed some-- user pushed some descriptor into the Tx queue, AIF2 will not fetch the queue right away. It will fetch some queues one by one when the data is consumed by protocol encoder.

And it also supports EOP counter for our both directions. So we can easily see how many packets are passed through the egress side or ingress side. And in the AD, we have 3 DIO engines for both directions. So 3 DIO engine can have different source address and destination address. So we can support multiple memory and multiple IP for ingress side and egress side.