design of 3gpp lte physical layer baseband system on cell...
TRANSCRIPT
Design of 3GPP LTE Baseband Downlink System on Cell Platform
Version 0.1
Written by Hui Feng, Yanzhe Xin, Ziji Hu, Fan He Fudan University
2009-8
1. INTRODUCTION ...............................................................................................................1
1.1 PROJECT BACKGROUND................................................................................................... 1 1.2 OBJECTIVE AND REQUIREMENT ANALYSIS............................................................................ 1 1.3 BRIEF INTRODUCTION TO SOFTWARE AND HARDWARE PLATFORM.......................................... 1
2. KEY PROBLEMS ANALYSIS AND SOLUTIONS...................................................................2
2.1 EFFICIENT ALLOCATION OF SPU RESOURCES....................................................................... 2 2.1.1 Solutions to Large Size of Data ........................................................................... 2 2.1.2 Solutions to Large Size of Code .......................................................................... 3
2.2 THE INTER-CORES COMMUNICATIONS................................................................................ 3 2.3 LOADING AND EXECUTION OF SPU PROGRAMS .................................................................. 4 2.4 SUMMERY ........................................................................................................................ 4
3. SYSTEM DESIGN...............................................................................................................4
3.1 OVERALL DESIGN............................................................................................................. 4 3.1.1 Main Procedures and Architecture ................................................................... 5 3.1.2 Allocation of Code and Data ............................................................................ 5 3.1.3 Overlay mode....................................................................................................... 7
3.2 DATA TYPES AND DATA STRUCTURES .................................................................................. 7 3.2.1 Data Types ............................................................................................................ 8 3.2.2 Data Structures ..................................................................................................... 8
3.3 DESIGN OF THE COMMON FUNCTIONS............................................................................. 10 3.3.1 Wrapped DMA Function ................................................................................... 10 3.3.2 Inter-Cores Communication Mechanism........................................................ 12 3.3.3 Vector Calculation and Operation Functions................................................ 16
3.4 DESIGN OF LTE SPECIFIC MODULES ................................................................................. 16 3.4.1 Main Flow of LTE.................................................................................................. 16 3.4.2 General Design of Specific Modules ............................................................... 19 3.4.3 Details of Modules Design ................................................................................. 22
4. OTHER PROBLEMS DURING DEVELOPMENT ..................................................................22
5. CONCLUSION................................................................................................................23
REFERENCE ............................................................................................................................24
ANNEX A FUNCTION SPECIFICATION................................................................................24
1
1. Introduction
1.1 Project Background
Third-generation (3G) wireless systems, based on wideband code-division multiple access (WCDMA) radio access technology, are now being deployed on a broad scale all over the world. The first step in the evolution of WCDMA has been taken by the Third Generation Partnership Project (3GPP) through the introduction of high-speed downlink packet access (HSDPA) and enhanced uplink. These technologies provide 3GPP with a radio access technology that will be highly competitive in the mid-term future. However, user and operator requirements and expectations are continuously evolving, and competing radio access technologies are emerging. Thus, it is important for 3GPP to start considering the next steps in 3G evolution, in order to ensure 3G competitiveness in a 10-year perspective and beyond. As a consequence, 3GPP has launched the study item Evolved UTRA and UTRAN, the aim of which is to study means to achieve further substantial leaps in terms of service provisioning and cost reduction.
Compared to the previous 3G system, the LTE wireless communication system is based on orthogonal frequency division multiple access (OFDMA) technology in downlink and single carrier frequency division multiple access (SC-FDMA) technology in uplink. Meanwhile, enhanced technologies such as hybrid automatic repeat request (HARQ), space time coding (STC), multiple input multiple output (MIMO), and enhanced link adaptation (AMC: adaptive modulation and coding) are all supported by LTE to improve the broadband access speed.
This is an open-source project sponsored by International Business Machines Corporation.
1.2 Objective and Requirement Analysis
The objective of this project is to realize the physical downlink shared channel of 3GPP LTE protocol on the Cell platform of PS3, including verifying the feasibility of this development and proving the validity of development result. The HARQ and MIMO mechanism are required.
The speed of LTE process simulator running is not considered as an important test reference. Thus the most important requisition is to develop the process from transmitter to receiver correctly.
Moreover, multiple SPUs are not required during current development stage.
1.3 Brief Introduction to Software and Hardware Platform
We use the Cell processor on CSE PlayStation 3 as the hardware development platform. The Cell Software Development Kit v3.1 and Fedora 9 are used as software platform.
Other third-part software, if used, will be covered in detail later.
2
2. Key Problems Analysis and Solutions
2.1 Efficient Allocation of SPU Resources
The specific LTE modules program runs on SPUs. However, each SPU only has a local store with small size 256KB, bringing forth the serious problem of allocating SPU limited resources for the large amount of data or code of LTE program.
2.1.1 Solutions to Large Size of Data
The following table shows the maximum data size in LTE specific Modules. Table 1 the largest possible amount of data output from some modules
Modules The Maximum Data Size in Modules (byte) CRC Attachment 75400
Segmentation 18432 Turbo 239772
Interleaver 240864 Rate Matching 91080
Scrambler 91080 Modulator 121440
Resource Mapping 147840 Symbol Generator 245760
It is clear to see that the size of the data generated by some specific modules is very close to the 256KB limit of the SPU local store. As a result, it is impossible to allocate memory space to store such large amount of data in SPUs.
So we use PPU main memory to assist SPU to deal with the large amount of data. All of the data to be transmitted through the LTE process is stored in the main memory.
During a specific module, SPU first gets the needed data from the main memory with DMA. After the data process finishes, SPU asks PPU to allocate a suitable size of memory space for the new packet of data generated, through Mailbox function. If the allocation successes, PPU will return the address of that memory space recorded to SPU for later use. At last, SPU puts the new data out to the address allocated in the main memory.
During the next module, with the address of the previous data in main memory, SPU gets the data in. Just like the previous modules, SPU asks PPU for a memory space in main memory and puts the new data out.
After all the modules end, SPU will inform PPU to free all the allocated memory space used to store the data.
This solution can solve the problem of limited size of the SPU local store. There is always enough space for data in PPU main memory. PPU supports memory allocation much better than SPU does. SPU can use all of the 256KB memory on real-time operation, without spending the limited local store resource on storing data.
3
However, there are two problems brought forth by this solution. First, DMA function is used to convey the large amount of data between SPUs and PPU.
Frequent DMA operations may bring large time overhead. What’s worse, the original DMA functions offered by Cell SDK 3.1 have several defects, making DMA functions inconvenient and unstable. So we need to design new functions wrapping original DMA functions and make the time overhead as small as possible. The related content will be covered later in 3.3.1 wrapped DMA Function.
Second, inter-cores communications are necessary. Because SPU informs PPU to allocate or free memory space, Mailbox function has to be used to perform those operations. There are several pieces of information to be transmitted between SPU and PPU during once allocation or free operation, such as data size, address of allocated memory space and the pointer to the memory space for free operation. A bunch of Mailboxes read/write operations are wrapped as specific function, which will be discussed later in 3.3.2 Inter-Cores Communication Mechanism.
2.1.2 Solutions to Large Size of Code
The transmitter of LTE has several modules, including segmentation, resource element mapping, interleaving, turbo encode, channel estimate, symbol generate, HARQ etc. There are corresponding modules in the receiver. Especially, some modules are very complicated, like turbo encode, channel estimate and resource element mapping,. A single SPU cannot afford such large size of the total code without Overlay mechanism.
If we use multiple SPUs to solve the code size problem, we need to distribute these modules into different SPUs. This method may not be able to achieve the effect desired, because unsuitable design will cause unnecessary data transmission which brings large time overhead. Even if we use all the six SPUs on PS3, there may still be multiple modules on a single SPU because of so many modules. The local store memory of this single SPU maybe still can’t store these modules’ codes. At last, the complicated communications and DMA mechanism between SPUs and PPU will also be much more complicated than single SPU method. The stability of the whole program will be dragged down if the inter-cores communications works unreliably.
In a word, using multiple SPUs may not be suitable for early development. After comprehensive consideration, we use Overlay to solve this problem. Because only a single SPU is needed while using Overlay, the inter-cores communications can be much simpler than using multiple SPU. Each module or function will simply be an independent segment of Overlay without additional analyze and design. Because the swap in and out of segments is totally automatic, Overlay is more stable and convenient. It is important to notice that this project doesn’t pay attention to the efficiency of program running, so we don’t need to worry about the time overhead caused by segments swap. The specific Overlay analyzes and design will be discussed in 3.1.3 Overlay Mode.
2.2 The Inter-Cores Communications
According to the previous solutions, large amount of data is stored in PPU main memory.
4
Some complicated modules, like channel simulator, are also put in PPU main memory for convenience. As a result, SPU should inform PPU to allocate or free memory space or dump the data to a specific file. Many other kinds of tasks also have to be done between SPU and PPU.
We wrap these operations tasks and design a so-called inter-cores communications system. This system is designed as two main parts. One part is in the SPU and the other is running in PPU. When SPU needs PPU’s assistant, the SPU part transmits requirement to PPU with necessary information. After the PPU part receives the requirement, PPU performs the corresponding task. At last, the PPU part returns the result to SPU part.
The design of the inter-cores communications system and specific requirement module will be covered in 3.3.2 Inter-Cores Communication Mechanism.
2.3 Loading and Execution of SPU programs
As the size of SPU programs may be larger than the sum of SPUs local store space, the loading and execution of SPU programs will be a big problem. The programs of different modules need to be loaded and executed dynamically.
From the previous sections, we have concluded that Overlay should be used. The loading and execution of each module code is automatically done by Cell system with Overlay. What we need to do is to properly design segments and assign different LTE modules into diverse segments. This task is much easier than distributing different modules on multiple SPUs.
The main content of Overlay design which will be covered in 3.1.3 Overlay Mode.
2.4 Summery
Here we made a conclusion to these solutions. In fact, all the solutions are mainly to solve the problem aroused by the limited size of SPU local store. The inter-cores communications system is used to assist PPU to allocate resource for SPU. And the loading and execution of programs are solved by Overlay.
The large amount of data is stored in PPU main memory to save local store space. Overlay function guarantees the large size of code and the complex modules can be loaded and executed dynamically on a single SPU. The wrapped DMA functions and inter-cores communications system are the most important underlying functions for these solutions. These two topics will be covered in detail in next chapter. So is Overlay.
3. System Design
3.1 Overall Design
Here PPU and a single SPU are used. The PPU program is designed to create, manage and
5
end SPU thread. The SPU program, responsible for calling each specific LTE module in order, is loaded after the PPU creates the SPU context.
Packets and large amount of data are stored in PPU’s main memory, conveyed between SPU and PPU by DMA functions. Inter-cores communications system synchronizes the SPU and PPU. Other underlying functions, such as vector calculation and operation, should be designed according to Cell processor properties.
3.1.1 Main Procedures and Architecture
After initializing the SPU thread and context structure, the PPU main program creates the SPU context and starts the SPU main program. Then, PPU program enters the loop of inter-cores communications and waits for the SPU requirements.
The SPU simulates several times with diverse SNR and different amount of data. During each time, after packets and data for test are initialized, the SPU calls the LTE modules in order according to the test mode specified. If the SPU needs assistance from PPU, it will call inter-cores communication system to inform PPU and wait for the result returned. When the whole simulator ends, SPU outputs the test result and informs PPU to exit.
At last, PPU jumps out of the inter-cores communication loop and ends the whole program. The main procedures and architecture are shown in Figure 1.
Figure 1 the main process of the program
3.1.2 Allocation of Code and Data
There are mainly three kinds of program running on PPU. First one is the PPU’s main
6
program. The second one is the PPU part of the inter-cores communications system. The last is some functions for global parameter configuration.
SPU contains several kinds of programs for different use. The SPU’s main program initializes data and calls diverse function modules. Some .c files and .h files define new data types and data structures. And the codes of each specific LTE modules are written separately, including the .c files of transmitter part and receiver part with an .h file. The underlying functions include SPU part of inter-cores communications system, DMA functions and vector operation functions. There are other function code for the global parameter configuration and initialization. Also, we need Makefile and other compile scripts for Overlay.
The allocation of code is shown as Table 2 and Table 3. Table 2 Code in PPU
Functions Specific Programs
PPU Main Program ppu_main.c and .h
PPU Part of Inter-cores Communications System
icc_ppu.c and .h
Global Parameter Configure global.c and .h,
conf_para_ppu.c and .h
Compile File Makefile
Table 3 Code in SPU
Functions Specific programs
SPU Main Program process_test.c and .h
Specific LTE Modules e.g. modulator.c demodulator.c modulator.h
Underlying Functions wrapped DMA functions, SPU part of inter-cores
communications system, vector operation functions etc
Define Data Types and Structures packet.c and .h, lte_types.h
Configuration and Initialization global.c and .h, conf_para_spu.c and .h
Compile Files Makefile, linker.script.ed
The large amount of data is stored in PPU. They are DMAed in and out during specific
modules. The memory space for these data is allocated or freed by PPU to the SPU’s demand. Some calculations or operations on these data are also done in PPU without DMA operation to save time. For example, the PPU takes charge of the statistics and output operation when SPU requires.
7
3.1.3 Overlay mode
Overlay is designed according to the allocation of SPU codes. These codes can be divided into three kinds, the main program, the LTE modules, other common functions. So we design three regions in Overlay.
The root region contains object files of the SPU main program. As the globle .o is responsible for the global configuration and initialization, it is also put in root region.
The second region contains the common functions, including SPU part of inter-cores communications system, wrapped DMA functions, vector operation functions and packet.o etc. These common functions are called very often by LTE specific modules. Each kind of function forms a segment in the second region.
The specific LTE modules are in the third region. Each segment is a module. The detailed Overlay design is shown in Figure 2.
Figure 2 Overlay design
3.2 Data Types and Data Structures
The data types used in LTE protocol are variable. The SPU local store has limited size. We should choose proper data type to minimize data size while guaranteeing precise. And the
8
calculation and operation on the large amount of data are complicated. It is very necessary to create new data types and structures for convenience.
3.2.1 Data Types
There are mainly four kinds of data type, bits, integer, float and complex. We use an 8-bit unsigned integer to represent single bit. A new created structure complex_t stands for complex data. We also have to create a new data type standing for the addresses used in DMA functions for convenience.. We name this data type ppu_addr, actually a 32-bit unsigned integer.
Except the new created data types, all the types used are standard Linux C data types. We use three types of integer, uint8_t, int8_t and uint32_t, defined in standard C integer head file stdint.h.
Different LTE modules use diverse types of data, which should be carefully chosen. The turbo decoding module deals with complicated process and large amount of data. It can’t use float types as LTE protocol says because of the limited size of SPU local store..So we use int8_t type instead of float in turbo module. This change of data types will make a impact on the turbo module performance.
The detailed information of data types used in this program is showed in Table 4. Table 4 data types used
Data Types Description Usage
uint8_t 8-bit unsigned integer or
stand for a single bit CRC Attachment, Segmentation,
Interleaver etc
int8_t 8-bit signed integer Turbo, Demodulator, etc
uint32_t 32-bit unsigned integer Count the data size
Float 32-bit floating point number Used in complex calculation
complex_t Data structure of complex Modulator, Resource Mapping, etc
ppu_addr uint32_t Stand for the address of data stored in
PPU main memory
3.2.2 Data Structures
We create kinds of common data structures. We only talk about the structures used often in almost every module. Other structures used only in a specific module are not introduced specially.
The first kind is designed to define a packet. The packet, which is the fundamental processing unit, contains all the data and parameters
9
needed in different stage of LTE process. There are two types of packets. One contains one block of data, and another contains several blocks of data.We design three structures to define packets.
The first one is pket_para_t, which contains all the parameters companying with packets in different stages of LTE process. The details will be covered in Annex A
The second is packet, containing information of one data block, like the address of this data block in main memory, the data type and the data size. It also contains the pkt_para_t. The detailed definition is shown in Annex A 3.1 Packet Structures. We create another structure packet_vec to define the packets containing several data blocks. A packet_vec contains some information of these small blocks, like addresses in main memory, the size of each small blocks and data type. The pkt_para_t is also contained. The detail of packet_vec is covered in Annex A 3.1 Packet Structures.
Second, the program will often deal with the large amount of data, considered as a vector. Thus it is necessary to create a structure vec_t to for convenience. The structure is defined as following. typedef struct{
void *p_spu_data; uint8_t data_type; uint32_t data_len;
}vec_t; The pointer p_spu_data indicates the address of the vector in SPU local store. data_type and data_len have the same meanings as those in packet. This structure will be used in vector calculation and operation. The third new structure is complex_t.And it is a doubt whether the compiler supports the complex type of standard C well. So we create our own complex type. typedef struct{ float real; float imagine;
}complex_t; The variable real means the real part, while the imagine stands for the imagine part. We use float type here, because the SPU local store can’t hold the large amount of the data if double type used. Sometimes in the actual calculation, we can regard the complex_t as two float numbers. The fourth kind of structures is global parameters, including debug_para_t, sim_para_t and harq_para_t. The debug_para_t contains parameters controlling debug process. The variables and structures in sim_para_t show the global parameters of LTE simulator process. The harq_para_t controls the HARQ type. The specification of these three structures is shown in Annex A Global Parameters. The last kind, message, is designed to pass multiple parameters to SPU part functions of inter-cores communication system for conevience,because different SPU functions of inter-cores communication system need diverse number and kinds of parameters. The specific structure is shown as following.
10
typedef struct{ uint32_t addr_vector; uint32_t data_size; uint32_t data_type; char file_name[5];
} message; addr_vector shows the address of the specific data in main memory. file_name[5], used in dumping data function, contains the four letters that used as the dump file name. The detailed usage of these structure parameters is covered in 3.3.2 Inter-Cores Communication Mechanism and Annex A 4.2.1 Inter-Cores Communication System SPU Part.
3.3 Design of the Common Functions
Because of the multiple-core architecture of Cell and our solutions, the support of inter-cores communications system and DMA functions are important. The calculation and operation functions of vectors are also needed to deal with large amount of data vectors.
3.3.1 Wrapped DMA Function
The original DMA functions have been offered by Cell SDK 3.1 with some defects and requirements. A single DMA operation can only convey at most 16KB data, Second, the size of data to be conveyed must be 1, 2, 4, 8, 16 bytes or multiple of 16bytes. Third, , the source address and the target address must be with at least 4 bits alignment.
As a result, we should wrap the original DMA functions as new functions to solve those problems. The new functions should be able to convey data more than 16KB, because the size of data in LTE is often very large. The data should be padded to be multiple of 16 bytes.
The wrapped DMA functions include two main functions. The one is dma_in, used to convey data from main memory to local store. The other is dma_out, used to convey data from local store to main memory. The two functions are shown as following. The specification is shown in Annex A 4.1 Wrapped DMA Functions.
int dma_in(void *p_spu_data, ppu_addr addr_ppu_data, uint32_t byte_size, uint8_t spu_id); int dma_out(void *p_spu_data, ppu_addr addr_ppu_data, uint32_t byte_size, uint8_t spu_id);
After dma_in or dma_out is called, the DMA function checks the byte_size to see whether the size of the data is larger than 16KB. If it is more than 16KB, mfc_get or mfc_put will be called to convey 16KB data several times until the left size of data is less than 16KB. If the left size is not the multiple of 16 bytes, DMA functions will pad the data and call mfc_get or mfc_put. The flow of the DMA function is shown in figure 3. More than 16KB data can be conveyed during one operation with new DMA functions. And the actual size transmitted will always be multiple of 16 bytes. The alignment of the source address and target address should be guaranteed while allocating memory space in main memory and defining data buffer. This detail will be talk about in inter-cores communication and specific module design.
11
According to the documents of Cell SDK 3.0, the original DMA operation will reach the transmission speed peak, only if the addresses in main memory and local store are both 128 bytes align and the data size is the multiple of 128 bytes. However, this peak may not be reached in our program.
In SPU, the local variables only can have a guaranteed alignment of 16 bytes at O2 optimization level, or 32 bytes at O3 optimization level, while the global variables can have 128 bytes alignment. But the amount of the buffers needed by DMA transmission is so large that these buffers can only be defined as local variables.
Thus, padding data to multiple of 128 bytes during transmission from main memory to local store may cover the next buffer whose address is only 32 bytes align. This situation is shown in figure 4. The part of buffer 2 is covered by the padding of the data conveyed into local store. It will cause segment fault or bus error during process. To avoid such a dangerous situation, we should pad data to multiple of only 16 bytes or 32 bytes .
As a result, the transmission sped of new DMA functions will be far below the peak speed.
Figure 3 the flow of dma_in and dma_out
12
Figure 4 Padding may Cover Next Buffers
3.3.2 Inter-Cores Communication Mechanism
The inter-cores communication mechanism is designed to do six tasks, including memory allocation, memory free, dumping data, channel simulator, bit-error-ratio statistics, informing PPU that SPU exits. This mechanism is realized by using Mailbox function.
As seen in previous sections, there are two parts of inter-cores communication system. The one is in SPU and the other is in PPU. The SPU’s write outbound mailbox and read inbound mailbox are used to transmit and receive messages.
To let PPU and SPU distinguish diverse tasks, we define some message types to represent different tasks. For example, we define MALLOC as 0x1 to stand for memory allocation.
1. The main flow of inter-cores communication mechanism After initialization and creating SPU thread, the PPU program enters into the loop of PPU
part of inter-cores communications system. The loop continuously checks the SPU write outbound mailbox to wait for the requirement of SPU.
When SPU program needs PPU’s assistance, SPU program values the parameters in message and passes it to the specific function of SPU part of inter-cores communication system. Then SPU part program writes a 32bits message into Write Outbound Mailbox, containing the SPU id, the task type number and maybe other information got from message. The SPU id is used to distinguish different SPU if using multiple SPUs in later development stage. Here we use only single SPU and the SPU id is defined as 0.
When PPU part finds that SPU Write Outbound Mailbox is full, it halts the loop and reads this 32bits message. According to the message type number, the PPU part calls the corresponding task program. SPU id is unnecessary with single SPU used.
After that first message is taken by PPU, SPU puts all the other messages abstracted from message into Write Outbound Mailbox in sequence. At the same time, the specific task program in PPU reads them in the same order.
After the task program finishes the task, it writes the result into SPU read inbound mailbox and continues to loop.
Until SPU finishes all the modules, SPU part will inform PPU part to exit. Then, PPU part jumps out of loop and the whole inter-cores communication system stops.
13
The main flow of the inter-cores communication system is shown in Figure 5. The specific task programs will be covered later.
Figure 5 Main Flow of Inter-cores Communication System
14
2. Memory allocation task Because PPU allocates memory space for SPU, SPU has to ask PPU for help when memory
allocation is needed. Here we define memory allocation task type as 0x01. The SPU part of inter-cores communication system writes a 32-bit message into Write
Outbound Mailbox. This message is show as following. SPU then waits for PPU’s result.
SPU ID
Malloc Task Type
NA Size of Memory Space Needed(Bytes)
Figure 6 Structure of the First Message in Malloc Task When PPU part finds that the Write Outbound Mailbox is full, PPU stops the loop and gets
this message. It abstracts out the malloc task type and call the PPU specific malloc task program. The malloc program uses malloc_align to allocate memory with 128 bytes aligned. At last,
PPU part writes the original address of the memory space, transformed to an unsigned 32-bit integer from a pointer, into Read Inbound Mailbox.
SPU part gets the address and returns. PPU part finishes the task and continues looping.
3. Memory free task When all the modules finish, SPU should free all the memory space allocated in main
memory. The data to be freed has several data types , including packet, packet vector, etc. Similar as memory allocation, the SPU part first writes a 32-bit message into Write Outbound
Mailbox, then waits for PPU part gets it away. This message is shown as following.
SPU ID
Free Task Type
NA Data Type
Figure 7 Structure of the First Message in Free Task PPU part finds out this message and stops the loop. According to the free task type id as 0x2,
PPU part calls the specific free task program. After the first message has been taken, SPU part writes the 32-bit original address of the memory space to be freed, into Write Outbound Mailbox. After getting this address, the free task program uses free_align to free this memory space according to this address. If the data type is packet or packer vector, the free task program will first frees all the memory space indicated in packet or packet_vec structure, then the packet or packet_vec itself. If the task finishes successfully, PPU part returns 0 and goes on looping. SPU part gets the 0 result and returns.
4. Data dump task In debug and test modules, we have to check the data during process. These data is stored in
main memory so SPU has to inform PPU to dump them out. SPU part writes the first message into Write Outbound Mailbox. PPU part takes away this
information and calls dumping task program according to the dump task type id 0x3. This message
3bits 5bits 4bits 20bits
3bits 5bits 4bits
15
is shown as following.
SPU ID
Malloc Task Type
Data Type
Size of Memory Space Needed(Bytes)
Figure 8 Structure of the First Message in Dumping Task Then, SPU part transmits the 32-bit address of the data in main memory to PPU part. At last, SPU part transmits a message containing four determined chars as the dumping file name. PPU first creates a txt file with the four chars as its name. According to the data address, data type and data size, PPU dumps the specific data to that file using fprintf. If the task finishes successfully, PPU writes a 0 into Read Inbound Mailbox and continues looping. SPU part gets the success result and returns.
5. Channel Simulator Task During process, we have to simulator the packet of data through channel. However, the
channel simulator contains very complicated process and calculation with great large amount of data. It is impossible to run this module in SPU. Thus, we should realize this module in PPU.
SPU part transmits the first message to PPU part.
SPU ID
Free Task Type
NA
Figure 9 Structure of the First Message in Channel Simulator Task PPU calls channel simulator task program to deal with data. After SPU part passes some
messages containing necessary information to PPU part, this task program will call specific channel simulator program, including SISO, SIMO and MIMO modes..
When this module finishes, PPU part returns the address of the new packet of data for later use.
The detail of the channel simulator will be covered in Annex A. 6. Bit Error Rate Statistics Task After the process finishes, it’s necessary to count the bit error rate to check if the modules run
correctly. We compare a packet from a specific module in transmitter with another from the corresponding module in receiver. Because all the packets are stored in main memory, it is convenience to do such calculation in PPU. .
SPU part also transmits a 32-bit message to PPU part. This structure of this message is the same as that of the first message in channel simulator. PPU part receive this message and calls the bit error rate statistics task program according to task type 0x8.
Then, SPU part transmits two address of the two packets to PPU part. PPU part then counts the two packets and gets the bit error rate.
PPU part returns the rate to SPU part and this task ends.
3bits 5bits 4bits 20bits
3bits 5bits
16
7. Exit Task During inter-cores communication system, PPU part is continuously looping. If SPU program
exits without informing PPU part, PPU part program will be trapped in loop. Thus we should create a mechanism to tell PPU part to jump out of loop and end inter-cores communication system.
SPU part passes PPU part a 32-bit message containing SPU id and exit task type id 0x6, with the same structure as that of the first message in channel simulator task. PPU part checks the exit task type and replies SPU part. At last PPU part exits the loop and return to PPU main program.
SPU whole program exits after SPU part gets the response..
3.3.3 Vector Calculation and Operation Functions
Modules often deal with large amount of data considered as vectors. We have created a structure vec_t to stand for the vectors for convenience.We here design some new functions for calculattionoperation with vec_t. And It is much more convenience to deal with data pointer.
There are two main types of these functions. The first kind is vector calculation. And the other one is vector operation.
1. Vector Calculation Here are several kinds of calculation, two float vectors addition, two float vectors subtraction,
a float vector multiple with a scalar float, two complex vectors addition, two complex vectors subtraction, two complex vectors multiplication, a complex vector multiple with a scalar complex.
We use SIMD Intrinsic, such as spu_add, spu_sub, spu_shuffle and spu_madd etc, to raise calculation efficiency except multiple with scalar data.
2. Vector Operation We mainly need four types of operation, copy, selection, clear and catenation. The copy
operation copies a part of a vector to another specific vector. The selection operation selects a part of a vector to form a new vector. The clear operation clears all the data in the vector as 0. The catenation operation concatenates two vectors to a long vector.
All the function specification is shown in Annex A 4.3 Vector Calculation and Operation Functions.
3.4 Design of LTE Specific Modules
3.4.1 Main Flow of LTE
Here we begin to talk about the design of LTE specific modules. There a lot of modules and processes are very complex. The general LTE processes are shown as following figures. There are mainly three modes, SISO, SIMO and MIMO, in which MIMO has two situations.
17
Figure 10 Main Flow of LTE Downlink SISO Mode SISO mode has single transmitter antenna and single receiver antenna. In a single process, only a code word is transmitted. SIMO mode has single transmitter antenna and double receiver antennas. In a single process, only one code word is generated and transmitted. MIMO mode has double transmitter antennas and double receiver antennas. This mode has two situations. The one is single code word transmitted and the other is double code words transmitted. We choose different modes and module programs according to the modules simulator parameters.
18
Fi
gure 11 Main Flow of Downlink SIMO Mode
Figure 9 Main Flow of Downlink MIMO Mode with Single Code Word
19
Figure 12 Main Flow of Downlink MIMO with Double Code Words It can be seen from previous figures that the two modes, SIMO and MIMO, have the same basic functional blocks as SISO, but have more branches. And MIMO has a more module, precoding, between modulator and resource mapping. The main differences between three modes are inside LTE specific modules’ programs. The modules inside the transmitter and receiver are executed inside SPU, while the channel simulator runs in PPU.
However, because of HARQ mechanism, the design of actual flow may not be as easy as Figure 10 or Figure 12 shows. The noise introduced by channel simulator causes errors in data packets. Thus LTE process should retransmits the error packet through a more complex flow. The detail design of HARQ mechanism will be covered in HARQ program in Annex A 6.6 HARQ.
3.4.2 General Design of Specific Modules
Although functions of each modules are diverse, the general design of modules are similar expect channel simulator running in PPU.
1. General Definition of a Module Main Function In general, each module program has two function parameters. The general definition of a
module main program is shown as following. void module_name (ppu_addr ppu_addr_in_pkt, ppu_addr ppu_addr_out_pkt)
The ppu_addr_in_pkt is the ppu_addr in main memory of the packet from previous module. The ppu_addr_out_pkt is the allocated address in main memory of the packet which will be
20
generated later in this module program. When the SPU main program calls a specific module program, SPU main program will pass these two ppu_addr to this module program.
Some module programs may have more parameters. For example, some programs may need several previous packet addresses or new packet addresses. The detail of each module’s definition will be covered in Annex A.
2. General Flow of a Module At the beginning of each module, program initializes some buffers to contain data or packets.
The addresses of these buffers must be initialized with at least 32 bytes align, used to contain the packets and data conveyed from main memory through DMA.
Then, this program DMA the packet structure of the packet generated in the previous module into the inbound packet buffer, according to the parameter ppu_addr_in_pkt.This program abstracts parameters, such as data pointer, from the packet structure.
According to the previous data address, this module program DMA the data generated in the previous module into the inbound data buffer. The new generated data will be put into outbound data buffer after operation.
This module calls the SPU part of inter-cores communication system to allocate a memory space for the new data in main memory. The data in the outbound buffer will be DMAed to the allocated memory space.
At last, this module program creates a new packet structure packet to indicate the new data and puts it in outbound packet buffer. The p_spu_data, data_type, data_len and the pkt_para_t are changed according to the new generated data. Finally this program DMA the new packet from outbound buffer out to the address ppu_addr_out_pkt.
The general design of flow of modules can be shown as Figure 11. 3. Exceptions of Design If the HARQ module is realized as an Overlay segment like other modules, it will cause
segment fault while program running because HARQ may call other modules like segment and turbo encode. As a result, we realized the HARQ function in SPU main program.
The channel simulator module is completed in PPU. It doesn’t needto DMA the packet and data, but still needs the addresses of the packets and data.
21
Figure 13 General Flow of LTE Modules
22
3.4.3 Details of Modules Design
1. Initialization of Buffers We should define these buffers with at least 32 bytes alignment, because these buffers are
used to DMA data and packets. Otherwise, a DMA module of a buffer may cover the beginning part of the next buffer because of padding of the DMA data.
These buffers can be defined as following. buffer_example __attribute__((aligned(128)));
__attribute__((aligned(128))) here is designed to bring buffers 128 bytes alignment. However, SPU only supports a local variable with at most 16 bytes alignment at O2 optimization level, or at most 32 bytes alignment at O3 optimization level. But we still keep __attribute__((aligned(128))), not __attribute__((aligned(16))) or __attribute__((aligned(32))) in program codes. Because we hope to find a proper method to support 128 bytes alignment in SPU during further development, thus we can only improve DMA function program to achieve DMA top speed. 2. Limit size of Local Store
We meet limit size of local store again during modules design. All the packet data are stored in PPU main memory. The sum of input and output data in local
store can’t exceed 200KB while modules program running. We should segment the large amount of data into small blocks. Every time only a block is DMA in, dealt with, and DMA out, then the next block. 3. Details of Module Function
The specific design of module function will be covered in Annex A 6 Specific LTE Module.
4. Other Problems during Development 1. Problems of Alignment
The alignment problems have been covered in previous text. We make a conclusion here. Cell SDK documents tell that DMA reaches top speed when both the source address and
destination address are 128 bytes aligned and the data size should be multiple of 128 bytes. And when the size of the data to be transmitted is large then 16 bytes, this size must be multiple of 16 bytes if 128 bytes alignment could not be satisfied. However, SPU only supports at most 32 bytes aligned. Thus, we can’t pad data to multiple of 128 bytes, or it will cover the next buffer in local store and cause disasters.
As a result, we allocate memory space in PPU main memory with 128 bytes alignment. But we only pad DMA data to multiple of 16 bytes. In SPU program code, we define local variable with 128 bytes alignment. These variables are actually only 32 bytes aligned.
We keep writing 128 bytes alignment in SPU codes, not 32 bytes alignment, for later improvement. If a great method is found in later development to solve the small alignment in local store, we just need to change the padding size in DMA functions without changing the code in specific LTE module functions. 2. Global Parameters Configuration
Global parameters, such as debug configuration, simulator parameters, have to be set before program running. These parameters are written into a configure script and read by program. It is
23
easy to do such things in PPU with Linux system. However, SPU with only spu-gcc can’t realize such function so easily.
We use Expat to abstract parameters from script. Expat is an XML parser library written in C. The detailed content is available on http://expat.sourceforge.net/. We write parameters as an XML script. When PPU program begins, it uses Expat functions to get parameters from the script. Then, PPU starts SPU and passes these parameters to SPU with Mailbox and DMA’s help. The configuration parameters are set as following in the script. <!-- Correlation selection ranged in (1,2,3): low = 1, medium = 2, high = 3 --> <CHANNEL_CORRELATION>1</CHANNEL_CORRELATION>
The first line is the annotator. The elements inside the angle brackets are the global configuration parameters’ names. The characters between two angle brackets are the values of these parameters. The Expat function will abstract the parameters’ names and values out from the XML script.
We failed to compile Expat installation files with spu-gcc in SPU. Thus Expat can’t be used directly in SPU. We let PPU to pass the abstracted parameters to SPU. First, we use Mailbox to tell SPU the address of these parameters structures in main memory. Then, SPU starts DMA function to get these parameter structures according to these addresses.
Some details of Expat about this project will be covered in Annex A 2.2 Global Parameters Configuration.
5. Conclusion At the present stage of development, we only use a single SPU with Overlay. And we don’t
care about the efficiency of the total process running. Because of the lack of time, the algorithms of some LTE modules are not optimized.
In further development stage, the program will be designed with multiple SPUs and pipeline function on the base of single SPU. And the algorithms should be optimized according to the features of Cell platform, such as using SIMD and some other SPU intrinsic. Reducing the execution time of the LTE process should be considered as a most important target to check whether the project can meet the actual needs.
24
Reference [1] 3GPP TS 36.211 V8.5.0: “Physical channels and modulation”. [2] 3GPP TS 36.212 V8.5.0: “Multiplexing and channel coding”. [3] Fudan University DSPTLab Xinyue Guo, Hui Feng, Jiajun Jiang, Jun Ni, Qiben Yan,
“Design and Analysis of 3G Long-Term Evolution Physical Layer Baseband System” 2008-4 [4] Sheng Xu, Xing liu, Jiang Yu, Yi Ge, Cell/B.E. Processor Programming Guid, 2009-3 [5] IBM Cell Training Documents 2008
Annex A Function Specification
25
1 PPU Main Program File Directory: ppu_main.c General Description: PPU main program first reads and set global parameters. Then it initializes channel simulator parameters. Thirdly, a SPE thread is created, which the global parameters are passed to. After all the previous tasks done, PPU enters the loop of the PPU part functions of inter-cores communication system and wait for SPU’s requirement, until the SPU exits. After the SPE finishes and exits, PPU destroys the SPE thread and exits Function: int main (void);
2 Global Parameters and Configuration
2.1 Global Parameters File Directory: global General Description:
All the global parameters are defined in global.c and global.h. The global parameters will affect the behavior of each stage of LTE process. Specific Parameters:
typedef struct {
bool DEBUG_RESULT; bool DEBUG_STAGE; bool DEBUG_DUMP; bool DEBUG_PKT_RESULT;
}debug_para_t; This structure defines some global parameters which affect the debug level of each stage in
LTE process. Its members are described below. bool DEBUG_RESULT; This parameter indicates whether to show the results per every
packet or not, including whether the packet has passed the crc check , and the statistic results of the packet
bool DEBUG_STAGE; This parameter indicates whether to display the state of each packet during simulation or not, such as entering a function block or exiting
bool DEBUG_DUMP; This parameter indicates whether to record the results of every packet or not.
bool DEBUG_PKT_RESULT; This parameter indicates whether to record the results of every packet or not.
typedef struct {
unsigned int SNR_LEN;
26
uint32_t *SIM_COUNT; float *NOISE_POWER; enum working_mode_flag_t WORKING_MODE_FLAG; enum mod_type_t MOD_TYPE; enum num_sym_per_slot_t NUM_SYM; uint8_t NUM_PDCCH_SYM; uint8_t NUM_TX_ANTENNA; uint8_t NUM_RX_ANTENNA; uint8_t NUM_LAYER; uint8_t NUM_CW; uint16_t N_RNTI; uint16_t CELL_ID; uint16_t NUM_SUBCARRIER; enum chan_type_t CHANNEL_TYPE; enum chan_corr_t CHANNEL_CORRELATION; enum precode_mode_t PRECODE_MODE; double CODE_RATE;
}sim_para_t; This structure records some global parameter of simulation environment. Its members are
described below. unsigned int SNR_LEN; This parameter indicates the number of SNRs or the length of noise
power vector in the simulation uint32_t *SIM_COUNT; This parameter indicates the number of TTIs for each SNR in
simulation (positive integer) float *NOISE_POWER; This parameter indicates noise power vector in Walt units to run
through (positive real number) enum working_mode_flag_t WORKING_MODE_FLAG; This parameter indicates the
working mode selected. enum mod_type_t MOD_TYPE; This parameter indicates the modulation type selected. enum num_sym_per_slot_t NUM_SYM; This parameter indicates the number of symbols in
one slot, 6 or 7. uint8_t NUM_PDCCH_SYM; This parameter indicates the number of symbols used as
PDCCH in one subframe, 1,2, or 3. uint8_t NUM_TX_ANTENNA; This parameter indicates the number of transmission
antenna. uint8_t NUM_RX_ANTENNA; This parameter indicates the number of reception antenna. uint8_t NUM_LAYER; This parameter indicates the number of the layers used. uint8_t NUM_CW; This parameter indicates the number of the code words. uint16_t N_RNTI; This parameter indicates the radio network temporary identifier. uint16_t CELL_ID; This parameter indicates the physical layer cell identity. uint16_t NUM_SUBCARRIER; This parameter indicates the number of subcarriers used. enum chan_type_t CHANNEL_TYPE; This parameter indicates the model of channel. enum chan_corr_t CHANNEL_CORRELATION; This parameter indicates the correlation
27
between each channel path. enum precode_mode_t PRECODE_MODE; This parameter indicates the mode of precoding.
double CODE_RATE; This parameter indicates the code rate used in rate-matching module.
typedef struct {
enum harq_type_t HARQ_TYPE; uint8_t NUM_RETRY; uint8_t NUM_HARQ_CHANNEL;
}harq_para_t; This structure records some global parameters about HARQ module. Its members are
described below. enum harq_type_t HARQ_TYPE; This parameter indicates the HARQ type selected. uint8_t NUM_RETRY; This parameter indicates the max number of retransmission in
HARQ. uint8_t NUM_HARQ_CHANNEL; This parameter indicates the length of circular buffer list
in HARQ. ppu_addr harq_tx_buf_addr[MAX_CW]; This parameter is the pointer pointing to the current
HARQ transmission buffer in the buffer list of each code word. ppu_addr harq_rx_buf_addr[MAX_CW]; This parameter is the pointer pointing to the current
HARQ reception buffer in the buffer list of each code word. ACK_list_t ACK_list[MAX_CW]; This structure is the ACK/NACK signel list of each code
word.
uint8_t IDX_SUBFRAME; This parameter is the index of the current subframe.
2.2 Global Parameters Configuration
2.2.1 Configuration Script
We create a XML script called global.xml as the configuration script. A configuration parameter is set as following.
<!-- Correlation selection ranged in (1,2,3): low = 1, medium = 2, high = 3 --> <CHANNEL_CORRELATION>1</CHANNEL_CORRELATION>
The first line is the annotator. The elements inside the angle brackets are the global configuration parameters’ names. The characters between two angle brackets are the values of these parameters.
We just need to change the value of the parameters during simulator.
2.2.2 PPU Part
File Directory: lte_conf/ppu_conf
28
General Description: We abstract the global parameters out from the XML script with Expat tools and set these
parameters. After all the parameters are set, these parameters are transmitted to SPU through Mailbox and DMA functions. Functions:
int set_conf(void): This function gets the parameters value form that script and sets these parameters. After calling Expat function XML_ParserCreate to create a new parser object, this function calls XML_SetElementHandler to set handlers for start and end tags, which is used to judge the parameters’ names. Then, XML_SetCharacterDataHandler is called to set handler for text, in order to abstract out the specific values of the corresponding parameters and set this parameter. XML_Parse is responsible for the main task to pass the global.xml in buffer to the parser. The detail of the previous four Expat functions and other Expat information is available on http://www.xml.com/pub/a/1999/09/expat/index.html.
int trans_env_viriable(spe_context_ptr_t spe_id): This function tells SPU the addresses of the global configuration structures in main memory and wait for SPU to get them.
2.2.3 SPU Part
File Directory: lte_conf/spu_conf
General Description: SPU gets the addresses of the global parameters in main memory from PPU through Mailbox
and conveys these parameters into local store through DMA. Function: int get_para(uint8_t spu_id): this function starts several Mailbox transmission and DMA operation to complete this task.
3 Details of Some Structures
3.1 Packet Structures File Directory:
packet General Description:
This module defines the packet structure and provides some common operations for the packet structure. The packet, which is the fundamental processing unit, contains all the data and parameters needed in different stage of LTE process. There are two types of packets. One contains one block of data, and another contains several blocks of data. Structure Specification:
typedef struct{ uint8_t num_segment; /* the number of segments in the current packet, used for
freeing operation */ uint8_t num_cblock; /* the number of code blocks after segmentation */ uint8_t idx_retry; /* index of retransmission times */
uint8_t idx_rv; /* redundancy version needed by HARQ and rate-matching
29
module */ uint8_t idx_antenna; /*index of the antenna by which the packet is sent */ uint8_t idx_subframe; /*index of the subframe; */ uint8_t k0; /*k0 hoping frequency offset */ enum idx_cw_t idx_cw; /*index of code word */ int32_t id; /*the ID of the packet */ uint32_t rm_size; /*rate matching size for rate matching module */ uint8_t seg_filler_len; /*filler length in segmentation module */
uint8_t interl_filler_len[MAX_CBLOCK]; /*filler length for each code block in subblock interleaver module */
uint16_t turbo_f1[MAX_CBLOCK]; uint16_t turbo_f2[MAX_CBLOCK]; float snr_est; /*the SNR estimated in receiver. */ float signal_power; /*the signal power estimated in lte_estimator */ float N0; /*a parameter needed in the demodulator in uplink */
} pkt_para_t; This structure contains all the parameters companying with packets in different stages of LTE
process. It is noted that the parameter num_segment and num_cblock have different usages. The num_segment, indicating the number of data blocks of the current packet, is varied in various stages of LTE process, while the num_segment, indicating the number of code blocks after segmentation module, is consistent through the LTE process.
typedef struct{ ppu_addr data; uint32_t data_len; uint32_t data_type; pkt_para_t parameter;
} packet; This structure is the packet structure which just contains one single data block. The parameter,
data, is the pointer points to the data stored in the main memory space. The SPU of Cell processor can’t operate the main memory directly. Instead, the SPU gets the data by this pointer using DMA method. The parameter, data_len, indicates the length of data.
The parameter, data_type, indicates the type of data, including BIT IN BYTE, FLOAT, and COMPLEX.
The last item is the parameter structure defined above.
typedef struct{ ppu_addr data[MAX_CBLOCK]; uint32_t data_len[MAX_CBLOCK]; uint32_t data_type; pkt_para_t parameter;
} packet_vec;
30
This structure is the packet structure which contains several data blocks. The pointer array, data[], points to all the data blocks. The maximum number of blocks is
define by MAX_CBLOCK. The array, data_len[], indicates the length of each data block. The parameter, data_type, indicates the type of data, including BIT IN BYTE, FLOAT, and
COMPLEX. The last item is the parameter structure defined above.
Corresponding Functions: void pkt_para_copy(pkt_para_t *in_para, pkt_para_t *out_para); This function copies the
parameter of the input packet to that of the output packet. void print_pkt_para(pkt_para_t *pkt_para); This function prints the parameter of the packet. void print_pkt(packet *pkt); This function prints the content of packet structure. void print_pkt_vec(packet_vec *pkt); This function prints the content of packet_vec
structure.
3.2 Other Global Structures File Directory: lte_types.h General Description: This head file defines some data types and structures which are used frequently by almost every function. Structure Specification: #define BIT_IN_BYTE 1
#define FLOAT 4 #define COMPLEX 8 #define PACKET 9 #define PACKET_VEC 10 #define NONE 0
Here we define some common data types as a specific number for convenience.
enum idx_cw_t {cw0= 0, cw1 = 1}; used to indicate the index of code words. enum chan_type_t {awgn, epa5, eva5, eva70, etu70, etu300}; used to indicate the channel
type. enum chan_corr_t {low, medium, high}; used to indicate the correlation between each
channel path. #define ppu_addr uint32_t; This data type is defined to represent the 32-bit address in main memory.
typedef struct{
float real; float imagine;
}complex_t; This structure is defined to represent a complex number.
31
typedef struct { float noise_power; uint8_t n_taps; uint32_t delay[9]; complex_t impulse[4][14][9];
} chan_resp_t; This structure is defined to carry time impulse iNformation
typedef struct {
void *p_spu_data; uint8_t data_type; uint32_t data_len; //number of data
}vec_t; This structure is defined to represent a vector of a large amount of data.
4 Common Underlying Function
5.1 Wrapped DMA Function
5.1.1 DMA from Main Memory into Local Store
File Directory: lte_dma General Description:
These functions DMA the specific data from main memory into SPU local store. Functions:
int dma_in(void *p_spu_data, ppu_addr addr_ppu_data, uint32_t byte_size, uint8_t spu_id): This is the main DMA in function. The addr_ppu_data tells the address of the data in main memory. The pointer p_spu_data indicates the pointer to the address of the buffer in local store. The byte_size shows the number of bytes that needs DMA operation. And the spu_id is used to generate the specific DMA tag mask. spu_id is mainly designed for multiple SPUs use in later development. The dma_in function will calls two sub functions as following.
uint64_t single_dma_in_max(uint64_t addr_ppu_data, void **p_spu_data, uint8_t spu_id): This function calls mfc_get to DMA in data with 16KB size, which is the maximum data size that a single DMA operation mfc_get can afford. The addr_ppu_data, p_spu_data, spu_id have the same definitions as in dma_in function.
With multiple calls of the single_dma_in_max, dma_in can DMA in data more than 16KB once. However, the data size will not just be the multiple of 16KB. Then dma_in calls single_dma_in if there is left data less than 16KB after multiple single_dma_in_max operations.
int single_dma_in(uint32_t dma_size, uint64_t addr_ppu_data, void *p_spu_data, uint8_t spu_id): This function uses mfc_get to DMA in data with the specific data size dma_size. The dma_size is left data size less than 16KB. We pad the left data to multiples of 16 bytes as DMA operation asks for. The other parameters are the same as in previous functions.
32
5.1.2 DMA from Local Store out to Main Memory
File Directory: lte_dma
General Description: These functions DMA the specific data from local store to main memory. The DMA out
functions is similar as DMA in functions. Functions:
int dma_out(void *p_spu_data, ppu_addr addr_ppu_data, uint32_t byte_size, uint8_t spu_id): This is the main DMA out function. It also calls two sub functions.
uint64_t single_dma_out_max(uint64_t addr_ppu_data, void **p_spu_data, uint8_t spu_id): This function once conveys 16KB data with mfc_put.
int single_dma_out(uint32_t dma_size,uint64_t addr_ppu_data, void *p_spu_data, uint8_t spu_id): This function is designed to DMA out the left data less than 16KB with mfc_put. All the parameters in DMA out functions have the same definitions as in DMA in functions.
5.2 Inter-Cores Communication Functions (ICC Functions)
5.2.1 SPU Part
File Directory: lte_icc/spu/ General Description: These functions are responsible for communication with PPU part of ICC functions. The detail of the specific mechanism is covered in previous text. Data Structure:
typedef struct{ uint32_t addr_vector; uint32_t data_size; uint32_t data_type; char file_name[5];
} message; Functions:
ppu_addr spu_msg_malloc(uint8_t spu_id, message msg_inf): This function pass information got from structure msg_inf to PPU. After getting the allocated address in main memory from PPU, it returns this address and exits. The parameter spu_id is used for multiple SPUs use in later development. Here we define it as 0. The spu_id in SPU part following functions are the same.
uint32_t spu_msg_free(uint8_t spu_id, message msg_inf): This free function passes parameters to PPU to inform PPU to free the specific address in main memory.
uint32_t spu_msg_dump( uint8_t spu_id, message msg_inf): used to gives PPU parameters as designed in 3.3.2 and waits for the dump result.
uint32_t spu_msg_channel(uint8_t spu_id, ppu_addr in_pointer, float noise_power, ppu_addr out_pointer, ppu_addr chan_resp): This function passes these parameters to PPU for SISO mode channel simulator in PPU. The specification of these parameters is covered in channel_siso_spu.
uint32_t spu_msg_simo_channel(uint8_t spu_id, ppu_addr in_pointer, float noise_power, ppu_addr out_pointer_1st, ppu_addr out_pointer_2nd, ppu_addr chan_resp): This function passes
33
these parameters to PPU for SIMO mode channel simulator in PPU. The specification of these parameters is covered in channel_simo_spu.
uint32_t spu_msg_mimo_channel(uint8_t spu_id, ppu_addr in_pointer_1st, ppu_addr in_pointer_2nd, float noise_power, ppu_addr out_pointer_1st, ppu_addr out_pointer_2nd, ppu_addr chan_resp): This function passes these parameters to PPU for MIMO mode channel simulator in PPU. The specification of these parameters is covered in channel_mimo_spu.
float spu_msg_stat(uint8_t spu_id, ppu_addr in_pkt, ppu_addr out_pkt, uint8_t data_type,\ uint8_t ber_type): SPU calls this function to count the bit error rate between two given packets stored in PPU. The in_pkt and out_pkt separately define the addresses of the two packets in main memory. data_type shows the data type and ber_type indicates the two packets contain whether hard or soft information. This function passes these parameters to PPU and wait for the statistics result back from PPU.
uint32_t spu_msg_exit(uint8_t spu_id): This function informs PPU that SPU is going to exit. After getting the reply from PPU, SPU exits.
5.2.2 PPU Part
File Directory: lte_icc/ppu/ General Description: PPU Part of ICC functions reply to the requirement form SPU part functions. The detail mechanism has been covered in previous text. Functions:
int ppu_message(spe_context_ptr_t spe_id): the main function of PPU part. This function is used in PPU main program to continuously check the specific SPU write outbound mailbox according to the spe_id, until this mailbox is full. Then this function abstracts the task type number from the received message and calls the corresponding task sub function. And the main function passes that message and the spe_id to the task function. The specific task sub functions are shown as following.
int ppu_mesg_malloc(uint32_t rxed_message, spe_context_ptr_t spe_id); This task function works with spu_msg_malloc. It allocates memory space with 128 bytes alignment according to the information from SPU. At last, this function returns the memory space address to SPU.
int ppu_mesg_free(uint32_t rxed_message, spe_context_ptr_t spe_id): Cooperating with spu_msg_free, this task function frees all the corresponding memory space. Then it returns SPU a successful message.
int ppu_mesg_dump(uint32_t rxed_message, spe_context_ptr_t spe_id): Then, this function dumps the data indicated by spu_msg_dump out to the specific file.
int ppu_mesg_channel(spe_context_ptr_t spe_id): This function gets necessary information from the spu_msg_channel function. And then it calls channel simulator function in SISO mode. At last it returns the address of simulator result packet in main memory to SPU. The specific SISO mode channel simulator function is available in function channel_siso_ppu.
int ppu_mesg_simo_channel(spe_context_ptr_t spe_id): This function is similar to ppu_mesg_channel. However, spu_msg_simo_channel informs it to call channel simulator function in SIMO mode. The SIMO mode channel simulator function is covered in function channel_simo_ppu.
34
int ppu_mesg_mimo_channel(spe_context_ptr_t spe_id): Similar as previous two functions, this function gets necessary information from spu_msg_mimo_channel and calls MIMO mode channel simulator function channel_mimo_ppu.
int ppu_mesg_stat(uint32_t rxed_message, spe_context_ptr_t spe_id): This function gets necessary information from SPU spu_msg_stat function. It calls underlying statistics functions to count the bit-error-ratio between two got packets from corresponding modules on transmitter and receiver. At last it returns the statistics result to SPU. The statistics functions called will be covered in Annex A 4.4.
int ppu_mesg_exit(uint32_t rxed_message, spe_context_ptr_t spe_id): After this exit task function is called, it replies SPU that SPU can exit. Then, it returns ppu_message a message that SPU has exited. Thus, ppu_messege returns the PPU main program that SPU has finished its task. Then, PPU main program stops the ppu_message loop and begins to destroy SPU thread.
5.2.3 Encapsulating of SPU Part Functions
File Directory: lte_icc/icc/ General Description: In order to facilitate the program transplantation on other platform, we encapsulate SPU part functions. We actually use encapsulated SPU part functions in coding. Functions:
The encapsulated functions are shown as following. The parameters of each function are the same definition as original functions.
ppu_addr spu_malloc(uint8_t spu_id, message msg_inf); uint32_t spu_free(uint8_t spu_id, message msg_inf); uint32_t spu_dump(uint8_t spu_id, message msg_inf); uint32_t spu_channel(uint8_t spu_id, ppu_addr in_pointer, float noise_power, ppu_addr
out_pointer, ppu_addr chan_resp); uint32_t spu_simo_channel(uint8_t spu_id, ppu_addr in_pointer, float noise_power,
ppu_addr out_pointer_1st, ppu_addr out_pointer_2nd, ppu_addr chan_resp); uint32_t spu_mimo_channel(uint8_t spu_id, ppu_addr in_pointer_1st, ppu_addr
in_pointer_2nd, float noise_power, ppu_addr out_pointer_1st, ppu_addr out_pointer_2nd, ppu_addr chan_resp);
float spu_stat(uint8_t spu_id, ppu_addr in_pkt, ppu_addr out_pkt, uint8_t data_type, uint8_t ber_type);
uint32_t spu_exit(uint8_t spu_id, message msg_inf);
5.3 Vector Calculation and Operation Functions File Directory: vector_calc
5.3.1 Vector Calculation
General Description: The following functions are designed to perform vector calculation operation. These operations infer to vectors add, sub, multiple with a scalar, multiple with another vector, etc. Most
35
of the functions use SIMD intrinsic to improve operation speed. Functions:
int vector_float_add(vec_t *vector_aug, vec_t *vector_addend, vec_t *vector_result): Every element of the float addend vector is added to the corresponding element of float summand vector and the float sum vector is put to the specific address indicated by pointer vector_result. The pointer vector_aug is the address of vec_t indicating summand vector and the vector_addend specifies the addend vector. Here we use SPU arithmetic intrinsic spu_add.
int vector_float_sub(vec_t *vector_minuend, vec_t *vector_suber, vec_t *vector_result): Every element of the float subtrahend vector indicated by vector_suber is subtracted from the corresponding element of the float minuend vector indicated by vector_minuend. And the float result vector is return to vec_t pointer vector_result. SPU arithmetic intrinsic spu_sub is used.
int vector_float_mscaler(vec_t *vector_multand, float multer, vec_t *vector_result): Every element of the float multiplicand vector indicated by vector_multand is multiplied by the scalar float multiplier multer. And the float result vector is return to vec_t pointer vector_result. In this function we don’t use any SPU SIMD intrinsic.
int vector_complex_add(vec_t *vector_aug, vec_t *vector_addend, vec_t *vector_result): Every element of the complex addend vector indicated by vector_addend is added to the corresponding element of the complex summand vector indicated by vector_aug. The result vector is return to vec_t pointer vector_result. The SPU arithmetic intrinsic spu_add is used.
Here the complex element is the structure complex_t. And all the complex elements in later vector calculation and operation functions are defined as complex_t.
int vector_complex_sub(vec_t *vector_minuend, vec_t *vector_suber, vec_t *vector_result): Every element of the complex subtrahend vector indicated by vector_suber is subtracted from the corresponding element of the complex minuend vector indicated by vector_minuend. And the complex result vector is return to vector_result. SPU arithmetic intrinsic spu_sub is used.
int vector_complex_mult(vec_t *vector_multand, vec_t *vector_multer, vec_t *vector_result): Every element of the complex multiplicand vector indicated by vector_multand is multiplied by the corresponding elements of the complex multiplier vector indicated by vector_multer. And the complex result vector is return to vector_result. The two complex vectors multiplication algorithm is from IBM Cell Training documents “Day1-09 Hands on SIMD SDK30”.
int vector_complex_mscaler(vec_t *vector_multand, complex_t multer, vec_t *vector_result): Every element of the complex multiplicand vector indicated by vector_multand is multiplied by the scalar complex multiplier multer. And the complex result vector is return to vector_result. In this function we don’t use any SPU SIMD intrinsic.
5.3.2 Vector Operation Functions
General Description: These functions are designed to bring convenience while performing vector operations. Functions:
vec_t define_vector(void *vector, uint8_t data_type, uint32_t data_len): A vector structure is defined and valued by this function. The three elements of a vec_t, p_spu_data, data_type and data_len are separately valued as three parameters of this function, vector, data_type and data_len. The new generated vec_t is returned.
36
int vector_int8_set(int8_t data, vec_t *vector_result): All the elements of the 8 bit integer vector in the address vector_result are set as the parameter data.
vec_t vector_sel(vec_t *vector_seled, uint32_t index, uint32_t length): A part of the specific vector indicated by the vec_t pointer vector_seled is selected out to form a new vector. The length indicates the number of elements selected and the index shows the beginning element. This function returns a new vec_t indicating the new generated vector.
int vector_copy(vec_t *vector_src, uint32_t index, uint32_t length, vec_t *vector_dest): A part of the vector represented by vector_src is copied to the vector specified by vector_dest. The length indicates the number of elements copied and the index shows the beginning element.
int vector_cat(vec_t *vector_one, vec_t *vector_two, vec_t *vector_result): The two vectors specified by vector_one and vector_two are concatenated into a longer result vector. And vector_result is valued to indicate this result vector. In this new result vector, the data of vector_one is followed by that of vector_two.
int vector_zero(vec_t vector_dest): All the elements in the vector indicated by vector_dest are set as 0.
5.4 Underlying Statistics Functions File Directory: lte_stat General Description: These functions are used to calculate the bit-error-ratio between two packets or SNR of a specific packet. These functions are all specially designed as underlying functions because they need to be compiled and called both in PPU and SPU programs. PPU part statistics task function of ICC system will call these functions while SPU statistics functions to be covered later will also call them to perform corresponding statistics operations. Functions:
float packet_ber(packet *p_in_pkt, packet *p_out_pkt): used to calculate the ber between the data of two correlative packets.
float packet_vec_ber(packet_vec *p_in_pkt, packet_vec *p_out_pkt): used to calculate the ber between the data of two correlative packet vectors.
float packet_soft_ber(packet *p_in_pkt, packet *p_out_pkt); used to calculate the ber between the data of two correlative packets, while the data of the packet in address p_out_pkt contains soft information.
float packetvec_soft_ber(packet_vec *p_in_pkt, packet_vec *p_out_pkt): used to calculate the ber between the data of two correlative packet vectors, while the data of the packet vectors in address p_out_pkt contains soft information.
float packet_snr_stat(packet *p_pkt): this function gets the SNR of the packet float packetvec_snr_stat(packet_vec *p_pkt): this function gets the SNR of the packet vector
5 SPU Main Program File Directory:
lte_process
5.1 Main Program
37
File directory: lte_main.c General Description:
This program is the main process of LTE simulation platform. It determines the processing order of each module of LTE process. It also prepares all the packets needed by each module. Function:
The entry of the LTE simulation platform is the function below: int main(void)
This function calls SPU configuration functions to get global parameters, firstly. Then, it enters into different modules according to the working mode selected in the configuration script.
Working mode supported in this version of LTE simulation platform will be described below. The uplink process isn’t supported right now
5.2 Specific Modules for Diverse Working Modes
5.2.1 Downlink SISO
File directory: lte_process_dl_siso.c General description:
This block determines the processing order of each module in the downlink simulator that sets one antenna at both the transmitter and receiver. Main function:
void lte_process_dl_siso();This is the LTE main process of SISO mode in downlink. Sub function:
void malloc_pkt_dl_siso(allpkt_dl_siso_t *allpkt); This function malloc all the packets needed by the following module.
void free_pkt_dl_siso(allpkt_dl_siso_t *allpkt, enum ACK_flag_t pre_ACK_flag); This function frees all the packets used.
5.2.2 Downlink SIMO
File directory: lte_process_dl_simo.c General description:
This block determines the processing order of each block in the downlink simulator that sets one antenna at transmitter and two at receiver. Main function:
void lte_process_dl_simo();This is the LTE main module of SIMO mode in downlink Sub functions:
void malloc_pkt_dl_simo(allpkt_dl_simo_t *allpkt); This function malloc all the packets needed by the following module.
void free_pkt_dl_simo(allpkt_dl_simo_t *allpkt, enum ACK_flag_t pre_ACK_flag); This function frees all the packets used.
5.2.3 Downlink MIMO with Single Word
38
File directory: lte_process_dl_mimo_sw.c General description:
This block determines the processing order of each block in the downlink simulator that sets two antennas at both the transmitter and receiver, and transmits single codeword per subframe. Main function:
void lte_process_dl_mimo_sw(); This is the LTE main process of MIMO mode with single codeword in downlink Sub functions:
void malloc_pkt_dl_mimo_sw(allpkt_dl_mimo_sw_t *allpkt); This function malloc all the packets needed by the following module.
void free_pkt_dl_mimo_sw(allpkt_dl_mimo_sw_t *allpkt, enum ACK_flag_t pre_ACK_flag); This function frees all the packets used.
5.2.4 Downlink MIMO with Double Words
File directory: lte_process_dl_mimo_dw.c General description:
This block determines the processing order of each block in the downlink simulator that sets two antennas at both the transmitter and receiver, and transmits double codewords per subframe. Main function:
void lte_process_dl_mimo_dw();This is the LTE main module of MIMO mode with double codewords in downlink. Sub functions:
void malloc_pkt_dl_mimo_dw(allpkt_dl_mimo_sw_t *allpkt); This function malloc all the packets needed by the following module.
void free_pkt_dl_mimo_dw(allpkt_dl_mimo_sw_t *allpkt, enum ACK_flag_t pre_ACK_flag); This function frees all the packets used.
6 LTE Specific Modules
6.1 Packet Generator File Directory:
lte_generator General Description: This block is used to generate the original data packet for each TTI from the source. The corresponding packet format information is also added in the packet according to the configuration. Functions: void gen_packet(uint8_t idx_subframe, enum idx_cw_t idx_cword, ppu_addr out); used to generate new source packet. idx_cword is used to denote the index of codeword in the simulation, and idx_subframe denotes the index of the packet in a frame. A frame contains 10 subframes. void init_lte_generator(); used to initiate the ID of the packet to 0 at the beginning of each simulation.
39
6.2 CRC Encoder/Decoder File Directory:
lte_crc
6.2.1 CRC Encoder Module
General Description: The 1st Cyclic Redundancy Check (CRC) attachment is provided to the data of the packet
from generate module. Functions:
void tx_crc(ppu_addr pkt_in, ppu_addr pkt_out): the main function. The address of this packet stored in main memory is pkt_in. After this CRC attachment is finished, a new packet, containing information of the CRC result data, is DMAed out to address pkt_out in main memory.
void crc_enc(int8_t *in_data, uint32_t data_len, uint8_t crc_type); used to perform specific attachment operation. crc_type decides whether this attachment is in CRC encoder or Segment module, because both CRC encoder and Segment module call this sub function with different cyclic generator polynomials. In CRC encoder module, we value crc_type as CRC_CODE_1ST, which means the 1st CRC attachment operation through the whole process.
6.2.2 CRC Decoder Module
General Description: Error detection is provided through the CRC calculation.
Functions: bool rx_crc(ppu_addr pkt_in, ppu_addr pkt_out); the main function. The entire data,
indicated by the packet structure stored in pkt_in, is used to check CRC parity bits. If the CRC result is right, this function returns bool true. Otherwise, it returns bool false. At last, it generates new packet to indicate result data and DMAs this packet to address pkt_out in main memory. bool crc_dec(int8_t *in_data, uint32_t data_len, uint8_t crc_type); used to perform specific CRC operation. The crc_type is similar as in CRC encoder function.
6.3 Code Block Segmentation and Code Block CRC Attachment File Directory:
lte_segment
6.3.1 Segmentation and CRC attachment on tranismitter
General Description: The entire data from CRC encoder is divided into several blocks. Then, all the blocks are
attached with CRC parity bits. Functions:
void tx_seg_turboenc(ppu_addr pkt_in, ppu_addr pkt_out): used to divided the entire data int o blocks in specific size. The CRC calculation operation is completed by calling crc_enc with crc_type defined as CRC_CODE_2ND.
6.3.2 Code Block Concatenation and CRC on receiver
40
General Description: Error detection is given to all the data blocks indicated by the packet_vec stored in pkt_in through CRC. Then these blocks are concatenated into entire data. Functions:
bool rx_con_turbodec(ppu_addr pkt_in, ppu_addr pkt_out): used to concatenate these blocks. crc_dec is called to finish CRC with crc_type defined as CRC_CODE_2ND. If any of these blocks are found wrong, this function returns bool false. Otherwise, it returns true.
6.4 Turbo Encoder/Decoder File Directory:
lte_turbo General Description:
Code blocks are delivered to the channel coding block, which is turbo coding according to TS 36.212. The turbo coding scheme is adopted in downlink shared channel. The turbo coder is a Parallel Concatenated Convolutional Code (PCCC) with two 8-state constituent encoders and one turbo internal interleaver according to TS 36.212. The code rate of turbo encoder is 1/3 and the output consists of the system codes and two output parity codes of the RSC encoders. Meanwhile in the receiver end, a max-log-map algorithm is used for iterative decoding, Functions declared in lte_turbo.h:
void tx_turbo(ppu_addr in, ppu_addr out); used to encode several code blocks in the packet. void rx_turbo(ppu_addr in, ppu_addr out); used to decode the code blocks in the packet. void turbo_interleave(vec_t *input, uint16_t f1, uint16_t f2, vec_t *output); used to interleave the data per code block. f1 and f2 are generated according to Table 5.1.3-3 in TS 36.212.8.5.0. The type of the input and output is 8-bit fixed point. Functions not declared in lte_turbo.h, used in this block only: void _rsc_encode(vec_t *sys_code_p, vec_t *parity_code_p, int8_t *trellis_code); used to encode RSC code. sys_code_p is the input, while parity_code_p and trellis_code is the output.
void _multiplex_in_turboenc(vec_t *sysc_1st_vec, vec_t *parc_1st_vec, vec_t *parc_2nd_vec, int8_t *trellis_code_1st, int8_t *trellis_code_2nd, uint8_t filler_len, vec_t *output_vec); used to multiplex the three data streams, which are the system code and the output parity codes of the two RSC encoder respectively.
void _demultiplex_in_turbodec(vec_t *received_data_p, vec_t *sysc_1st_vec_p, vec_t *sysc_2nd_vec_p, vec_t *parc_1st_vec_p, vec_t *parc_2nd_vec_p, uint8_t filler_len, uint16_t f1, uint16_t f2, uint8_t seg_idx); the reverse operation of _multiplex_in_turboenc. Separate the input data stream into three parts: system code sysc_1st_vec_p and two parity codes, parc_1st_vec_p and parc_2nd_vec_p. And sysc_2nd_vec_p is just the output of reverse interleaver operation of parc_2nd_vec_p. void _interleaver_in_turbodec(vec_t *input, uint16_t f1, uint16_t f2, vec_t *output); used to interleave the data per code block. Differ from the function declared in lte_turbo.h because of the type of the data is float.
void _deinterleaver_in_turbodec(vec_t *input, uint16_t f1, uint16_t f2, vec_t *output); the reverse operation of _interleaver_in_turbodec. The type of the data is float. void _max_log_map_dec(vec_t *sys_code_vec_p, vec_t *parity_vec_p, vec_t *la_vec_p, vec_t *le_vec_p); used to decode the RSC code using MAX-LOGMAP algorithm. The input
41
la_vec_p is the prior probability of the data, while the output le_vec_p is the posterior probability. In turbo decoder, the posterior probability is used as the prior probability of the other RSC decoder. void _hard_decision(vec_t *sys_code_vec_p, vec_t *le1_vec_p, vec_t *la1_vec_p, uint16_t f1, uint16_t f2, vec_t *output_vec_p); used to transform the probability of each data to hard bit, i.e. 0 or 1. And a deinterleaver is used in it. int8_t _f2i(float in); transform the data from float to fixed point, considering overflow and infinity. float _i2f(int8_t in); transform the data from fixed point to float, considering overflow and infinity. float _scale(float *beta_tmp); scale the 1x8 vector to fixed point data and return the scale. float _descale(float *scale_vec, uint8_t beta_value, uint32_t col_idx); reverse operation of _scale.
float com_log(float a, float b); the algorithm to calculate log(exp(a)+exp(b)), when in MAX-LOG-MAP, it equals to max(a, b).
uint32_t _intl_idx(uint32_t idx_in, uint32_t data_len, uint16_t f1, uint16_t f2); the algorithm to calculate the index after interleaver.
6.5 Interleaver/Deinterleaver File Directory:
lte_interleaver General Description:
This module performs sub-block interleaving and deinterleaving. Code blocks after turbo encoding is then interleaved separately so that the transmit data can be randomize before later rate-matching module. Correspondingly, on the receiver end, the de-interleaving module should be performed in order to regain the original data. The channel interleaving algorithm which is only for uplink channel is not included in source codes of this version. Main functions:
void interleaver(ppu_addr in_pkt,ppu_addr out_pkt); This function performs interleaving after turbo encoding.
void deinterleaver(ppu_addr in_pkt, ppu_addr out_pkt); This function performs deinterleaving before turbo decoding. Sub functions:
uint32_t interleaver_subblock(int8_t *out_data_buf, int8_t *in_data_buf, uint32_t in_data_len); This function performs interleaving for three sub-blocks in each code block and returns the filler length.
uint32_t deinterleaver_subblock(int8_t *out_data_buf, int8_t *in_data_buf, uint32_t in_data_len, uint32_t filler_len); This function performs deinterleaving for three sub-blocks in each code block and returns the output data length.
void interleaver_map_first(uint16_t *inter_pattern, uint32_t pattern_len); This function generates the interleaver permutation pattern of first type.
void interleaver_map_second(uint16_t *inter_pattern, uint32_t pattern_len); This function generates the interleaver permutation pattern of second type.
6.6 HARQ
42
File Directory: harq, lte_process
General Description: This module performs the rate matching module and retransmitting module with feedback information including packet scheduling in transmitter, together with HARQ combination module and rate de-matching module in receiver.
The rate matching module is used to match the number of input bits in one TTI to a consistent number which is required in the following stages. The rate de-matching module is the reverse operation of rate-matching module. The rate matching module is accomplished according to protocol 3GPP TS 36.212 v8.3.0.
According to the feedback information, the HARQ module operates the HARQ buffer and determines whether to generate a new packet or not. Two types of HARQ, Chase Combining (CC) and Incremental Redundancy (IR), are supported in company with no HARQ type in this version of source codes. The retransmitted packet generated by rate matching module may be different from the original packet if the HARQ IR type is chosen. Therefore, The HARQ transmission buffer is placed before the rate-matching module. The HARQ combination module is used to combine the retransmitted block with the original stored block using maximum ratio combination mode to provide extra gain for turbo decoding. Data Structures:
typedef struct{ uint8_t harq_channel;
ppu_addr pkt_addr; /* the ppu address pointing to the current packet in transmission buffer*/
ppu_addr src_pkt_addr; /* the ppu address pointing to the source packet for statistic */
ppu_addr turbo_pkt_addr; /* the ppu address pointing to the packet after turbo encoding for statistic */
ppu_addr next_buf_addr; /* the ppu address pointing to the next transmittion buffer */
} harq_tx_buf_t; This structure defines the HARQ transmission circular buffer. The pointer next_buf_addr
points to the the next harq buffer and all these buffers forms a circular list in which the tail’s pointer points to the head.
typedef struct{
uint8_t harq_channel; ppu_addr pkt_addr; /* the ppu address pointing to the current packet in
reception buffer */ ppu_addr mask_pkt_addr; ppu_addr next_buf_addr; /* the ppu address pointing to the next reception buffer */
} harq_rx_buf_t; This structure defines the HARQ reception circular buffer. The pointer next_buf_addr points
to the the next harq buffer and all these buffers forms a circular list in which the tail’s pointer points to the head.
43
enum ACK_flag_t {ACK = 0, NACK =1};
typedef struct{
enum ACK_flag_t flag[MAX_ACK_FLAG];/* 0 denotes ACK, and 1 denotes NACK*/ uint8_t num_ACK_flag;
} ACK_list_t; This structure defines the ACK/NACK signal list. An array flag[] is used as the signal list and
the maximum length is defined by MAX_ACK_FLAG. The real length of the signal list is described by num_ACK_flag. Main functions:
Main Functions under harq Folder: void new_harq_buf(uint8_t num_harq_process, uint8_t num_cw); This function initiates the
harq transmission and reception buffer, and ACK/NACK signal lists. void delete_harq_buf();This function delete the harq transmission and reception buffer. ppu_addr new_ratem_info();This function prepares new space in main memory for the
structure of ratem_info_t which records the locations of pruned bits. It returns the address of main memory.
void rate_matching(ppu_addr in_pkt, ppu_addr out_pkt, ppu_addr ratem_info_p); This function performs rate matching module.
void rate_dematching(ppu_addr in_pkt, ppu_addr out_pkt, ppu_addr ratem_info_p, ppu_addr mask_pkt); This function performs rate dematching module.
Main Functions under lte_process Folder: enum ACK_flag_t harq_tx_process(ppu_addr *src2txcrc_pkt, ppu_addr txcrc2txseg_pkt,
ppu_addr txseg2txturbo_pkt, ppu_addr *txturbo2interl_pkt, ppu_addr *interl2ratemat_pkt, enum idx_cw_t idx_cw); This function performs the main HARQ transmission module and returns the ACK/NACK signal.
void harq_rx_process(ppu_addr ratedemat2deinterl_pkt, ppu_addr deinterl2rxturbo_pkt, ppu_addr rxturbo2rxcon_pkt, ppu_addr rxcon2rxcrc_pkt, ppu_addr rxcrc_out_pkt, ppu_addr mask_pkt, enum idx_cw_t idx_cw); This function performs the main HARQ reception module with HARQ combination algorithm.. Sub Functions:
void put_pkt_into_txbuf(ppu_addr src_pkt, ppu_addr turbo_pkt, ppu_addr in_pkt, enum idx_cw_t idx_cw); This function adds a new packet into the harq transmission buffer and deletes the old one.
void get_pkt_from_txbuf(ppu_addr *src_pkt, ppu_addr *turbo_pkt, ppu_addr *out_pkt, enum idx_cw_t idx_cw, uint8_t idx_subframe); This function gets a retransmitted packet from the harq transmission buffer.
void combination_CC(ppu_addr cur_pkt); This function realizes the combination algorithm for CC-type HARQ.
void combination_IR(ppu_addr cur_pkt, ppu_addr cur_mask_pkt); This function realizes the combination algorithm for IR-type HARQ.
void operate_ACK_list(enum ACK_flag_t ACK_flag, enum idx_cw_t idx_cw); This function adds a new signal to the ACK/NACK signal lists and deletes the eldest one.
44
void print_harq_buf(uint8_t num_harq_process); This function prints the context of the harq buffer for debug.
int8_t * rate_matching_subblock(int8_t *in_data_buf, int8_t *out_data_buf, packet_vec *in_pkt_buf, ratem_info_t *ratem_info_p, uint32_t idx_cblock); This function performs rate matching module for each code block.
int8_t * rate_dematching_subblock(int8_t *in_data_buf, int8_t *out_data_buf, int8_t *mask_bit_buf, packet *in_pkt_buf, ratem_info_t *ratem_info_p, uint32_t idx_cblock); This function performs rate dematching module for each code block.
6.7 Scramble File Directory:
lte_scramble General Description:
This module performs scrambling and de-scrambling module. In transmitter the input bits are scrambled to be random for the convenience to do signal processing in the following stage. The scramble code, also named PN sequence, is a binary pseudorandom sequence generated by a linear feedback shift register. The scrambled bits are achieved by doing exclusive or (xor) operation to the input bit stream with the PN sequence bit by bit.
In receiver this module performs the reverse operation of scrambler module. The descrambled bits are also achieved by doing exclusive or (xor) operation to the input bit stream with the PN sequence bit by bit. Main functions:
void scrambler(ppu_addr in_pkt, ppu_addr out_pkt); This function performs scrambling module after rate-matching module.
void descrambler(ppu_addr in_pkt, ppu_addr out_pkt); This function performs soft descrambling module before rate de-matching module. Sub functions:
void scrambler_subblock(int8_t *out_data_buf, int8_t *in_data_buf, int8_t *X1_buf, int8_t *X2_buf, uint32_t length); This function performs scrambling for each segmentation. Since the size of packet data is too large for the SPU local memory, the packet data are scrambled segment by segment.
void descrambler_subblock_soft (int8_t *out_data_buf, int8_t *in_data_buf, int8_t *X1_buf, int8_t *X2_buf, uint32_t length); This function performs soft descrambler for each segmentation since the bits are soft bits.
6.8 Modulator/Demodulator File Directory:
lte_modulator
6.8.1 Modulation Module
General Description: This module modulates the binary bits into complex_t symbols according to the constellation.
45
The main function is shown as following. Functions:
void modulator(ppu_addr in_pkt, ppu_addr out_pkt): the main function which calls the two following sub functions are called to perform the specific modulation operation.
ppu_addr modulator_mapping(packet *in_pkt, int8_t *p_data, enum mod_type_t modulator_type): used to convey data and assign buffers and pointers. The modulator_type decides whether QPSK or QAM16 or QAM64 is used.
int mapping_function(int8_t *p_map_data, ppu_addr addr_map_out, uint32_t map_data_size, enum mod_type_t modulator_type): called to perform specific modulation operation.
6.8.2 Demodulation Module
General Description: This module demodulates the complex_t symbols into 8-bit signed integers using soft
demodulation. There are two steps. The first one is soft demodulation. The complex_t symbols are demodulated to float number to represent each bit according to the distances inside constellation. Second, because SPU local store can’t afford turbo decode module enough resource to deal with float data, the second step is to quantify and transform float data to 8-bit signed integer data. Functions: void demodulator(ppu_addr in_pkt, ppu_addr out_pkt, ppu_addr in_channel_pkt): The main function. The packet indicating channel gain data is from in_channel_pkt.
float demodulator_mapping(float *p_in_data, ppu_addr out_addr, uint32_t data_size, enum mod_type_t modulator_type, float noise, float *p_channel_data): used to perform soft demodulation from complex_t to float data
ppu_addr quanti_int(packet *in_pkt_buffer, float *in_data_buffer, ppu_addr addr_out_data, int8_t *scale_data, float scale_max): used to perform quantify and transform float data to 8-bit signed integer data.
6.9 Precoding File Description:
lte_precode General Description:
This module finishes two tasks. First is the layer mapping. The complex-valued modulation symbols for each of the code words to be transmitted are mapped onto one or several layers. Second is the real precoding module. The data vectors from layer mapping are mapped onto resources on each of the antenna ports. There are three modes now in precoding, precoding for transmission a single antenna port, precoding for spatial multiplexing without CDD and precoding for spatial multiplexing with large CDD. Data Structure:
We create a new structure precode_struct to receive the addresses of packets from modulation, because the number of addresses is diverse according to different simulator working mode.
typedef struct {
46
ppu_addr in_packet_cw1; /* address of the first code word packet */ ppu_addr in_packet_cw2; /* address of the seconde code word packet */ ppu_addr out_packet_ap1; /* address of the packet on the first antenna port*/ ppu_addr out_packet_ap2; /* address of the packet on the second antenna port */
}precode_struct; Functions:
int8_t lte_precode(precode_struct *packet_addr): This function is the main function of the precoding module. According to the precoding mode selected in the global configuration, the main function calls one sub function from the following three to finish this module.
int8_t precode_single_ap(precode_struct *packet_addr): used in a single antenna port mode. int8_t precode_no_cdd(precode_struct *packet_addr): used in the mode for spatial
multiplexing without CDD. int8_t precode_large_cdd(precode_struct *packet_addr): used in the mode for spatial
multiplexing with large CDD.
6.10 Resource Element Mapper File Description:
lte_RE_mapper General Description:
This module performs resource element mapping and demapping after layer mapping and precoding, according to the protocol 3GPP TS 36.212 v8.3.0. It maps different physical channels and signals to resource elements in one subframe.
In mapping module, the reference signals and synchronization signals and PDSCH, PCFICH, PHICH, PDCCH, PBCH are simultaneously mapped to different resource elements in one subframe. The data after precoding are put in PDSCH. In the receiver, the PDSCH data are abstracted by demapping module and transported to next stage. Simulation on PDSCH can be performed on this platform, while other physical channels are filled with PN data. Simulation on PDCCH is not included in this version of C++ code.
According to the number of transmission antennas, there are two types of Resource Element Mapper, one for one antenna, and another for two antennas. Main functions:
ppu_addr new_mapper_pattern();This function prepares new space in main memory for the resource element mapper pattern and returns the address of main memory.
void RE_mapper_dl_siso(ppu_addr in_pkt, ppu_addr out_pkt, ppu_addr mapper_pattern, ppu_addr QPSK_sym); This function performs the main process of resource element mapping in cases of one transmission antenna in downlink.
void RE_mapper_dl_mimo(ppu_addr in_pkt, ppu_addr out_pkt, ppu_addr mapper_pattern, ppu_addr QPSK_sym, uint8_t idx_tx_antenna); This function performs the main process of resource element mapping in cases of two transmission antennas in downlink.
void RE_demapper_dl(ppu_addr in_pkt, ppu_addr out_pkt, ppu_addr mapper_pattern_addr); This function performs the main process of resource element demapping in downlink. Sub functions:
void set_mapper_para(mapper_para_t *mapper_para, uint32_t idx_antenna, uint32_t
47
idx_subframe, uint32_t num_subcarrier, uint32_t num_sym, uint32_t num_PDCCH_sym, uint32_t cell_ID); This function sets the context of structure mapper_para_t.
void mapping_ref_sig_siso(complex_t *out_data_buf, mapper_para_t mapper_para); This function maps the reference signals to resource element grid in cases of one transmission antenna in downlink.
void mapping_ref_sig_mimo(complex_t *out_data_buf, mapper_para_t mapper_para); This function maps the reference signals to resource element grid in cases of two transmission antennas in downlink.
void mapping_sync_sig_siso(complex_t *out_data_buf, mapper_para_t mapper_para, dl_sync_t *dl_sync); This function maps the primary and secondary synchronization signals to resource element grid in cases of one transmission antenna in downlink.
void mapping_sync_sig_mimo(complex_t *out_data_buf, mapper_para_t mapper_para, dl_sync_t *dl_sync); This function maps the primary and secondary synchronization signals to resource element grid in cases of two transmission antennas in downlink.
void mapping_PDCCH(complex_t *out_data_buf, mapper_para_t mapper_para, ppu_addr QPSK_sym); This function maps PDCCH (physical downlink control channel) to resource element grid in downlink.
void mapping_PBCH(complex_t *out_data_buf, mapper_para_t mapper_para, ppu_addr QPSK_sym); This function maps PBCH (physical broadcast channel) to resource element grid in downlink.
void mapping_PDSCH(complex_t *out_data_buf, packet *in_pkt_buf); This function maps PDSCH (physical downlink share channel) to resource element grid in downlink.
uint32_t demapping_PDSCH(complex_t *out_data_buf, packet_vec *in_pkt_buf, ppu_addr mapper_pattern_addr); This function abstracts the data of PDSCH (physical downlink share channel) from resource element grid in downlink and return the output data length.
void generate_ref_seq_dl ( complex_t *dl_ref_seq, uint32_t idx_slot, uint32_t idx_sym, uint32_t cell_ID, uint32_t isNormal_CP ); This function generates reference signals for each symbol according to the input parameter.
void generate_ps_seq (int8_t *ps_seq, int8_t *C_init, uint32_t length ); This function generates a m-sequence. which is used for generating PN-data for PDCCH and PBCH.
void generate_dl_sync_pri(complex_t *dl_sync_pri, uint32_t inN_ID_2); This function generates the primary synchronization signals. Please make sure that the length of dl_sync_pri array is equal or greater than 72.
void generate_dl_sync_sec(complex_t *dl_sync_sec0, complex_t *dl_sync_sec1, uint32_t inN_ID_1, uint32_t inN_ID_2); This function generates the secondary synchronization signals. Please make sure that the length of dl_sync_sec array is equal or greater than 72.
uint32_t get_data_sym_per_subframe_dl(uint32_t idx_subframe); This function calculates the number of symbols used in PDSCH according to the index of subframe.
void modulate_QPSK(complex_t *out_data_buf, int8_t *in_data_buf, uint32_t len_sym); This function performs modulating for QPSK symbols which are filled in PDCCH and PBCH later.
void generate_QPSK_sym_siso(ppu_addr *ppu_addr_p, uint32_t len_sym); This function generates the pesude-random QPSK symbols for filling PDCCH and PBCH in cases of one transmission antenna.
48
void generate_QPSK_sym_mimo(ppu_addr *ppu_addr1_p, ppu_addr *ppu_addr2_p, uint32_t len_sym); This function generates the pesude-random QPSK symbols for filling PDCCH and PBCH in cases of two transmission antennas.
void print_mapper_pattern(complex_t *mapper_pattern); This function prints the mapper pattern for debug.
6.11 OFDM Symbol Generator File Directory:
lte_sym_gen
6.11.1 Generator on Transmitter
General Description: This module generates the OFDM symbols after the OFDM mapping operation has been done.
Generating OFDM symbols involves firstly inserting the zero at the DC subcarrier position and secondly after zero padding performing the IFFT operation. For the purpose of convenience, this module also does the operation of adding CP after completing the above OFDM symbol generation. Functions:
int lte_sym_gen(ppu_addr pkt_in, ppu_addr pkt_out): the main function. int sym_gen_ifft(float *in): The sub function used to perform the IFFT operation.
6.11.2 Degenerator on Receiver
General Description: Oppose to the transmitter, the degenerate module extracts the inserted CP and zero out to perform FFT operation and then forms the original slots. Functions:
int lte_sym_degen(ppu_addr pkt_in, ppu_addr pkt_out): the main function. int sym_degen_fft(float *in): this sub function is called to finish FFT task.
6.12 Channel Simulator
6.12.1 PPU Part
File Directory: lte_channel_ppu
General Description: This block performs the simulation of a real physical channel, which means it must have the
AWGN noise, multi-path, Doppler frequency offset and MIMO channel correlation. It supports 1x1 (1 transmit antenna and 1 receive antenna), 1x2 and 2x2 channels. This block is run in PPU because of the great volume of data. And due to the ideal estimator used in the simulation, the channel should also give out the ideal time impulse response. Functions:
void channel_siso_ppu(void *in_pointer, float noise_power, void *out_pointer, chan_resp_t *chan_resp); performs the 1x1 channel, which can be AWGN channel without fading, or EITU
49
channel. chan_resp is just a structure denoting the ideal time impulse response, declared in lte_types.h.
void channel_simo_ppu(void *in_pointer, float noise_power, void *out_pointer_1st, void *out_pointer_2nd, chan_resp_t *chan_resp); similar to channel_siso_ppu except for performing the 1x2 channel. void channel_mimo_ppu(void *in_pointer_1st, void *in_pointer_2nd, float noise_power, void *out_pointer_1st, void *out_pointer_2nd, chan_resp_t *chan_resp); similar to channel_siso_ppu except for performing the 2x2 channel.
void channel_awgn_siso(void *in_pointer, float noise_power, void *out_pointer, chan_resp_t *chan_resp); performs 1x1 AWGN channel, which only contains AWGN noise, no fading.
void channel_awgn_simo(void *in_pointer, float noise_power, void *out_pointer_1st, void *out_pointer_2nd, chan_resp_t *chan_resp_p); performs 1x2 AWGN channel, which only contains AWGN noise, no fading.
void channel_awgn_mimo(void *in_pointer_1st, void *in_pointer_2nd, float noise_power, void *out_pointer_1st, void *out_pointer_2nd, chan_resp_t *chan_resp_p); performs 2x2 AWGN channel, which only contains AWGN noise, no fading.
void channel_eitu_siso(void *in_pointer, float noise_power, void *out_pointer, chan_resp_t *chan_resp); performs 1x1 EITU channel, whose Doppler frequency and the number of paths can be modified through changing the channel model in the script file “global.xml”.
void channel_eitu_simo(void *in_pointer, float noise_power, void *out_pointer_1st, void *out_pointer_2nd, chan_resp_t *chan_resp); similar to channel_eitu_siso except for performing 1x2 EITU channel.
void channel_eitu_mimo(void *in_pointer_1st, void *in_pointer_2nd, float noise_power, void *out_pointer_1st, void *out_pointer_2nd, chan_resp_t *chan_resp); similar to channel_eitu_siso except for performing 2x2 EITU channel.
void _add_noise(complex_t *input, uint32_t data_len, float noise_power, complex_t *output); used to add complex Gaussian white noise to input data.
void init_channel(); used to initiate the parameters of EITU channel, such as the Doppler frequency, number of paths, the gain of each path, the initial phase of each path and so on.
void generate_eitu_channel(); generate the coefficients of EITU channel according to the parameters prepared in init_channel, and MIMO channel correlation is also considered.
void channel_attenuate(complex_t **input, uint32_t data_len, uint32_t seg_offset, complex_t **output); multiply the channel coefficients and the data in different path, considering the different delays in different path.
void free_channel(); free the store malloced in init_channel. void get_chan_response(chan_resp_t *chan_resp, float noise_power); get the ideal time impulse response of the channel for ideal estimating.
6.12.2 SPU Part
File Directory: lte_channel_spu
General Discription: This block is run in SPU to call the corresponding functions to run in PPU.
Functions:
50
void channel_siso_spu(ppu_addr in_pointer, float noise_power, ppu_addr out_pointer, ppu_addr chan_resp_p); call channel_siso_ppu.
void channel_simo_spu(ppu_addr in_pointer, float noise_power, ppu_addr out_pointer_1st, ppu_addr out_pointer_2nd, ppu_addr chan_resp_p); call channel_simo_ppu. void channel_mimo_spu(ppu_addr in_pointer_1st, ppu_addr in_pointer_2nd, float noise_power, ppu_addr out_pointer_1st, ppu_addr out_pointer_2nd, ppu_addr chan_resp_p); call channel_mimo_ppu.
6.13 Channel Estimation File Directory:
lte_estimator General Discription:
This block performs the channel estimation operation, which tries to estimate the channel frequency domain response. Due to ideal estimator we used in simulation, this block should be know the ideal time impulse response in channel and transfer it to frequency domain response. Functions: void estimate(ppu_addr in_chan_resp, uint8_t n_path, ppu_addr *out_chan_pkt_array); transfer the ideal time impulse response in in_chan_resp to the frequency domain response out_chan_pkt_array. The n_path here just equals to NUM_TX_ANTENNA x NUM_RX_ANTENNA.
void _fft_2048(complex_t *in, complex_t *out); performs fft of 2048 complex datas. void _fft_shift(complex_t *in, complex_t *out, uint32_t n_subcarrier); used to cyclic shift the data.
6.14 Channel Equivalent File Directory:
lte_equalizer General Discription:
This block just combine or separate the packets and calculate the equivalent channel coefficients of the data. The specific compensation of channel fading can be found when demodulate the data into soft information. Functions:
void equalize_siso(ppu_addr in_data_pkt, ppu_addr in_chan_pkt, ppu_addr out_data_pkt, ppu_addr out_chan_pkt); equalize the data attenuated by the channel in frequency domain and modify the channel coefficients for demodulator. void equalize_simo(ppu_addr *in_data_pkt_vec, ppu_addr *in_chan_pkt_vec, ppu_addr out_data_pkt, ppu_addr out_chan_pkt); equalize the two packets out of 1x2 channel and combine them by MRC void equalize_mimo_sw(ppu_addr *in_data_pkt_vec, ppu_addr *in_chan_pkt_vec, int8_t cb_idx, ppu_addr out_data_pkt, ppu_addr out_chan_pkt); equalize the two packet of one codeword out of 2x2 channel and combine them by MRC void equalize_mimo_dw(ppu_addr *in_data_pkt_vec, ppu_addr *in_chan_pkt_vec, int8_t cb_idx, ppu_addr *out_data_pkt_vec, ppu_addr *out_chan_pkt_vec); equalize the two packets out of mimo channel and separate them by MMSE.
51
float _sqr(complex_t in); calculate the norm of a complex. complex_t _div(complex_t a, complex_t b); calculate the division of two complex numbers. complex_t _det(cmat_2x2 in); calculate the determinant of a 2x2 matrix. cmat_2x2 _mul(cmat_2x2 in_a, cmat_2x2 in_b); calculate the multiplication of two 2x2 complex matrixes. cmat_2x2 _mmse_mat(cmat_2x2 in, float noise_power); calculate the MMSE matrix, which is (HHH+σ2I)-1 HH. H is the 2x2 channel matrix, σ2 is the noise power, superscript H means conjugate transpose and superscript -1 mean inverse matrix.
void print_cmat(cmat_2x2 in); print the complex number in a 2x2 complex matrix.
6.15 Statistics File Directory:
lte_statistic_spu General Discription: This block is run in SPU and calculates some types of statistical results to evaluate our simulation system, and exports the statistical results into a text file. The statistical results contain channel SNR, encoded bit error(ber), un-encoded bit error before and after rate-matching (pber and hber), and throughput rate. Functions: void init_statistic(); initiate the accumulator to 0. void ber_calculate(ppu_addr in1, ppu_addr in2); count the different bits between the packet out of source and that at the end of receiver. void pber_calculate(ppu_addr in1, ppu_addr in2); count the different bits between the packet before modulator and that after modulator. void hber_calculate(ppu_addr in1, ppu_addr in2); count the different bits between the packet after turbo encoder and that before turbo decoder. void snr_thr_record(ppu_addr in, enum idx_cw_t idx_cw); record the SNR of every packet and whether the packet has passed or not. void tti_result_save(char *in, uint32_t tti_idx, enum idx_cw_t idx_cw); record the results of each TTI. The input char *in decides the file recording the results. void snr_result_save(char *in); record the results of a simulation of a SNR. The input char *in decides the file recording the results.