Vianney Lapotre

Purushotham Murugappa

Guy Gogniat

Amer Baghdadi

Michael Hübner
email: michael.huebner@rub.de

Jean-Philippe Diguet

Stopping-free dynamic configuration of a multi-ASIP turbo decoder

Keywords: ASIP, Dynamic configuration, Turbo decoder, Wireless communications, ASIP

The multiplication of wireless standards is introducing the need of flexible and reconfigurable multistandard baseband receivers. At the physical layer, multiprocessor turbo decoders have been recently developed in order to provide an answer to the increasing throughput requirement of emerging standards. However these solutions do not sufficiently address reconfiguration performance issues which can be a limiting factor in the future. This work focuses on the design of a reconfigurable multiprocessor architecture for turbo decoding achieving very fast reconfiguration without compromising decoding performances. Dynamic reconfiguration can be performed within a single frame decoding duration opening new perspective for reconfigurable multistandard baseband receivers. For that purpose, optimizations at the processing element level and a novel bus-based configuration infrastructure are proposed. Results show that up to 64 processings elements can be dynamically configured in 5.352 µs. This low configuration latency corresponds to a single frame decoding duration when performing 6 decoding iterations for a throughput up to 666 Mbps.

I. INTRODUCTION

In the last years, multi-modes wireless communication standards have been developed in order to reach higher requirements in terms of throughput, robustness against destructive channel effects and convergence of services in a smart terminal. Forward error correction codes constitute a key feature of a wireless standard. Turbo codes are frequently adopted in recent wireless standards to reach a low bit error rate (BER). The increasing throughput requirement often imposes the efficient exploitation of the different levels of parallelism which have been introduced in multi-modes, multi-standards and multiprocessor decoders [START_REF] Vogt | A Reconfigurable Multi-Processor Platform for Convolutional and Turbo Decoding[END_REF], [START_REF] Murugappa | A Flexible High Throughput Multi-ASIP Architecture for LDPC and Turbo Decoding[END_REF], [START_REF] Condo | A Network-on-Chip-based turbo/LDPC decoder architecture[END_REF], [START_REF] Martina | A Flexible UMTS-WiMax Turbo Decoder Architecture[END_REF] in order to offer high throughput and high flexibility. These architectures implement subblock parallelism [START_REF] Hsu | A parallel decoding scheme for turbo codes[END_REF] where each frame is divided into subblocks and then each subblock is processed in parallel using adequate initializations. In this context, flexible ASIP (Application Specific Instruction set Processor) based multiprocessor architectures [START_REF] Vogt | A Reconfigurable Multi-Processor Platform for Convolutional and Turbo Decoding[END_REF], [START_REF] Murugappa | A Flexible High Throughput Multi-ASIP Architecture for LDPC and Turbo Decoding[END_REF], [START_REF] Brehm | A scalable multi-ASIP architecture for standard compliant trellis decoding[END_REF] have been explored. Multi-ASIP architecture is a promising approach to reach high flexibility, high throughput and energy efficiency. An ASIP based decoder implementing several ASIPs described in [START_REF] Vogt | A Reconfigurable ASIP for Convolutional and Turbo Decoding in an SDR Environment[END_REF] and a LTE accelerator in order to build a flexible turbo decoder for LTE requirements has been presented in [START_REF] Brehm | A scalable multi-ASIP architecture for standard compliant trellis decoding[END_REF]. In [START_REF] Vogt | A Reconfigurable Multi-Processor Platform for Convolutional and Turbo Decoding[END_REF], the authors present a NoC based multi-ASIP architecture in which ASIPs can be grouped to perform independent decoding tasks in parallel.

In [START_REF] Murugappa | A Flexible High Throughput Multi-ASIP Architecture for LDPC and Turbo Decoding[END_REF], authors present the UDec architecture. It consists of ASIPs (named DecASIPs) supporting both Single Binary Turbo Codes (SBTC) and Duo Binary Turbo Codes (DBTC) interconnected via a Network on Chip (NoC). Within each component decoder ASIPs are also connected by a ring network for boundary state metric exchanges. Dynamic reconfiguration of such platforms is particularly challenging as in many standards and/or applications decoding parameters can be changed as early as one data frame ahead [START_REF]IEEE Standard for Local and Metropolitan Area Networks Part 16: Air Interface for Fixed and Mobile Broadband Wireless[END_REF], thus it becomes mandatory to aggressively improve reconfiguration times in order to perform the reconfiguration of the whole multiprocessor platform within a single frame decoding duration. Fig. 1.a illustrates a scenario in which three frames are serially decoded with three different configurations. The configuration latency of a frame (noted ∆t Conf ig ) is constrained by the previous frame decoding duration. Fig. 1.b shows the frame duration for a frame size of 2048 bits depending on the decoding throughput. This example demonstrates that the available time to decode a frame critically decreases when the throughput requirement increases. Consequently, reaching a reconfiguration time below 10 µs will be a key concern to face expected throughput of future communication standards like LTE Advance which provides throughput up to 1Gbps. Management of dynamic reconfiguration of such multiprocessor channel decoder is not well addressed in the literature. In [START_REF] Vogt | A Reconfigurable Multi-Processor Platform for Convolutional and Turbo Decoding[END_REF], [START_REF] Murugappa | A Flexible High Throughput Multi-ASIP Architecture for LDPC and Turbo Decoding[END_REF], [START_REF] Martina | A Flexible UMTS-WiMax Turbo Decoder Architecture[END_REF], [START_REF] Brehm | A scalable multi-ASIP architecture for standard compliant trellis decoding[END_REF], flexible multiprocessor decoders are presented but no configuration infrastructure is proposed to deal with low latency reconfiguration of future communication standards.

Among the few related works, we can cite the recent architecture presented in [START_REF] Condo | VLSI Implementation of a Multi-Mode Turbo/LDPC Decoder Architecture[END_REF] where the authors propose solutions for the reconfiguration management of the multiprocessor Turbo/LDPC decoder architecture presented in [START_REF] Condo | A Network-on-Chip-based turbo/LDPC decoder architecture[END_REF]. Up to 35 processing elements (PEs) and up to 8 configuration buses have been implemented. Each PE is configured through a configuration memory. Groups of four PEs are connected to a dedicated configuration bus. The remaining PEs are shared among the buses when the number of PEs is not divisible by four. Dynamic reconfiguration during one frame duration is possible when the current configuration is small enough to load a new configuration in the memory. If not, authors provide management solutions to deal with this issue, such as erasing the current configuration during the last decoding iteration and continue the reconfiguration process during the first iteration of the new configuration, but it is not always sufficient. Then, stopping the current treatments to configure the new configuration is unavoidable and leads to a decoding quality loss in terms of BER. Moreover, the cost of the proposed multi-bus configuration infrastructure becomes too high with the increasing number of PEs and leads to a complex configuration transfer management. To leverage these issues, it becomes essential to propose original solutions for a low complexity and stopping-free configuration of multiprocessor turbo decoders.

Based on the work presented in [START_REF] Murugappa | A Flexible High Throughput Multi-ASIP Architecture for LDPC and Turbo Decoding[END_REF], where a flexible multi-ASIP turbo decoder implementation is proposed, this paper aims to further investigate and optimize the reconfiguration process in order to support stopping-free dynamic reconfiguration for high throughput requirements and high level of parallelism. Configuration latency below 10 µs must be proposed to reach this objective for emerging and future communication standards as shown in Fig. 1. This work features the following contributions: i) optimization of the DecASIP [START_REF] Murugappa | A Flexible High Throughput Multi-ASIP Architecture for LDPC and Turbo Decoding[END_REF] processing element for configuration efficiency in a multi-ASIP context, and ii) efficient bus-based configuration interconnection structure for a low configuration transfer latency and low area overhead.

The rest of this paper is organized as follows. Section II introduces the UDec architecture. Section III presents the proposed optimizations to reach an efficient configuration of the DecASIP in a multi-ASIP context. Section IV highlights the main issues that need to be addressed in order to build an efficient configuration infrastructure while section V describes the proposed bus-based solution. Section VI presents the implementation results. Finally section VII concludes the paper.

II. MULTI-ASIP TURBO DECODER

The UDec turbo decoder architecture [START_REF] Murugappa | A Flexible High Throughput Multi-ASIP Architecture for LDPC and Turbo Decoding[END_REF] is shown in Fig 2 . It consists of two rows of DecASIPs interconnected via a butterfly Network on Chip [START_REF] Moussa | Binary de Bruijn on-chip network for a flexible multiprocessor LDPC decoder[END_REF]. Each row corresponds to a component decoder. In the example of Fig. 2 The configuration memory contains all parameters required to perform the initialization of the ASIP while the program memory contains the instructions in order to perform the decoding algorithm. Since the DecASIP is designed to work in a multi-ASIP architecture as described in [START_REF] Murugappa | A Flexible High Throughput Multi-ASIP Architecture for LDPC and Turbo Decoding[END_REF], it requires several parameters to deal with a subblock of the data frame and several parameters to configure the ASIP mode. Concerning the subblock partitioning, each ASIP is configured with the size and the number of windows it has to decode. Furthermore, the last window size can be different so it corresponds to an additional parameter. In a single binary turbo code mode, the address of the tail bits in memory, the size and the number of windows for the tail bits have to be configured. Parameters for the ASIP mode correspond to the location of the ASIP in the architecture, the number of ASIPs required, the parameter which defines if the current ASIP is in charge of tail bits or not, the target standard (3GPP-LTE, WIMAX, or DVB-RCS) and the scaling factor for extrinsic information. Finally, some seed values are necessary for address generation in order to exchange information over the NoC that connects the ASIPs of each decoder component. All these parameters are required for a configuration of an ASIP within the platform.

In [START_REF] Murugappa | A Flexible High Throughput Multi-ASIP Architecture for LDPC and Turbo Decoding[END_REF], authors show that the DecASIP architecture provides high performance and high flexibility. However the topic of dynamic reconfiguration is not addressed. Despite its high flexibility, it presents some lacks to offer an efficient dynamic reconfiguration. The next section points out theses lacks and proposes several solutions to implement an efficient reconfigurable DecASIP for the UDec turbo decoder architecture.

III. RECONFIGURABLE DECASIP Several optimizations are proposed to reach an efficient dynamic reconfiguration of the DecASIP architecture. The first optimization is related to the storage of configuration parameters. Currently, some parameters are stored in the configuration memory and others are provided in the program instructions directly [START_REF] Murugappa | A Flexible High Throughput Multi-ASIP Architecture for LDPC and Turbo Decoding[END_REF]. The second optimization deals with the way used to load the configuration memory through the configuration memory organization. The third optimization corresponds to the development of a generic program independent of the configuration to be performed.

A. Configuration parameters storage

To reach configuration efficiency, we propose to move all parameters from the program memory to the configuration memory. This solution allows to configure a single memory to change all the configuration parameters (instead of loading both new program memory and configuration memory). Furthermore, once the ASIP is configured, the configuration memory can be accessed without any conflict since the configuration is loaded inside internal registers of the ASIP during the initialization step. This is a key point to prepare the next configuration if necessary. Indeed, the entire next configuration can be loaded in the configuration memory during the processing of the current data frame. Thus the configuration loading can be completely masked.

B. Configuration memory organization

In order to improve the configuration of the ASIP, it is essential to analyze the organization of the configuration memory. The parameters stored in the configuration memory are very specific. They can be divided in four categories: 1) interleaving domain dependent, 2) identical for all ASIPs, 3) for all ASIPs and 4) different for the last ASIPs which decode the tail bits in a single binary turbo code mode. All these characteristics need to be taken into account in order to build a low latency configuration process. A smart memory organization should allow an efficient broadcasting of the configuration parameters to the required ASIPs. Thus we propose to group the parameters depending on the previously described categories. Three groups which occupy different parts of the configuration memory are defined.

Table I shows the proposed configuration memory organization. The memory is organized as follows: (1) from address @0 to @1, parameters can be different for each ASIP. Furthermore, to optimize the initialization step of the ASIP, the parameter Tail which indicates if the ASIP has to perform or not the tail bits is also included in this group. Only the last two ASIPs are concerned by the tail bits in a single binary turbo code mode; (2) from address @2 to @6, the parameters are domain dependent; (3) from address @7 to @10, the parameters are the same for all ASIPs. This organization allows a good way for a fast reconfiguration at the platform level. Indeed, multicast mechanisms can be used to load the configuration in order to minimize the data transfers load. In this context, two multicast transfers are necessary to send domain dependent parameters to dedicated ASIPs and one multicast transfer for parameters that are the same for all ASIPs. Finally, unicast transfers are used to load the ASIP dependent parameters.

C. Generic program

We propose to simplify the configuration mechanism by using a unique generic program. Since all parameters contained in the program memory have been moved to the configuration memory, three possibilities exist for the program: two programs for single binary turbo code and one program for duo binary turbo codes. In single binary mode, after the initialization step, the last two ASIPs have to perform the tail bits while other ASIPs execute NOP operations. So, a particular program is loaded in these last two ASIPs. In duo binary mode, data frames are decoded after the initialization step. In order to merge these three possible programs, the new unique program has to be able to tackle these three cases. For this purpose, the program which integrates the tail bits computation is used as a reference. We have chosen to modify the Fetch pipe stage of the ASIP in order to detect and replace the instructions for tail bits with NOP instructions if the ASIP is not concerned. The value of the bit Tail stored in the configuration memory (Table I) determines if the ASIP is concerned or not by tail bits decoding. In duo binary mode, no tail bits have to be decoded. So, using a unique program in this mode adds 12 extra NOP instructions before the decoding step which corresponds to tail bits computation in single binary mode. However, these extra clock cycles are negligible regarding the number of cycles required to perform the decoding on one entire data frame.

Optimizations described in this section allow to reduce the (re)configuration impact thanks to the new memory organization and the generic program which reduce the total configuration load to be transferred when a new configuration has to be performed.

IV. MAIN CHALLENGES FOR AN EFFICIENT CONFIGURATION INFRASTRUCTURE

In the UDec architecture, the 80-bit buses and the Butterfly NoC are optimized and dedicated to exchange data between DecASIPs. So, these interconnection structures can not be used to transfer the configuration data without performance lost. To build an efficient solution, the configuration interconnection structure has to be specific and to take into account the following requirements: 1) Low complexity, 2) Multicasting mechanism and 3) Burst transfer.

A. Low complexity

The configuration infrastructure only manages configuration memories updates. Thus, this extra hardware must have a minimal impact on the global design complexity in terms of area overhead. When designing a communication architecture in a multiprocessor platform, two main technologies are available: Network on Chip or On-Chip Bus. Last decade has seen the huge adoption of Networks on Chip in complex System on Chip to mainly enhance the throughput and the scalability compared to a bus-based communication infrastructure. However, the design of a communication interconnect dedicated to configuration data does not require such a complex approach. Indeed, configuration broadcasting can be defined as a unidirectional communication between a configuration manager that generates and transfers configuration data to one or a group of processing elements that have to be configured. Hence, there is no transfer concurrency issue, and a unique component, called Master, is able to initiate a transfer. These features lead to a bus-based structure that provides a simple communication interconnect for this particular context.

B. Multicasting and selection

The UDec platform is configured through DecASIP configuration memories. As shown in section III, the DecASIP configuration memory is organized in order to allow multicast mechanisms for an efficient and fast configuration of the multi-ASIP platform. Moreover, depending on the application requirements, the number of activated DecASIPs to perform a given configuration can be tuned at runtime. Hence, a mechanism of processor selection has to be introduced in order to send configuration data to activated DecASIPs only.

C. Incremental data burst transfer

The last point to build an efficient configuration infrastructure for the UDec platform is related to the transfer mode. Since some of the configuration data has to be loaded in adjacent parts in the configuration memory, all related transfers can be defined as a burst starting from a base address in the I, configuration data identical for all DecASIPs can be incrementally transferred starting from the base address @7. Four incremental transfers are then performed. Many On-Chip Buses have been developed these last years that propose different topologies and different communication protocols. Representative On-chip Buses are the AMBA [START_REF] Arm | AMBA specifications[END_REF], the CoreConnect [START_REF]CoreConnect Bus Architecture[END_REF] or the Avalon bus [START_REF] Altera | Avalon bus specification: Reference manual[END_REF]. Unfortunately, these solutions do not support multicast. [START_REF]Sonics network technical overview[END_REF] supports multicast but this solution implements complex arbitration mechanisms and communication protocols that are not necessary in our context. The Fast Simplex Link (FSL) [START_REF]Xilinx, FSL V2.0 specification[END_REF] proposes a low complexity unidirectional bus for data transfer. Unfortunately multicast is not supported. It is thus required to propose an optimized bus dedicated to configuration data for the UDec platform.

V. CONFIGURATION INFRASTRUCTURE

To address the main issues highlighted in section IV, we propose a new bus-based communication infrastructure as well as the associated communication protocol. Our goal is to optimize configuration data transfers into DecASIPs configuration memories for the UDec platform. In this section, we detail the architecture, the dynamic selection of activated DecASIPs and the protocol.

A. Architecture overview

The proposed bus architecture is presented in Figure 3. This architecture can be split in four functional blocks: Master Interface (MI), Slave Interface (SI), Selector and interconnect. Each configuration memory is connected to the bus through a SI. The configuration manager deals with the configuration generation which is based on internal decisions Destination @ Destination @ @ @ @ Base @ Base @ + 1 Base @ + 2 Base @ + 3 Base @ Base @ Base @ Base @ + 1 Base @ + 2 Base @ + 3 and external information and commands (this point is not addressed in this paper).

The MI provides an interface allowing the connection of the configuration manager to the bus. To initiate a transfer, the MI receives, from the configuration manager, the address of a SI or a group of SIs (called Destination address) and the memory base address where the transfer starts. During a transfer, the MI also manages the increment of the memory address based on the base address.

The SI provides an interface between the bus and the configuration memory. Its role is, when a transfer is enabled, to check if the destination address corresponds to its own address or one of its associated multicast addresses. Then, the SI retrieves the data (and the associated memory address) from the bus and writes it into the configuration memory.

The Selector provides a simple and efficient solution to select, at run-time, DecASIPs that are targeted by the next configuration data. For this purpose, each SI has a 1-bit input that is driven by the Selector. When this input is enable, the associated SI is activated and reacts to the events on the bus while it ignores all transfers in the other case.

The interconnect part of the proposed architecture consists of three buses and a transfer enable control signal. Two address buses are required. The first one (Dest.@ in Figure 3) is used to select the destination (i.e. one SI or a group of SIs) and the second (Mem.@) is used to indicate the target memory address. The third bus is used to send the configuration data. Finally, a control signal (T enable) is used to inform SIs that a transfer has been enabled.

B. Transfer protocol

The transfer of configuration data can be divided in three steps: 1) initialization and data transfer from the configuration manager to the MI, 2) data transfer from the MI to one or several SIs and 3) configuration memory loading from the SI.

1) From the configuration manager to the MI (upper part of Figure 4): During the initialization step, the config-uration manager sends the destination address and the base memory address to the MI. The T init control signal (Figure 3) is driven to indicate to the MI that a transfer initialization is required. On the MI side, when these two addresses are read, the first one is stored and the second one is used to initialize the memory address increment process. These addresses are used until a new transfer initialization step is performed. After the initialization step, the configuration manager can send one data per cycle on the Data bus. The D enable control signal is also driven at the same time to inform the MI that a data is available. Obviously, the data transfer can be suspended if no data is available. Figure 4 shows an example of transfer initialization and data transfer between the configuration manager and the MI.

2) From the MI to the SI(s) (middle part of Figure 4): Figure 4 presents two examples of data transfer on the bus. The first one shows the transfer of a single data, and the second shows a data burst. The transfer on the bus consists of two phases: address phase and data phase. The address phase lasts for a single clock cycle. During this cycle, the destination and the base memory addresses are sent on the corresponding bus. The T enable control signal is also driven to indicate that a transfer occurs. During the data phase, the data is sent on the Data interconnect. When a data burst is performed, a data is available at each clock cycle. The destination address is maintained on the bus during the transfer procedure while, for each data, the memory address is incremented by the MI.

3) From the SI to the configuration memory (lower part of Figure 4): When a transfer occurs, the SIs involved in the transfer store the memory address (read during the address phase) and get the data on the next clock cycle. To write into the configuration memory, the memory address is stored during one clock cycle. When the data is available, the control signal write enable of the memory is driven and the memory address and the data are sent on the interconnect between the SI and the configuration memory.

These three steps allow the transfer of a data into the configuration memory in 5 clock cycles. Moreover, thanks to the pipeline nature of the transfers, the configuration infrastructure is able to provide one data per clock cycle to the destination. As will be demonstrated in section VI such a solution outperforms existing solutions and allows reaching a very low latency reconfiguration time.

C. Selection

The UDec platform can dynamically select the number of DecASIPs involved in the decoding process depending on the requirements of an application (e.g. throughput, error rate, etc.). When a configuration command occurs, a selection mechanism is launched to select the SIs associated to the configuration memories connected to the DecASIPs involved in the next configuration. When an SI is not selected, it ignores all transfers on the bus. The Selector is configured through the bus infrastructure by the configuration manager which sends a configuration vector on the bus which is forwarded to the SIs.

This section has detailed the configuration infrastructure highlighting main features and providing an in-depth analysis of the latency. Next section focus on the implementation of the proposed solutions.

VI. IMPLEMENTATION RESULTS

A. RDecASIP implementation

The proposed optimizations described in section III have been implemented on the DecASIP presented in [START_REF] Murugappa | A Flexible High Throughput Multi-ASIP Architecture for LDPC and Turbo Decoding[END_REF]. The ASIP was modeled in LISA language using Synopsys (ex. Coware) Processor Designer tool. Synthesis of the previous and the new cores was done with 65nm CMOS technology with a clock frequency objective equals to 500MHz. Synthesis results have been extracted to determine the impact of the optimizations on the area of the ASIP. To evaluate the impact of the new features on the ASIP area, we extracted the area synthesis results for each pipeline stage of the RDecASIP. This ASIP consists of 10 pipeline stages as shown in Fig. 5. The reconfiguration optimizations presented in this paper do not affect all the stages. Only three stages are impacted. Indeed, from BM1 to EXTR-CH, stages are dedicated to data computation and this part of the

Table III CONFIGURATION AND PROGRAM BIT LOAD COMPARISON IN BITS

ASIP pipeline is not directly concerned by the configuration optimizations proposed in this work. Moreover, The prefetch stage is identical in the two implementation of the DecASIP. On the other hand, fetch (FE), decode (DC), and operand fetch (OPF) stages have seen their area increased compared to the previous ASIP. The proposed optimizations were implemented along the pipelines stages as follows:

• FE: The FE stage insures the automatic replacement of instructions for tail bits computation by NOP when the ASIP is not concerned by tail bits decoding.

• DC: This stage is mainly impacted by the transfer of all flexible parameters in a unique configuration memory. Instead of a direct access to some parameters in instruction code words, parameters are now read from registers. Thus, the number of connections with the register file has been increased. • OPF: This stage is impacted by the new configuration memory organization since it is in charge of the parameter registers initialization. The area overhead comes from the increasing number of parameters in the configuration memory and by added control structures that manage the configuration size flexibility. Since more configuration parameters are read from the configuration memory, the number of connections with the register file has been increased to configure additional registers.

Table II shows the global area comparison between the DecASIP and the new version optimized for dynamic reconfiguration called RDecASIP. We observe that the global logic overhead on the ASIP is 0.9% (1,628 µm 2 ). This overhead is mainly due to the additional internal registers used to store the configuration parameters read from the configuration memory.

The RDecASIP is configured through the optimized configuration memory presented in section III. Table III compares the configuration and program load (in bits) for the proposed RDecASIP and the original DecASIP presented in [START_REF] Murugappa | A Flexible High Throughput Multi-ASIP Architecture for LDPC and Turbo Decoding[END_REF]. For one ASIP, we observe that the proposed RDecASIP can be configured with 286 bits instead of 976 bits thanks to the generic program described in section III-C. Moreover, the new memory organization proposed in section III allows the optimization of the configuration memory loading. Indeed, parameters are sent to several ASIPs through a multicast mechanism. Thus, in a multi-ASIP context, each DecASIP has to be configured with its own configuration and program memory while configuration memory of the proposed RDecASIP can be loaded using a multicast mechanism as follows: 52 bits are independently loaded in each ASIP. ASIPs that work in the same interleaving domain are loaded with 130 common bits. Finally, 104 configuration bits are broadcasted to all ASIPs. Thanks to this new configuration memory organization, the impact of the number of ASIPs on the configuration load is significantly reduced: n.52 bits instead of n.976 bits, where n is the number of ASIPs implemented. For example, if 8 ASIPs are implemented in a multi-ASIP platform, the configuration load to configure the 8 ASIPs is 7808 bits with the DecASIP and 780 bits with the proposed RDecASIP.

The timing performances for turbo decoding of the new and the original version of the DecASIP are identical. Indeed, the pipeline architecture is still the same and both implementation are able to reach the maximum frequency of 500MHz. However, in double binary mode, the RDecASIP requires 8 extra clock cycles after the initialization phase to start decoding. Nevertheless, we can disregard these impacts in front of the decoding time of a data frame that is identical for both versions of the ASIP.

B. Configuration infrastructure implementation

To validate the proposed bus architecture and communication protocol presented in section V an hardware prototype on a Xilinx XUPV5 platform based on a Virtex 5 LX110T FPGA was developed. The prototype architecture is shown in Figure 6. It consists of a Xilinx Microblaze soft core that generates the configuration at run-time. The configuration is then sent through an FSL bus to a FSL to MI interface. The Fast Simplex Link (FSL) [START_REF]Xilinx, FSL V2.0 specification[END_REF] connection has been considered as this interconnect structure proposes a fast, simple and unidirectional connection. An asynchronous FIFO is associated to the FSL connection in order to provide frequency domain flexibility on both Microblaze and configuration infrastructure sides. The FSL to MI interface realizes the protocol adaptation between the FSL communication protocol and our bus protocol. Finally, the outputs of each SI Thanks to this hardware implementation, configuration transfer time were evaluated for several number of RDe-cASIP. For this purpose, the Microblaze and proposed bus frequency is set to 125 MHz. The Chipscope module is configured to monitor the output signals of the SIs. Table IV shows the configuration transfer times of the proposed bus compared with designs implementing CoreConnect PLB4 [START_REF]CoreConnect Bus Architecture[END_REF] and AMBA AXI4 [START_REF] Arm | AMBA specifications[END_REF] buses connected to a Microblaze with the clock frequency set up to 125MHz. Thanks to the multicast mechanisms, a low overhead of 72 ns is necessary to configure each additional couple of RDecASIPs (one ASIP in both natural and interleaved domains) while 968 ns and 528 ns are necessary for [START_REF]CoreConnect Bus Architecture[END_REF] and [START_REF] Arm | AMBA specifications[END_REF] respectively. Results of Table IV show that the proposed implementation significantly reduces the configuration time overhead when the number of active RDecASIPs increases compared to classical bus approaches. A logical synthesis of the proposed bus components was also done with 65nm CMOS technology with a clock frequency objective equals to 500MHz. Table V shows the area evaluation for the three components of the proposed configuration infrastructure. The logic overhead caused by the configuration infrastructure is 0.015 mm 2 which leads to a low penalty of 1% regarding the logic area of the 8 RDecASIPs (1.477 mm 2 ). Furthermore, regarding frequency objective of 500 MHz, a speedup of 4 on the configuration transfer latencies shown in Table IV can be expected compared to the 125 MHz FPGA prototype.

C. Stopping-free reconfiguration analysis

The minimum frame decoding duration providing a stopping-free configuration is determined by the longest configuration time that is 5.352 µs in Table IV. Thus, the maximum achievable throughput is theoretically limited for a given frame size and is given by the equation ( 1) where F rame duration min is equal to 5.352 µs.

Considering the UDec platform implementing RDe-cASIPs, the maximum achievable throughput is limited by the number and the performance of the RDecASIP. Equation [START_REF] Murugappa | A Flexible High Throughput Multi-ASIP Architecture for LDPC and Turbo Decoding[END_REF] shows the estimated throughput of the UDec platform.

Where N ASIP is the number of RDecASIPs, N instr is the average number of instructions to decode one symbol (N instr = 4 for the RDecASIP), N iter is the number of iterations performed and F clk is the frequency. It is worth to note that increasing the subblock parallelism degree can be done with careful consideration of boundary state metrics initialization as it can impact the convergence speed and thus reduce the parallelism efficiency [START_REF] Muller | Parallelism Efficiency in Convolutional Turbo Decoding[END_REF]. Several parameters should be considered in terms of frame size, code rate, interleaving rules, and state metrics initialization methods [START_REF] Muller | Parallelism Efficiency in Convolutional Turbo Decoding[END_REF]. Considering equation (1) and equation [START_REF] Murugappa | A Flexible High Throughput Multi-ASIP Architecture for LDPC and Turbo Decoding[END_REF] where the number of RDecASIP is limited to 64, Table VI, shows the maximum estimated throughput achievable in SBTC and DBTC allowing a stopping-free dynamic configuration and the corresponding number of RDecASIP that have to be used for different frame sizes and a number of decoding iterations equals to 6.

Results of Table VI show that stopping-free dynamic configuration can be achieved for a throughput up to 666 Mbps by coupling the RDecASIP presented in section III and the configuration infrastructure proposed in section V. For a UDec architecture implementing 64 RDecASIPs, Table VI shows that for long frames the throughput is limited by the number of implemented RDecASIPs while the throughput for smaller frames is bound by the configuration latency. However, considering an ASIC implementation of the configuration infrastructure, this bound can be divided by 4.

Compared to the recent related work proposed in [START_REF] Condo | VLSI Implementation of a Multi-Mode Turbo/LDPC Decoder Architecture[END_REF],the configuration infrastructure consists of several buses, each connected to a group of 4 PEs. Up to 8 buses have been implemented to configure 35 PEs to provide throughput up to 292 Mbps in DBTC mode and 150 Mbps in SBTC mode. However, the way the buses are driven is not described in details in the paper but the management of the 8 buses in parallel should increase the complexity of the configuration manager used to load new configurations. The approach proposed in this paper provides optimizations at PE level in order to build an efficient and low complexity configuration infrastructure. The proposed solution is a single bus implementing mechanisms optimized for dynamic configuration management that leads to stopping-free decoding when the constraints previously analyzed are respected. Such an approach allows an efficient dynamic configuration of high speed decoders without loss in error correction quality.

VII. CONCLUSION

This work describes an ASIP-based reconfigurable architecture for turbo decoding. This architecture is based on the UDec architecture implementing the RDecASIP optimized for an efficient dynamic configuration in a multiprocessor context. The architecture is reconfigured through a novel bus-based configuration infrastructure implementing incremental burst, unicasting, multicasting and broadcasting mechanisms providing a high speed configuration data transfer. Dynamic configuration in one frame decoding duration is provided for high throughput up to 666 Mbps when the frequency of the configuration infrastructure is 125 MHz.

Figure 1 .

 1 Figure 1. Configuration latency constraint and frame duration

Figure 3 .

 3 Figure 3. Architecture of the proposed bus interconnect configuration memory. For example, based on the DecASIP memory organization of TableI, configuration data identical for all DecASIPs can be incrementally transferred starting from the base address @7. Four incremental transfers are then performed.Many On-Chip Buses have been developed these last years that propose different topologies and different communication protocols. Representative On-chip Buses are the AMBA[START_REF] Arm | AMBA specifications[END_REF], the CoreConnect[START_REF]CoreConnect Bus Architecture[END_REF] or the Avalon bus[START_REF] Altera | Avalon bus specification: Reference manual[END_REF]. Unfortunately, these solutions do not support multicast.[START_REF]Sonics network technical overview[END_REF] supports multicast but this solution implements complex arbitration mechanisms and communication protocols that are not necessary in our context. The Fast Simplex Link (FSL)[START_REF]Xilinx, FSL V2.0 specification[END_REF] proposes a low complexity unidirectional bus for data transfer. Unfortunately multicast is not supported. It is thus required to propose an optimized bus dedicated to configuration data for the UDec platform.

Figure 4 .

 4 Figure 4. Communication from the configuration manager to the configuration memory through the communication infrastructure

  Figure 5. DecASIP Pipeline

Table II ASIP

 II AREA COMPARISON IN µm 2

		Config	Prog.	1	n
		param.	mem.	ASIP	ASIPs
	RDecASIP	286	-	286	n.52+260+104
	DecASIP	336	640	976	n.976
	Gain	14%	100%	70%	90% (n = 8)

Table V AREA

 V OF THE PROPOSED CONFIGURATION ARCHITECTURE


Efficient dynamic configuration of a multi-ASIP turbo decoder Vianney Lapotre*, Purushotham Murugappa ¥ , Guy Gogniat*, Amer Baghdadi ¥ , Jean-Noël Bazin ¥ Jean philippe Diguet*, Michael Hübner § *Univ. Bretagne Sud, UMR6285, Lab-STICC, firstname.lastname@univ-ubs.fr ¥ Telecom Bretagne, UMR6285, Lab-STICC, firstname.lastname@telecom-bretagne.eu § Rurh-Universität Bochum, ESIT, michael.huebner@rub.de

Configuration scenario

• Each frame can require a specific configuration.

• A new configuration is generated and loaded during the decoding of the current frame.

Due to high throughput, the frame decoding duration decreases. Thus, the maximal configuration latency critically decreases too

Reconfiguration in few µs becomes mandatory

Throughput evolution in telecommunication standards

						Frame decoding duration (n)
					Decoding	Frame n-1	Frame n	Frame n+1
					Configuration	Config. Frame n	Config. Frame n+1	Config. Frame n+2
					1 Gbit/s
		84 Mbit/s	150 Mbit/s LTE	LTE Advanced	Configuration latency max. (n+1)	Time
			HSPA +
		14.4 Mbit/s			4G
			HSPA	3G
	380 Kbit/s	UMTS
		Release 99
	236 Kbit/s	GSM GPRS	2G
		EDGE

Configuration transfer latency ( FPGA prototype, 125 MHz) Nb. ASIPs Transfer latency (in ns) Speedup

		Reconfigurable UDec architecture		RDecASIP
	Control flow	Data flow		Configuration flow	Noisy symbols from demapper	• SBTC and DBTC • Max-Log MAP algorithm
	Config Memory		Platform controller			Input interface		• 12 Windows of 64 symbols
		To ASIPs		To NoC					Optimized for high speed configuration
	Input Memory			Extrinsic Memory			Extrinsic Memory		Input Memory	• Generic Program for turbo decoding
	Input Memory Program Memory Config Memory Program Memory	RDecASIP 0 RDecASIP 1	Extrinsic Memory Cross metric Memory		Butterfly NoC NoC interface NoC interface NoC interface NoC interface	Cross metric Memory Extrinsic Memory	RDecASIP 2 RDecASIP 3	Program Memory Config Memory Input Memory Program Memory	• Multi configuration storage • 1 cycle re-initialization (for the same configuration parameters) • Smart memory organization  Unicast, multicast and broadcast for low latency configuration transfer Configuration infrastructure
	Config Memory		Cross metric Memory			Cross metric Memory		Config Memory	• Bus-based pipelined interconnect structure • Unicast, multicast and broadcast mechanisms
										• Incremental burst transfer
	Slave Interface (SI_0)	Slave Interface (SI_1)	Slave Interface 0 (SI_2)	Slave Interface (SI_3)	Slave Interface (SI_4)	Selector
	Mem.@ Data Dest. @	26 8 8								This work	CoreConnect PLB 4	AMBA AXI 4 vs. CoreConnect PLB 4 vs. AMBA AXI 4
	T_enable
										4	1 032	3 872	2 212	3.75	2.14
			Master Interface (MI)					6	1 176	5 808	3 168	4.94	2.69
										8	1 320	7 744	4 224	5.87	3.2
			8	8	T_init D_enable					16	1 896	15 488	8 448	8.17	4.45
			26		Base. @ Dest. @	Configuration Manager				32	3 048	30 976	16 896	10.16	5.54
					Data					64	5 352	61 952	33 792	11.57	6.31
						Configuration management for very low frame decoding duration
		Frame n				Frame n+1
					3
	T(n)			T(n+1)					Time


Vianney Lapotre

Hübner Michael
email: michael.huebner@rub.de

Purushotham Guy Gogniat

Murugappa Velayuthan

Amer Baghdadi

Michael Hübner

Purushotham Murugappa

Jean-Philippe Diguet

An efficient on-chip

Keywords: Multi-ASIP, Reconfiguration, Self-adaptation, Turbo decoder

An efficient on-chip configuration infrastructure for a flexible multi-ASIP turbo decoder architecture

I. INTRODUCTION
The increasing demand of flexibility, energy efficiency and throughput requirement for telecommunication applications leads designers to build dynamically reconfigurable application specific multiprocessor platforms. In this context the UDec architecture presented in [START_REF] Murugappa | A Flexible High Throughput Multi-ASIP Architecture for LDPC and Turbo Decoding[END_REF] is a flexible multi-ASIP turbo decoder. It consists of Application Specific Instruction set Processors (ASIP) interconnected through a Network on Chip (NoC) dedicated to data exchanges. The flexibility of the UDec architecture comes from a configuration memory associated to each ASIP. Each time a new configuration has to be launched, each ASIP downloads the corresponding parameters from its configuration memory. This flexibility must rely on a configuration infrastructure in order to transfer new parameters to configuration memories. Moreover, due to the increasing requirements in terms of throughput and low latency, the available reconfiguration time between two data frames decreases in recent communication standards. Fig. 1.a illustrates a scenario in which three frames are serially decoded with three different configurations. The configuration latency of a frame (noted ∆t Conf ig ) is constrained by the previous frame decoding duration. Fig. 1.b shows the frame duration for a frame size of 2048 bits depending on the decoding throughput. This example illustrates how the available time to decode a frame critically decreases when the throughput requirement increases. Consequently, reaching a reconfiguration time below 10 µs will be a key concern to face expected throughput of future communication standards like LTE Advanced which provides throughput up to 1Gbps. Management of dynamic reconfiguration of such multiprocessor channel decoder is not well addressed in the literature. To face these requirements this paper proposes an optimized on-chip configuration infrastructure dedicated to configuration data transfer in a dynamically reconfigurable application specific multiprocessor platform.

Several configuration infrastructures and strategies have been developed for recent reconfigurable multiprocessor architectures dedicated to multimedia and telecommunication applications. In [START_REF] Clermidy | An Open and Reconfigurable Platform for 4G Telecommunication: Concepts and Application[END_REF] and [START_REF] Jalier | Flexible and distributed real-time control on a 4G telecom MPSoC[END_REF], configurations are distributed among several configuration servers that provide configuration data on demand. In [START_REF] Clermidy | An Open and Reconfigurable Platform for 4G Telecommunication: Concepts and Application[END_REF] configuration servers are dedicated resources embedded in an heterogeneous platform while in [START_REF] Jalier | Flexible and distributed real-time control on a 4G telecom MPSoC[END_REF] each cluster of DSPs corresponds to a configuration server that provides a complete or a part of a configuration.

In both approaches, a unique NoC is used for application and configuration data as it is assumed that configuration transfers do not negatively impact the application data throughput. However, in [START_REF] Murugappa | A Flexible High Throughput Multi-ASIP Architecture for LDPC and Turbo Decoding[END_REF] the NoC is designed for interleaving process and cannot be used to configure ASIPs without reducing data throughput. Indeed, this NoC consists of two unidirectional butterfly NoCs that are optimized for application data. In this case, an additional configuration interconnect is mandatory to provide configuration mechanisms that do not lower decoding performances.

In [START_REF] Ventroux | Sesam: An mpsoc simulation environment for dynamic application processing[END_REF], clusters of DSPs are connected through a NoC for application data exchanges and a dedicated bus is used for both control and configuration transfers. A central controller sends configuration commands to local cluster controllers that download configurations from a central shared memory using DMA accesses. Thus, each component connected to the bus is a master. Extra hardware is required in order to manage and to arbitrate these transfers. In this paper, we propose a dedicated configuration infrastructure optimized for the architecture described in [START_REF] Murugappa | A Flexible High Throughput Multi-ASIP Architecture for LDPC and Turbo Decoding[END_REF]. It consists of a low complexity unidirectional on-chip bus implementing multicast mechanisms and incremental data burst in order to reduce the configuration latency. Moreover, a configuration manager, which is the only master on the bus, is in charge of the configuration generation at run-time. Compared to existing efforts our approach provides both a very low configuration latency and a low area overhead. Several optimizations have been developed in order to minimize the cost of the configuration infrastructure. To validate our contribution we have adopted a two-step evaluation process based on a virtual prototyping approach. In a first step a Sys-temC/VHDL mixed simulation model has been used to perform an early evaluation of our solution. Then, in a second step a FPGA prototype has been built to measure the actual hardware cost and performance.

The rest of this paper is organized as follows. Section II introduces the UDec architecture. Section III highlights the main issues that need to be addressed in order to build an efficient configuration infrastructure while section IV describes the proposed bus-based solution. Section V provides first evaluations through a SystemC/VHDL mixed model. Section VI presents the FPGA implementation results. Finally section VII concludes the paper.

II. MULTI-ASIP TURBO DECODER

A. UDec architecture

The turbo decoding system diagram is presented in Fig. 2. It consists of component decoders that exchange extrinsic information through an interleaver (Π) and a deinterleaver (Π -1 ) processes. The component decoder 1 receives Log-Likelihood Ratio (LLR) from a demapper for each bit of a data frame in the natural order while component decoder 0 receives LLR in interleaved order. Then, iterative decoding algorithm is performed to decode the data frame. The UDec turbo decoder architecture [START_REF] Murugappa | A Flexible High Throughput Multi-ASIP Architecture for LDPC and Turbo Decoding[END_REF] is shown in Fig. 3. It consists of two rows of DecASIPs interconnected through a butterfly topology NoCs [START_REF] Moussa | Binary de Bruijn on-chip network for a flexible multiprocessor LDPC decoder[END_REF]. Each row corresponds to a component decoder. In the example of Fig. 3, four ASIPs are organized in 2 component decoders respectively built with 2 ASIPs. Within each component decoder the ASIPs are connected by two 80bit buses for boundary state metrics exchange. The DecASIP implements the Max-Log MAP algorithm as described in [START_REF] Robertson | Optimal and suboptimal maximum a posteriori algorithms suitable for turbo decoding[END_REF]. It supports both single and double binary convolutional turbo codes and implements radix-4 trellis compression technique for SBTC mode. Large frames are processed by dividing the frame into N windows each with a maximum size of 64 symbols. Each ASIP can manage a maximum of 12 windows. The DecASIP is associated with 3 memory banks of size 24x256 used to store the input channel LLR values x. There are also another 3 banks of size 30x256 used for extrinsic information storing y. Each ASIP is further equipped with two 40x32 memories which hold state values z. Moreover, each ASIP is configured through a program { and a configuration memory |. The configuration memory contains all parameters required to perform the initialization of the ASIP while the program memory contains the instructions in order to perform the decoding algorithm. Since the DecASIP is designed to work in a multi-ASIP architecture as described in [START_REF] Murugappa | A Flexible High Throughput Multi-ASIP Architecture for LDPC and Turbo Decoding[END_REF], it requires several parameters to deal with a subblock of the data frame and several parameters to configure the ASIP mode. Concerning the subblock partitioning, each ASIP is configured with the size and the number of windows it has to decode. Furthermore, the last window size can be different so it corresponds to an additional parameter. In a single binary turbo code mode, the address of the tail bits in memory, the size and the number of windows for the tail bits have to be configured. Parameters for the ASIP mode correspond to the location of the ASIP in the architecture, the number of ASIPs required, the parameter which defines if the current ASIP is in charge of tail bits or not, the target standard (3GPP-LTE, WIMAX, or DVB-RCS) and the scaling factor for extrinsic information. Finally, some seed values are necessary for address generation in order to exchange information over the NoC that connects the ASIPs of each decoder component. All these parameters are required for a configuration of an ASIP within the platform.

B. UDec configuration

The behavior of the UDec turbo decoder is dependent of the parameters loaded in the configuration memory of each ASIP. In order to improve the reconfiguration step, it is essential to optimize the organization of the configuration memory. The configuration parameters stored in the configuration memory can be divided in four categories: 1) domain dependent, 2) identical for all ASIPs, 3) different for all ASIPs and 4) different for the last two ASIPs which decode the tail bits in single binary turbo code mode. A smart memory organization allows an efficient broadcasting of the configuration parameters to the required ASIPs. Thus, three groups which occupy three different parts of the configuration memory have been defined.

Table I shows the configuration memory organization. A configuration consists of 286 bits and is organized as follows:

• From address @0 to @1, parameters can be different for each ASIP. Furthermore, to optimize the initialization step of ASIP, the parameter Tail which indicates if the ASIP has to perform or not the tail bits is included in this group. Only the last two ASIPs have to deal with the tail bits in single binary turbo code mode. • From address @2 to @6, parameters are identical for ASIPs of the same decoder component.

Table I ASIP CONFIGURATION MEMORY

• From address @7 to @10, parameters are the same for all ASIPs. This organization allows an efficient and fast reconfiguration at the platform level. Indeed, multicast mechanisms can be used to load the configuration in order to minimize the data transfer load. In this context, two multicast transfers are necessary to send domain dependent parameters to corresponding ASIPs and one multicast transfer for parameters that are the same for all ASIPs. Finally, unicast transfers are used to load the ASIP dependent parameters.

Once configurations are loaded in ASIPs configuration memories, ASIPs can be launched as soon as input data are ready. The configuration parameters are then read from the configuration memory and stored in each ASIP internal registers. When this initialization phase is finished the decoding phase can start. Note that a new configuration can be downloaded into configuration memories while computation is performed, such an approach minimizes the reconfiguration latency and allows the execution scheme described in Fig. 1.a.

Besides the ASIPs, the UDec platform implements flexible elements as a controller, an input interface, the two buses for boundary state metrics exchange and the Butterfly NoC. The controller is in charge of the computation scheduling depending of the mode (serial or shuffle decoding), the number of decoding iterations, and the number and location of the selected ASIPs. The input interface is configured to spread the symbols coming from a demapper to the inputs memory of selected ASIPs depending of the frame size, the selected standard, the number and the location of the selected ASIPs. Finally, the two buses for boundary state metrics exchange and the Butterfly NoC Network Interfaces (NIs) are configured to take into account the number and location of the selected ASIPs. For that purpose, an extra configuration memory attached to the platform controller is added. When a new configuration is loaded, the controller launches an initialization phase to read configuration parameters in this memory and store them into configuration registers.

III. MAIN CHALLENGES FOR AN EFFICIENT CONFIGURATION

INFRASTRUCTURE

Dynamic reconfiguration of flexible multiprocessor platforms is one of the main challenges for system designers. This issue is important, especially when dealing with multiprocessor platforms where no global communication interconnect can be shared between application and configuration data. In this case, it is mandatory to implement a communication infrastructure dedicated to configuration data. In the UDec architecture, the 80-bit buses and the Butterfly NoC are optimized and dedicated to data exchange between DecASIPs. These interconnections can not be used to transfer the configuration data. To build an efficient solution, the configuration infrastructure has to take into account the following requirements: 1) Low complexity, 2) Multicasting mechanism and 3) Burst transfer.

A. Low complexity

The configuration infrastructure only manages configuration memories updates. Thus, this extra hardware must have a minimal impact on the global design complexity in terms of area overhead. When designing a communication architecture in a multiprocessor platform, two main technologies are available: Network on Chip or On-Chip Bus. Last decade has seen the huge adoption of Networks on Chip in complex System on Chip to mainly enhance the throughput and the scalability compared to a bus-based communication infrastructure. However, the design of a communication interconnect dedicated to configuration data does not require such a complex approach. Indeed, broadcasting can be defined as a unidirectional communication between a reconfiguration manager that generates and downloads configuration data to one or a group of processing elements that have to be configured. Hence, there is not transfer concurrency issue, and a unique component, called Master, is able to initiate a transfer. Moreover, we assume that the configuration manager is, at any time, aware of the configuration state of the platform. Thus, no read operations are necessary to check a status or the presence of a particular configuration in a given processing element. These features lead to a bus-based structure that provides a simple communication interconnect for this particular context.

B. Multicasting and selection

The UDec platform is configured through the DecASIP configuration memories. As shown in Section II-B, the DecASIP configuration memory is organized in order to allow multicast mechanisms for an efficient and fast configuration of the multi-ASIP platform. Moreover, depending on the application requirements, the number of activated DecASIPs to perform a given configuration can be tuned at run-time. Hence, a mechanism of processor selection has to be introduced in order to send configuration data to activated DecASIPs only.

C. Incremental data burst transfer

The last point to build an efficient configuration infrastructure for the UDec platform is related to the transfer mode. Since some of the configuration data has to be loaded in adjacent parts in the configuration memory, all related transfers can be defined as a burst starting from a base address in the configuration memory. For example, based on the DecASIP memory organization of Table I, configuration data identical for all DecASIPs can be incrementally transferred starting from the base address @7. Four incremental transfers are then performed.

Many On-Chip Buses have been developed these last years that propose different topologies and different communication protocols. Representative On-chip Buses are the AMBA [START_REF] Arm | AMBA specifications[END_REF], the Core-Connect [8] or the Avalon bus [START_REF] Altera | Avalon bus specification: Reference manual[END_REF]. Unfortunately, these solutions do not support multicast. Work presented in [START_REF]Sonics network technical overview[END_REF] supports multicast but this solution implements complex arbitration mechanisms and communication protocols that are not necessary in our context. The Fast Simplex Link (FSL) [START_REF]Xilinx, FSL V2.0 specification[END_REF] proposes a low complexity unidirectional bus for data transfer. Unfortunately multicast is not supported. It is thus mandatory to propose an optimized bus dedicated to configuration data that could be used for the UDec platform in order to reach the configuration latency challenge.

IV. CONFIGURATION INFRASTRUCTURE

To address the main issues highlighted in Section III, we propose a new bus-based communication infrastructure as well as the associated communication protocol. Our goal is to optimize configuration data transfers into DecASIPs configuration memories for the UDec platform. In this section, we detail the architecture, the dynamic selection of activated DecASIPs and the protocol.

A. Architecture overview

The proposed bus architecture is presented in Fig. 4. This architecture can be split in four functional blocks: Master Interface (MI), Slave Interface (SI), Selector and interconnect. Each configuration memory is connected to the bus through a SI. The configuration manager deals with the configuration generation which is based on internal decisions and external information and commands (this point is not addressed in this paper).

The MI provides an interface allowing the connection of the configuration manager to the bus. To initiate a transfer, the MI receives, from the configuration manager, the address of a SI or a group of SIs (called Destination address) and the memory base address where the transfer starts. During a transfer, the MI also manages the increment of the memory address based on the base address.

The SI provides an interface between the bus and the configuration memory. Its role is, when a transfer is enabled, to check if the destination address corresponds to its own address or one of its associated multicast addresses. Then, the SI retrieves the data (and the associated memory address) from the bus and writes it into the configuration memory.

The Selector provides a simple and efficient solution to select, at run-time, DecASIPs that are targeted by the next configuration data. For this purpose, each SI has a 1-bit input that is driven by the Selector. When this input is enabled, the associated SI is activated and reacts to the events on the bus while it ignores all transfers in the other case.

The interconnect part of the proposed architecture consists of three buses and a transfer enable control signal. Two address buses are required. The first one (Dest.@ in Fig. 4) is used to select the destination (i.e. one SI or a group of SIs) and the second (Mem.@) is used to indicate the target memory address. The third bus is used to send the configuration data. Finally, a control signal (T enable) is used to inform SIs that a transfer has been enabled.

B. Addressing

Due to the context of this work which deals with a platform that consists of several implementations of specialized processing elements, and to minimize the design complexity, we choose to statically, at design-time, define the SIs addresses and the different multicast addresses associated with each SI. Indeed, the interest of a run-time address definition is reduced by the fact that the DecASIPs are statically grouped depending of the domain in which they perform the treatments. Each SI connected to the interconnect block owns an unique address. This address allows configuration information transfers to a particular configuration memory only. Moreover, each SI is associated to two multicast addresses. The first one is common for all SIs and the second one is common for SIs associated with DecASIPs in the same domain.

C. Transfer protocol

The transfer of configuration data can be divided in three steps: 1) initialization and data transfer from the configuration manager to the MI, 2) data transfer from the MI to one or several SIs and 3) configuration memory loading from the SI.

1) From the configuration manager to the MI (upper part of Fig. 5): During the initialization step, the configuration manager sends the destination address and the base memory address to the MI. The T init control signal (Fig. 4) is driven to indicate to the MI that a transfer initialization is required. On the MI side, when these two addresses are read, the first one is stored and the second one is used to initialize the memory address increment process. These addresses are used until a new transfer initialization step is performed. After the initialization step, the configuration manager can send one data per cycle on the Data bus. The D enable control signal is also driven at the same time to inform the MI that a data is available. Obviously, the data transfer can be suspended if no data is available. Fig. 5 shows an example of transfer initialization and data transfer between the configuration manager and the MI.

2) From the MI to the SI(s)(middle part of Fig. 5): Fig. 5 presents two examples of data transfer on the bus. The first one shows the transfer of a single data, and the second one shows a data burst. The transfer on the bus consists of two phases: address phase and data phase. The address phase lasts for a single clock cycle. During this cycle, the destination and the base memory addresses are sent on the corresponding bus. The T enable control signal is also driven to indicate that a transfer occurs. During the data Destination @ Destination @ @ @ @ Base @ Base @ + 1 Base @ + 2 Base @ + 3 Base @ Base @ Base @ Base @ + 1 Base @ + 2 Base @ + 3 phase, the data is sent on the Data interconnect. When a data burst is performed, a data is available at each clock cycle. The destination address is maintained on the bus during the transfer procedure while, for each data, the memory address is incremented by the MI.

3) From the SI to the configuration memory (lower part of Fig. 5): When a transfer occurs, the SIs involved in the transfer store the memory address (read during the address phase) and get the data on the next clock cycle. To write into the configuration memory, the memory address is stored during one clock cycle. When the data is available, the control signal write enable of the memory is driven and the memory address and the data are sent on the interconnect between the SI and the configuration memory.

These three steps allow the transfer of a data into the configuration memory in 5 clock cycles while 11 clock cycles and 6 clock cycles are necessary through the CoreConnect and the AMBA buses respectively. Moreover, thanks to the pipeline nature of the transfers, the configuration infrastructure is able to provide one data per clock cycle to the destination.

D. Selection

The UDec platform can dynamically select the number of DecASIPs involved in the decoding process depending on the requirements of an application (e.g. throughput, error rate, etc.). When a configuration command occurs, a selection mechanism is launched to select the SIs associated to the configuration memories connected to the DecASIPs involved in the next configuration. When an SI is not selected, it ignores all transfers on the bus. The Selector is configured through the bus infrastructure by the configuration manager which sends a configuration vector on the bus. Each bit of this vector corresponds to the state of one SI. This solution allows a fast selection of SIs compared to a mechanism in which each SI is selected through a unicast transfer. To reduce the complexity of the selector, one selector is associated with a number of SIs corresponding to the width of the data interconnect (that determines the width of the configuration vector). For the UDec platform 26 SIs can be associated to one Selector. Depending on the number of SIs, several Selectors can be distributed along the bus infrastructure.

Since the selection is performed through a transfer on the bus, the SIs targeted by the selection process are ready to receive configuration data after 5 cycles. However, taking into account the pipeline nature, a data transfer can be initialized by the configuration manager with a delay of one clock cycle after the selection data has been sent to the MI. This delay is sufficient to guarantee that the targeted SIs are ready when the first configuration data arrives.

This section has detailed the configuration infrastructure highlighting main features and providing an in-depth analysis of the latency. Next sections focus on the two-step validation process. First the SystemC/VHDL mixed model is described, then the FPGA prototype is detailed.

V. SYSTEMC/VHDL MIXED VALIDATION

To validate our contribution we propose to analyze the configuration infrastructure through a mixed SystemC/VHDL simulation model based on the platform presented in Section II. For this purpose, a complete Cycle and Bit Accurate SystemC [START_REF] Grotker | System Design with SystemC[END_REF] model of the proposed bus architecture was implemented. Then, this model was connected to a VHDL model of the multi-ASIP platform (which was already available) to allow a mixed SystemC/VHDL simulation. Finally, A non-timed SystemC model was developed to simulate the configuration manager (which is in charge of the configuration generation based on parameters set by the designer). The goal of this mixed model was to validate and to provide early evaluation of the proposed bus architecture through realistic configuration scenarios. The Input interface distributes the received symbols in the Input memories of each DecASIP. A verification module compares original symbols with decoded symbols to evaluate the decoding performance. Finally, A controller is used to manage the platform. In Fig. 6, data and control flow are highlighted with full black and broken lines respectively. On the SystemC model side, 1 Selector and 5 SIs are implemented. Each SI is connected to a configuration memory: 4 De-cASIP configuration memories Conf. Mem. and one configuration memory associated with the controller of the platform. This last memory is used to configure the modules of the platform (see Section II-B). For clarity reasons, connections between the selector and the SIs are not represented in Fig. 6. The SystemC model of the Configuration Manager allows an interaction with the designer in order to simulate complete dynamic reconfiguration scenarios. In Fig. 6, Configuration data flow is shown in doted lines.

A. Platform model

Non-timed SystemC

B. Configuration scenario

In the context of this work, the maximum configuration latency of a frame is constrained by the previous frame decoding duration as shown in Fig. 1.a. The configuration of the UDec platform is divided in three steps as shown in Fig 7 : (1) the configuration manager receives the configuration order associated with frame parameters (i.e. frame size, standard, throughput, targeted BER) necessary to generate the configuration for the DecASIPs. (2) the configuration parameters for each selected DecASIP presented in section II-B are generated. (3) the configuration parameters for each selected DecASIP configuration memory is transfered through the configuration infrastructure presented in Section IV.

The SystemC/VHDL mixed model allows to rapidly evaluate several scenarios and to verify the efficiency of the platform. In order to illustrate one possible scenario and to evaluate the performance of our approach we consider in the next subsection a typical case study in which DVB-RCS and 3GPP-LTE frames are alternatively decoded. This scenario corresponds to the reception of TV (DVDB-RCS) and web browsing (3GPP-LTE) simultaneously on the same terminal.

C. Model evaluation

The proposed SystemC/VHDL mixed model allows a fast evaluation of the configuration performance with respect to the decoding time for realistic configuration scenarios generated at run time by the configuration manager. The configuration latency of the UDec platform using the proposed approach is defined by equation 1.

Conf igurationLatency = 31 + (3.N ASIP ) F (1)
Where NASIP is the number of DecASIPs and F is the frequency of the proposed bus. 31 clock cycles are necessary to transfer the parameters common to all ASIPs and the parameters common to ASIPs of the same decoder component. 3 additional clock cycles are necessary to transfer parameters that are different for each ASIP.

Table II shows, for the two considered standards and for different data frame sizes, the ratio of the configuration loading regarding the decoding time for 4 active ASIPs and 6 decoding iterations. The last column represents the configuration time when compared to the total time required to configure and decode a frame. The configuration time is constant since the number of ASIPs is fixed. However, when the data frame size increases, the decoding time increases too. Consequently, the configuration time impact becomes negligible with high frame size (0.095% for a 3008-bit frame in 3GPP-LTE mode). When the frame size is smaller, the impact of configuration loading is still low (less than 1% for a 440-bit frame size).

The SystemC/VHDL mixed model has enabled an early and fast validation of the main features describes in Section IV. Starting from this model, next section presents the first hardware implementation on FPGA and an evaluation for an ASIC technology.

VI. HARDWARE PROTOTYPE

To validate the proposed bus architecture and communication protocol presented in section IV a hardware prototype on a Xilinx XUPV5 platform based on a Virtex 5 LX110T FPGA was developed. The prototype architecture is shown in Fig. 8. It consists of a Xilinx Microblaze soft core that generates the configuration at run-time. The configuration is then sent through an FSL bus to a FSL to MI interface. The Fast Simplex Link (FSL) [START_REF]Xilinx, FSL V2.0 specification[END_REF] connection has been considered as this interconnect structure proposes a fast, simple and unidirectional connection for the Microblaze which ease its integration within the configuration infrastructure (other interconnection solution to the Microblaze would lead to an higher complexity and lower performance). An asynchronous FIFO is associated to the FSL connection in order to provide frequency domain flexibility on both Microblaze and configuration infrastructure sides. The FSL to MI interface realizes the protocol adaptation between the FSL communication protocol and our bus protocol. Finally, the outputs of each SI are connected to a Xilinx ChipScope module that allows the run-time monitoring of these signals. This module replaces the configuration memories associated with the SIs.

The FSL bus provides a solution to transfer, each cycle, a 32-bit width data. Hence, we define an adaptation protocol in order to, starting from a 32-bit frame, extract control and data information. Fig. 9 shows the two FSL frames model used to adapt the communication protocol. Depending of the control flag, the FSL to MI interface provides a transfer initialization or a data transfer service on the bus. Fig. 9.a shows the FSL frame model sent by the Microblaze to initialize a transfer on the bus. In this case the control flag is set to 1, the flag indicates that this frame corresponds to a transfer initialization. The 8-bit component destination and the 8-bit base memory address are extracted. One cycle later, the interfaces drives MI's inputs as described in section IV-C. Fig. 9.b shows the FSL frame model sent by the Microblaze to transfer data after a transfer initialization. In this case the control flag is set to 2, the flag indicates that this frame corresponds to a data transfer. The 26-bit data is extracted from the frame and the interface drives MI's inputs as described in section IV-C.

Thanks to this hardware implementation, configuration transfer time were evaluated for several numbers of DecASIPs. For this purpose, the Microblaze and the proposed bus frequency is set to 125 MHz. The Chipscope module is configured to monitor the output signals of the SIs. Table III shows the configuration transfer times of the bus compared to designs we have implemented using CoreConnect PLB4 [8] and AMBA AXI4 [START_REF] Arm | AMBA specifications[END_REF] buses connected to a Microblaze with the same clock frequency (set up to 125MHz). Thanks to the multicast mechanisms, a low overhead of 144 ns is

Where NASIP is the number of DecASIPs and F M icroblaze is the frequency of the Microblaze and the proposed bus. 93 clock cycles are necessary to transfer the parameters common to all ASIPs and the parameters common to ASIPs of the same decoder component. 9 additional clock cycles are necessary to transfer parameters that are different for each ASIP. Compared to equation 1, the performance penalty is due to two factors. Indeed, the FSL bus used to connect the Microblaze processor to the configuration infrastructure and the protocol adaptation between the FSL bus and the MI lead to additional cycles which impact the transfer latency. Moreover, the Microblaze doesn't send one data per cycle on the FSL bus since several cycles are necessary to build the frames presented in Fig. 9 before each transfer.

However, as shown in Table III, using this solution combined with our low latency configuration infrastructure allows us to perform the configuration of up to 64 ASIPs in less than 10 µs (5.353 µs) which opens very interesting perspectives for future reconfigurable decoders.

A logical synthesis of the proposed bus components was also done with a 65nm CMOS technology with a clock frequency objective equals to 500MHz. Table IV shows the area evaluation for the three components of the proposed configuration infrastructure. The logic overhead due to the configuration infrastructure is 0.015 mm 2 which leads to a low area penalty of 2% regarding the logic area of the 4 DecASIPs (0.739 mm 2 ). The complexity of the selector is the lowest one since only a comparison with the input component address is necessary to know if the input vector has to be copied into the output or not. The complexity of the SI and MI components is quite similar. The difference is mainly due to the presence of a counter in the MI for incremental burst while 8-bit comparators is implemented in the SI for address comparison. Furthermore, considering an ASIC implementation with the frequency objective of 500 MHz, a significant speedup on the configuration transfer latencies shown in Table III can be expected compared to the 125 MHz FPGA prototype. Table V shows the estimated configuration transfer time for an ASIC implementation. Results are estimated using equation 1 with a bus frequency fixed to 500 MHz and show that a speedup of 12 can be reached compared to the FPGA implementation.

Results presented in this section show that the proposed configuration infrastructure offers an efficient solution for the UDec implementing up to 64 ASIPs. It guarantees configuration latency below 6µs providing a very low configuration latency overhead and meeting the configuration latency challenge as explained in the introduction. Furthermore, as detailed in Fig. 7, the next configuration computation and transfer is performed in parallel of the current data frame treatment. Such a solution meets future standard requirements where a code switch can be done as early as one data frame ahead [START_REF]IEEE Standard for Local and Metropolitan Area Networks Part 16: Air Interface for Fixed and Mobile Broadband Wireless[END_REF].

VII. CONCLUSION

Configuration data transfer in application specific multiprocessor platforms is still an important challenge. In this paper, we propose a configuration infrastructure that provides an efficient and low complexity solution. This work was validated through a mixed VHDL/SystemC model and an FPGA prototype for timing and area evaluation. A synthesis targeting ASIC 65nm CMOS technology was also performed. Results show that configuration of a multi-ASIP platform implementing 64 ASIPs can be achieved in 5.352 µs for an FPGA implementation. Future work targets the definition and the validation of decision algorithms to build an efficient selfadaptable multicore platform for turbo decoding in a dynamic environment.

Figure 1 .

 1 Figure 1. Configuration latency constraint and frame duration

Figure 2 .

 2 Figure 2. Turbo decoding system

Figure 3 .

 3 Figure 3. UDec system architecture example with 2x2 ASIPs

Figure 4 .

 4 Figure 4. Architecture of the proposed bus interconnect

Figure 5 .

 5 Figure 5. Communication from the configuration manager to the configuration memory through the communication infrastructure

Fig. 6

 6 Fig. 6 presents the different components implemented in the platform model. On the VHDL model side, A Random generator associated with an Emitter produce the encoded symbols. The channel model is an Additive White Gaussian Noise (AWGN).The Input interface distributes the received symbols in the Input memories of each DecASIP. A verification module compares original symbols with decoded symbols to evaluate the decoding performance. Finally, A controller is used to manage the platform. In Fig.6, data and control flow are highlighted with full black and broken lines respectively.

Figure 6 .Figure 7 .

 67 Figure 6. Architecture model for SystemC/VHDL mixed simulation

Figure

  Figure 9. FSL to MI protocol adaptation

Table III CONFIGURATION

 III [START_REF] Altera | Avalon bus specification: Reference manual[END_REF]. FSL to MI protocol adaptation TRANSFER TIME IN ns necessary to configure each additional couple of DecASIPs (one ASIP in both natural and interleaved domains) while 1936 ns and 1056 ns are necessary for [8] and[START_REF] Arm | AMBA specifications[END_REF] respectively. Results of TableIIIshow that proposed implementation significantly reduces the configuration time overhead when the number of active DecASIPs increases compared to classical bus approaches.Compared to equation 1, the performance of the proposed configuration infrastructure FPGA prototype is defined by equation 2.

	Nb.		latency (in ns)		Speedup
	ASIPs	This work	[8]	[7]		vs. [8]	vs. [7]
	4	1 032	3 872	2 212	3.75	2.14
	6	1 176	5 808	3 168	4.94	2.69
	8	1 320	7 744	4 224	5.87	3.2
	16	1 896	15 488	8 448	8.17	4.45
	32	3 048	30 976	16 896	10.16	5.54
	64	5 352	61 952	33 792	11.57	6.31
	Conf igurationLatency =	93 + (9.N ASIP ) F M icroblaze

Table V ESTIMATED

 V CONFIGURATION TRANSFER TIME IN ns FOR AN ASIC IMPLEMENTATION

	Infrastructure Component	Area (in µm 2 )
		MI			1 790
		SI			1 150
		Selector			784
	Infrastructure for 4 RdecASIPs		15 199
		4 DecASIP		738 552
			Table IV
	AREA OF THE PROPOSED CONFIGURATION ARCHITECTURE
	Nb.	Transfer latency (in ns)	Speedup
	ASIPs	FPGA	ASIC (estimated)
	4	1 032	86		12
	6	1 176	98		12
	8	1 320	110		12
	16	1 896	158		12
	32	3 048	254		12
	64	5 352	446		12