# Hardware Update through Digital TV Signals
## 5 The Proposed Hardware Reconfiguration Scheme Based on the DTV Signals
### Core Data Filtering  
A DTV receiver's resident system is configured to filter the transmitted content to find some hardware reconfiguration bitstream (core). It will look for a UIT and then parse it, beginning with hw_core_flag. If it is set to \"0x0\", it merely ignores the current UIT; otherwise, it is set to \"0x1\", where there is hardware bitstream content to be considered, and it parses the remaining UIT content (e.g., fpga_core_size, fpga_core_version, and fpga_core_module_name(0) to retrieve the corresponding table fields, which describe characteristics of a given broadcast bitstream (hardware core). Finally, such values are compared with those of the local FPGA devices as shown in Figure 7. The characteristics of the local FPGA devices can be stored in a simple text file, which is made available at a receiver's file system, as performed here.  
\begin{table}
\begin{tabular}{l c c c} \hline \hline \multirow{2}{*}{**Data Structure**} & **Bit Rate** & \multirow{2}{*}{**Mnemonic**} & \multirow{2}{*}{**Value**} \\  & **(No. of Bits)** & & \\ \hline fpga\_section\_identifier() \{ & & & \\ descriptor\_tag & 8 & uimsbf & 0x05 \\ descriptor\_length & 8 & uimsbf & \\ for (i = 0; i \textless{}N; i++) \{ & & & \\ \multicolumn{3}{c}{remount\_core\_pck\_pid} & 32 & bslbf & \\ \multicolumn{3}{c}{remount\_core\_sec\_tid} & 16 & bslbf & \\ \multicolumn{3}{c}{remount\_priority} & 8 & uimsbf & \\ \multicolumn{3}{c}{} \\ \hline \hline \end{tabular}
\end{table}
Table 7: The syntax of the descriptor FPGA_SECTION_IDENTIFIER.  
Figure 7: Steps to check the UIT content and find broadcast core hardware suitable for a receiver to retrieve the correct PIDs for filtering.  
On the one hand, if some of those fields do not match a receiver's hardware characteristics, it interrupts the reconfiguration process. Indeed, this may happen, given that the content may have been sent to another kind of receiver with different FPGA devices. On the other hand, if such content fits a receiver, it continues the filtering procedure and parses remount_core_pck_pid and remount_core_sec_tid. Those values are used as access points for extracting the transmitted reconfiguration bitstreams (for programming the section-filtering modules) directly from the private sections as depicted in Figure 8. When a private section is retrieved, its CRC is checked for validation purposes (see Section 3.1). If it is not corrupted, the receivers can store their payload according to the section order provided by section_number; otherwise, they will wait for a new section. In case of a system reset, the downloaded content is discarded, and the working memory is cleaned, being necessary to restart the bitstream remounting process.  
A receiver keeps this iterative process until the last section is received to conclude the reassembling processes. However, this procedure's completion depends on validating an entire private section's payload. If a section is not validated (e.g., it is corrupted), a reconfiguration process discards that, and the search for a valid section content continues. Given that sections may be randomly retrieved, any receiving system is responsible for ensuring the correct order.