Introduction This document provides a complete description of the DL microkemels (MKs) and the way in which they are to be called to realize the steps that constitute the symbol level processing as per 3GPP standard Supported channels The current support includes the following channels. 1. PDSCH upto 4 layers 2. PDCCH 3. SSB a. PSS b. SSS c. PBCH 4. CSI-RS upto 4 ports Process flow The DL processing is broken down into bit-level and symbol-level processing and this applies to all channels except PSS, SSS and CSI-RS where there is no bit level processing involved. The bit-level processing happens in the OTX HW with the necessary configuration given by control SW. This control SW entity will be called the L1-SS and it runs in one of the SUs in the OTRX HW. The OTX HW performs the bit-level processing up to rate-matching in a single shot (on a slot basis) for each channel of each user and stores the data in the OTRX LMEM The TXU processing happens at a symbol-level. On every symbol, OTX gets a trigger from L1-SS with the necessary user/channel configuration to fetch the bits for those users, perform scrambling and modulation and write the modulated data to TXU LMEM. In the rest of the document, this data would be referred to as post-proc data. This data becomes the input to the TXU for DL processing. In the presence of multiple layers, the processing in TXU is split across multiple TXUs. Depending on the number of layers to be processed, the number of TXUs that are deployed can change and typically, the processing is split such that there is one-layer processing in a single TXU.L1-SS interaction with OTX The interaction between L1-SS and OTX on a per-symbol basis is to generate the post-proc output. In BO, it is expected that the post-proc output is written at a fixed predefined offset for each user on all symbols instead of concatenating them one below another. This is done because one or more DL MKs require the start-offset of each user to be specified as a configuration and by keeping this fixed throughout the slot, the configuration can be made static for the entire slot. In order to illustrate this better, let us consider an example where there are three users with the following configuration 1. User-0: RBs 0-99 with no data on DMRS 2. User-1: RBs 180-199 with data on DMRS 3. User-2: RBs 240-269 with data on DMRS The post-proc memory arrangement for the above example is illustrated in the figure below. ‘On all symoo's other Use-0 Data User Data ser2 Data than DRS symbol Start of each user is invariant across symbols irrespective of the number of tones: for thal user Enoly deta fem) Data | Emety | Ona DURS symbol Use User User Figure-1: Illustration of post-proc memory arrangement The illustration above corresponds to the post-proc buffer of a single layer in a single ‘TXU and the same picture holds true for other layers in the respective TXUs. The OTX control has to use a fixed offset in the post-proc buffer for each user across symbols and the necessary configuration to achieve this has to be added to the interface between OTX and L1-SS. TXU MK Flow The steps involved in DL depend on the channel being transmitted and applies to all users for whom the channel is applicable. At a high level, the below steps can be associated with the transmission of all the supported DL channels. Saino So Lol coy ona [>| Open [4 Meinaente La trent | tremens terertieyersto acne! | poaic) | [ange x caiaon a Per eye pera Figure-2: Functional block diagram of DL processingThe DL processing flow in TXU depends on the nature of the symbol (DMRS, data, CSI-RS or mixed) and involves invoking a set of MKs in a certain sequence. The DL MKs in BO accept multiple user configurations and process the whole set of users in sequence. This would mean that there need not be a loop over users in the TXU control FW and it would be handled by the MK completely, The sequence of MKs/steps depending on the symbol type is given in Figure-3. Figure-3: MK sequence for trivial symbol types As can be seen from figure-3, there is a set of MKs which are used repeatedly for different symbol types. The subsequent sections explain the functionality implemented by each of the above MKs and also the arrangement of data in memory as it flows through the above MKs. MK Description mk_nr_mu_pow_scale This MK performs the power scale operation for all the active users in a certain symbol. This takes the post-proc data as the input, scales it according to the configured scale value and writes it into a configured intermediate output buffer. It can be seen from figure-1 that the post-proc data of each user is available in a single common buffer at different user-specific offsets. The power scale MK expects this offset and the number of RBs for each user to be specified in the API.It takes three buffers for storing the output and the buffer to which the output is stored depends on the nature of the symbol. The three different symbol types are 1. Data symbol - Used for storing the output of the data-only users 2, DMRS symbol - Used for storing the scaled output of users with data on DMRS 3. CSI-RS symbol - Used for storing the scaled output of users overlapping with CSLRS For the users who have data alone on the current symbol, this MK writes the scaled output into the configured buffer at the same offset as the input. For the users with data on DMRS, the scaled output is written into the configured buffer in a continuous manner. mk_nr_dmrs_gen_ins This MK generates the DMRS for each user and extracts the DMRS corresponding to the PRBs allocated for that user. The extracted DMRS is written to a configured intermediate buffer continuously across the users that are processed. It also takes the scaled post-proc data of the same set of users as input and performs the insertion of the DMRS into the scaled post-proc data according to a configured insertion bitmap, The DMRS inserted buffer would have the data of all configured users continuously in memory. mk_nr_mu_copy This MK is used only on symbols where a subset of users have DMRS and the remaining users have data alone. In such symbols, the power scale MK writes the output to two buffers, one corresponding to users who have data alone and the other corresponding to users with DMRS. As with the former buffer, the output is written at the same offset as the input whereas for the latter, it is written continuously and used by the DMRS_gen_ins MK to perform the insertion. Once the insertion is complete, the mu_copy MK is used to copy the DMRS inserted data of each user into the buffer that holds the scaled post-proc output of the data-only users. Once the copy is done, this shall be used as the input to the VRB2PRB MK. mk_nr_vrb2prb This MK performs the mapping of the scaled post-proc data (in the case of a data symbol) or the DMRS inserted data (in the case of the DMRS symbol) onto a common buffer which represents the frequency domain grid for the current symbol. This buffer would be of size corresponding to the maximum number of PRBs in the BW of transmission. This MK runs in a user-agnostic manner, however, it would be required to calll this MK once per channelmk_nr_mat_vec_mult This MK performs the precoding operation required for the different DL channels. The precoding operation involves multiplying the transmitted symbol vector on each tone with a precoding matrix. In our implementation, the precoding matrix is set static across the tones of a given PRB. Accordingly, the MK expects a precoder matrix to be specified for each RB. There will be a single call to this MK across all users and channels active in the current symbol. mk_nr_zero_insert This MK is used to insert the place holders for the CSI-RS subcarriers. When PDSCH overlaps with CSI-RS, zeroes are inserted in between the overlapping PDSCH data tones and are taken through the regular DL processing chain. Once the precoded frequency domain output is available, the CSI-RS tones are generated and inserted into the placeholder tones using the mk_nr_csirs_gen MK. mk_cmn_fft_1024/mk_cmn_fft_4096 There are two MKs for performing FFT/IFFT. The MK, mk_cmn_fit_1024 is used in cases where the FFT/IFFT length is less than or equal to 1024. Mk_cmn_fft_4096 is used in cases where the FFT/IFFT length is greater than 1024, Both the MKs do not require any rearrangement of input data. There is no special handling required for the output as well since the subsequent MK (tx_td_sym_proc) handles the stride arrangement in memory. mk_cmn_fft_shift This MK is used to perform three operations namely 1. FFT shift (Shifting DC from center to Oth index or vice versa) 2. Scaling the entire symbol by a complex number (Useful for applying the symbol phase compensation scale) 3. Handling the input stride required by the IFFT MK This MK is called on all symbols prior to the FFT MK call. mk_cmn_tx_td_sym_proc This MK performs two operations namely, 1. CP addition 2. Tx windowing This MK reads the IFFT output in stride order, performs the above-mentioned operations and writes the output into the final circular buffer which acts as the input tothe DUC. The circular copy in BO is still implemented using two linear copies and it is the control SW responsibility to provide the two addresses on a per-symbol basis MK APIs This section tabulates the size of the configuration required by each of the above MKs. The API size of each MKis tabulated in Table-1. It can be found from the MK APIs that, some of the variables are pointers to configuration structures which are used to store user or symbol specific information. mk_nr_mu_pow_scale 10 mk_nr_mu_dmrs_gen "1 mk_nr_pttrn_ins 15 mk_nr_mu_copy_sct 6 mk_nr_vrb2prb 5 mk_cmn_n_to_one_copy 23 mk_nr_mat_vec_mult mk_cmn_one_to_n_copy mk_nr_zero_ins mk_nr_fit_1024/4096 mk -ft_shift mk_cmn_tx_td_sym_proc Tabi ize of API for the different DL MKs p_ue_idx_ary min(numUes, 32) | UINTS The index of active UEs in the current symbol p_sym_type_ary min(numUes, 32) | UINT8 The nature of symbol for each user: data, dmrs or csirsp_num_data_ton | min(numUes, 32) | UINT16 | The number of data tones for e_ary each user; set to numRbs * 12 p_vrb_offset_ary | min(numUes, 32) | UINT16 | The start offset of each user in the postproc buffer p_pow_scale_ary | min(numUes, 32) | UINT16 | The power scale value for each user in Q11 format Table-2: User specific parameters used in mk_nr_mu_pow_scale() ParameterName| Length _| Data Type Description p_ue_idx_ary | min(numUes, 32) UINT8 | The index of active UEs in the current symbol p_dmrs_init_state | min(numUes, 32) | UINT32 | The ¢_init value for each user on —x2_ary (SC16) the current symbol p_dmrs_sym_val | min(numUes, 32)|UINT32 | The 16-bit value to be used to ue_ary represent bitO (Upper 16 bits) and bit1 (lower 16 bits) in the DMRS sequence p_num_tb_ary | min(numUes, 32) | UINT16 _| The number of RBs per user p_num_dmrs_ge | min(numUes, 32) | UINT16 The number of tones in the n_tone_ary generated DMRS sequence. This has to be set as maxRbOfUser * numDmrsTonesPerRb Table-3: User specific parameters used in mk_nr_mu_dmrs_gen() From Tables-2 and 3, the memory needed for the user specific parameters is 21 bytes per user. Table-4 below shows the memory needed for one instance of these parameters for different numbers of users. Number of users | Size in words 1 5.25 2 10.5 4 24 8 42 16 8432 168 Table-4: Size of one instance of user specific config for different number of users Data flow across MKs In order to illustrate the different MK calls and the way in which they process the postproc data and generate the output at different stages, two example scenarios are considered. In both cases, there are 3 users. In the first one, the symbol type of each user is the same on all symbols, In the second case, there is some difference across users on different symbols. The flow of data through memory is shown in the below figures for these two cases User-0: User ser-2: Start PRB = 10 Start PRE = 100 Start PRB = 200 Num PRBs = 80 Num PRBs = 30, Num PRBS = 50, DMRS Symbols = (2, 9) DMRS Symbok Data on DVRS = Present Data on OMRS 2,9) DMRS Symbois = (2, 9 resent Data on DMRS = Present Data Symbol (All symbols except 2, 9) Postsroe Data a a0 012 wee) em ORS Te 2(60 RB 2 wee COuput of power sealing (Scratch bur and input to VRBZPRE ponte by cst cut) ‘sea 00 Rs: 0012 wr) eer 20 Tuscan noe 5-2 woe) ‘Quput of VRBZPRB (Scratch bufer an input to AU-DMA) — DMRS Symbol (Symbols 2, 9) a See aes ‘Oulput of power sealing (Seratch butler and ene ofthe puts 19 DMRS ganinepomted by dst ut) ss wor Pertorm insertion to DMRS Garvns (Scratch butt andthe oer np ta nserten) g9ttho ta output foswoowas eorssieoe] ize, Juser2 pues] ones DIS Gowns (Fina! Ouput ater insertion) ‘se a0 ts ao2 wae) ers O0R5= | use (0 Ras 5°12 wares) ‘Culpa of VRAZPRE (Scratch bullet and input to ALLDMA) or R22 ee oe vase EP “1096 for Figure-4: Illustration of data flow for scenario-1User: User2: Start PRE = 100 Start PRE = 200 Num PBs « 20 ‘um PRBS « 30 Num PRs = 50 [DMRS Symbels = (2,9) DMRS Symbols «(2 DMRS Symbcs= (2 9) Data on DMRS = Present Datnon ONRS = Present Data on OM Data Symbol (All symbols except 2, 9) Postproe Data So Ke (Quputet power seaing (Seratch bute’ and input to VREZPRE pointe by dst pul ‘Uw 0 Rs: 02 wee) veary 26% Tus (50s 5°12 wor) ‘race ‘Oubut of VRB2PREB (Scratch bur and input io AU-DMA) eee RBS ‘Uae (0 Rs: 8012 wore) or (60 Re 6012 wea DMRS Symbol (Symbols 2) Post pro Data Input to power seating) se 0 Ras: 206 wor Free 2 1 = og2 ore Gulp of power scaling (Sertch buffer and cna ofthe nuts to DMRS gavin pobtad by dat ult) So eee sa [DMRS Genvins (Scratch buf end the other input to nseton) gettho fia! ouput sera puns eorex 87s] See? [user 2 owns co] one, DRS Gonins (Final Outpt ats incerion) Ue (0 08 a) TRIS | ezine tore wa ‘Ouput of VRB2PRE (Seach butler and input AU-DMA) Pogo 2S] | == DMRS Symbol (Symbols 9) Post proc Data tpt to power seating) [occa eorex eres) emycanage [om 2D 270] asa GRO Teapaage ‘Output of power scaling (Scratch butler and input to VREZPRB paired by dst but) enepiaarage enotcarage Quip of power ecaing (Sertch buffer and one ofthe puts to DMRS gerne ported by det uf) [sero eo nas: ere wor .— Prior ingen to OMS Genin (Seaton buer-1 andthe other nput onsen) getthe fal ouput ne ons (0 ROK Bsr OURS so] wos) pes soso Same tor URS Gervns (Final utp tar inserion) en: 80-2 wea) se (0 RB: 8012 wees) ‘Output of mu_copy (Same scratch butter used as VRBZPRE input) ‘up of VRBZPRE (Seach bur and pt 0 ALLEMA) — "User (80 RBS: 80°12 tones) T BEETTSTRES TT ser.2 (50 RBs! 50°12 tones)Figure-4: Illustration of data flow for scenario-2