## 3 Hardware Configuration  
The aim of this work is to give an evaluation of [PERSON]'s method for estimating error magnitudes in a received code word in Reed-Solomon code, considering practical implementations. As a benchmark for the evaluation, [PERSON]'s method was considered. The two algorithms were designed with different configurations of the \(n\), \(k\), \(t\), and \(m\) values, as shown in Table 3. Two different \(m\) values were chosen: code-words with symbols composed by 4 bits are typically used in image transmission [38; 39], while code-words with 8-bit symbols are practically implemented in Quick Response (QR) codes [14], Digital Video Broadcasting--Terrestrial (DVB-T) [40], and the Consultative Committee for Space Data Systems (CCSDS) standard for space applications [41]. Figure 5: Error magnitude evaluation with \(\
u=3\) implemented with the Lu algorithm. The blocks shown are additions, multiplications, and inversions (\((\cdot)^{-1}\)) over the Galois field. All configurations were designed to correct any number of errors \(\
u\leq t\) in the code-word. However, as the worst performance is obtained when the maximum number of errors occurs, the number of errors introduced in the code-word was set to be equal to the maximum detectable error (i.e., \(\
u=t\)). The configurations were designed for implementations both on an FPGA device and on an MCU, as different behaviors are to be expected on the two hardware devices because of the different nature of the two platforms. The FPGA platform was used to evaluate the parallelization capability of the two algorithms. For this purpose, the configurations presented in Table 3 for both the Forney and Lu algorithms were designed in full concurrent VHDL code, and results were evaluated in terms of resources' usage and delay to obtain a valid output. The platform environment is Xilinx Vivado 2019.1 and the target device was set to Artix-7 XC7A100T-CSG324 FPGA. As an example, in Figures 6 and 7, the register transfer level (RTL) results of the RS (15,11) configuration are reported. A button is pressed to begin the elaboration and a controller takes care of signaling the start by raising the _start_ signal. As the outputs of the method under the test consist of several bits (up to 128 in the worst case), it would be impossible to monitor all of them with an oscilloscope. Thus, a comparator was introduced to assert the _end_ signal when a valid data matches a constant that represents the expected value. Thus, the _test pin_ rises with the _start_ signal and falls when the _end_ signal goes high. The time between the two transitions of the _test pin_ gives the algorithm output delay. The measurements were carried out with a Tektronix DPO7254 oscilloscope, exploiting its 40 GSa/s, real-time sample rate. Exploiting the full sequential architecture of an MCU platform, the speed of the two algorithms without parallelization was evaluated. The platform environment in this case is IAR Embedded Workbench, in which the different configurations of Table 3 were coded in C language and flashed on a Texas Instruments (TI) LaunchPad XL development board. The board hosts a TI CC3200 system on chip (SoC) device, with a 32-bit architecture ARM Cortex-M4 MCU clocked at 80 MHz. This device, thanks to an embedded Wi-Fi radio module, is widely used to implement devices and systems compatible with the Internet of Things and wireless sensor network paradigms [42; 43; 44; 45; 46; 47], topics in which error correction techniques were demonstrated to gain an advantage in recent implementations [48; 49]. Data about execution speeds were collected by measuring a general-purpose input/output (GPIO) pin voltage, which was toggled inside the C code at the computation's start and end. The time between the low-to-high and high-to-low transitions gives the code execution time. The measurements were carried out by means of a Tektronix MSO 2024 oscilloscope. In Figure 9, the Forney and Lu versions of the C code flow chart for the RS (15,11) configuration are reported.