The field of nanosatellites is constantly evolving and growing at a very fast speed. This creates a growing demand for more advanced and reliable EDAC systems that are capable of protecting all memory aspects of satellites. The Hamming code was identified as a suitable EDAC scheme for the prevention of single event effects onboard a nanosatellite in LEO. In this paper, three variations of Hamming codes are tested both in Matlab and VHDL. The most effective version was Hamming [16, 11, 4]_{2}. This code guarantees singleerror correction and doubleerror detection. All developed Hamming codes are suited for FPGA implementation, for which they are tested thoroughly using simulation software and optimized.
Satellites have many applications, with earth observation (EO) being one of the primary applications. EO satellites use smart image sensors to monitor and capture data on the earth’s surface, and in some cases, infrared is used to look beneath. This information can be used to monitor urban development, vegetation growth, natural disasters, etc. With satellite imaging constantly evolving and improving, the captured information contains higher detail and improved resolution (smaller than 1 meter) making the data more useful. This is achieved, using a wide range of spectral band cameras [
The Hamming error correction and detection code were first introduced by Richard Hamming in 1950. The work initially conducted on Hamming codes allowed largescale computing machines to perform a large number of operations without a single error in the end result [
Hamming code classification and parameters.
Hamming code  Hamming (7, 4)  

Developed by  Richard Hamming  
Type  Linear block code  
Code rate 


Alphabet (Σ) 
 
Block length 


Message length 


Distance 


Notation 


The Hamming code initially started as a solution for the IBM machines that crashed when an error occurred. When the code was developed, it was considered a breakthrough but no one in 1950 could have predicted it being used to ensure data reliability onboard nanosatellites. Due to the capabilities and versatility of Hamming codes, new papers are constantly published.
EDAC codes are classified mainly according to the approach the code takes when performing error detection and correction. Hamming codes fall under the following classifications: Error detection and correction codes => Forward error correction (FEC) => Block => Binary codes. This is shown graphically in Figure
Classification of Hamming code.
A Hamming block is basically a codeword containing both the information signal (
Systematic and nonsystematic codewords.
Systematic  =[ 
Nonsystematic  =[ 
The EDAC scheme selection is almost solely dependent on its application. The work in this paper focuses on EDAC onboard a nanosatellite. This implies that a solution is needed to detect and correct errors induced by radiation onboard a nanosatellite during its low earth orbit (LEO), specifically the ZACube missions.
The ZACube missions are a series of nanosatellite missions being developed by French South African Institute of Technology (FSATI) in collaboration with Cape Peninsula University of Technology (CPUT). The name of this initial nanosatellite is the ZAcube 1 [
Ideally, the effects of singleerror upset (SEU) and multipleerror upset (MEU) should have been monitored in ZAcube 1; unfortunately, this was not done and therefore, this information is unavailable. However, this data were gathered by the Alsat1, which was the first Algerian microsatellite launched into LEO. This work was published [
Memory errors that observed on Alsat1 during a 7year period.
Event upset observation for Alsat1  

System monitored  OBC 386 RAMDISK memory 
EDAC code  RS (256,252) 
Memory size  32 Mbytes 
Hybrid  SYS84000RKXLI70 (4M × 8bit) 
Device  Samsung SEC KM684000BLT5L: 512K × 8BIT SRAM 
Observation period  2510 days November 29, 2002–October 12, 2009 
Bits monitored  268435456 
No. of singlebit errors  244150 (98.6%) 
No. of multiplebit errors  217 (0.08%) 
No. of doublebyte errors  2996 (1.21%) 
No. of severe errors  230 (0.09%) 
Using the data provided in Table
Likelihood of error occurring in a day.
Using the information shown using Table
Hamming code was selected mainly as it meets the EDAC requirements, implementation complexity is minimum and cost of additional hardware is kept minimal. For example, commercial offtheshelf (COTS) devices can be used.
In the sections to follow, a detailed overview of the Hamming code will be given. By touching on the parameters and foundation principles, the reader should have a solid understanding of the Hamming code.
Hamming code is an EDAC scheme that ensures no information transmitted/stored is corrupted or affected by singlebit errors. Hamming codes tend to follow the process illustrated in Figure
General layout of Hamming code.
The type of storage is dependent on the application, which in this paper is RAM used by the onboard computer (OBC) of a nanosatellite. It is during storage that errors are most likely to occur. Errors usually occur when radiated particles penetrate the memory cells contained within the RAM. These errors are defined as bit flips in the memory. Hamming codes are capable of SECSED but can be extended to SECDED with an additional parity bit.
The decoder is responsible for checking and correcting any errors contained within the requested data. This is done by applying the Hamming theorem, which uses a paritycheck matrix to calculate the syndrome. The decoder checks, locates, and corrects the errors contained in the codeword before extracting the new errorfree information data.
As mentioned previously, Hamming code uses parity bits to perform error detection and correction. The placement of these parity bits is dependent on whether or not the code is systematic or nonsystematic. In Table
Bit position (codeword) is dependent on the amount of data bits protected
Parity bit positions are placed according to, 2 to the power of parity bit:
2^{0} = 1, 2^{1} = 2, 2^{2} = 4, 2^{3} = 8 and 2^{4} = 16.
Parity bit’s relationship to bit position and data bits (also shown using Figure
Parity bit 1 (P1) represents bit position: 1 (P1), 3, 5, 7, etc. (all the odd numbers)
Parity bit 2 (P2) represents bit position: 2 (P2), 3, 6, 7, 10, 11, etc. (sets of 2)
Parity bit 4 (P4) represents bit position: 4 (P4), 5, 6, 7, 12, 13, etc. (sets of 4)
Parity bit 8 (P8) represents bit position: 8 (P8), 9, 10, 11, 12, 13, etc. (sets of 8)
Parity bit 16 (P16) represents bit position: 16 (P16), 17, 18, 19, etc. (sets of 16)
The position in between the parity bits are filled with data bits.
The layout makes each column have a unique parity bit combination, for each bit position.
This unique parity bit combination is known as the syndrome value.
Bit layout of Hamming code (nonsystematic).
Bit position  1  2  3  4  5  6  7  8  9  10  11  12 

14  15  16  

Encoded data bits  P1  P2  D1  P4  D2  D3  D4  P8  D5  D6  D7  D8 

D10  D11  P16  
Encoded data coverage (nonsystematic) syndrome  P1  ✗  ✗  ✗  ✗  ✗  ✗ 

✗  
P2  ✗  ✗  ✗  ✗  ✗  ✗  ✗  ✗  
P4  ✗  ✗  ✗  ✗  ✗ 

✗  ✗  
P8  ✗  ✗  ✗  ✗  ✗ 

✗  ✗  
P16  ✗ 
The syndrome allows errors to be located and corrected. For example, if parity bits P1, P4, and P8 show an error, the location of the error can be found by 1(P1) + 4(P4) + 8(P8) = 13. Therefore, the error affected data bit 9 (D9) in position 13, shown in bold. The above explanation shows the general algorithm used when implementing Hamming code.
Parity vs data: Hamming (7, 3) (a) and Hamming (15, 11) (b).
Generator matrix (
Paritycheck matrix (
The relationship between
As a final note on
Interchange two rows (or columns)
Multiply each element in a row (or column) by a nonzero number
Multiply a row (or column) by a nonzero number and add the result to another row (or column)
The Hamming encoder is responsible for generating the codeword (nbits long) from the message denoted by (
The mathematical expression in (
Gate/graphical expression of hamming encoder formula.
The Hamming decoder is responsible for generating the syndrome (
The mathematical expression in (
Gate/graphical expression of hamming decoder formula.
The extended Hamming code makes use of an additional parity bit. This extra bit is the sum of all the codeword bits (Figure
Parity relationship to data, extended Hamming (8, 4).
Bit layout of extended Hamming code (16, 11).
Bit position  1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  

Encoded data bits  P1  P2  D1  P4  D2  D3  D4  P8  D5  D6  D7  D8  D9  D10  D11  P16  
Encoded data coverage (nonsystematic) syndrome  P1  ✗  ✗  ✗  ✗  ✗  ✗  ✗  ✗  
P2  ✗  ✗  ✗  ✗  ✗  ✗  ✗  ✗  
P4  ✗  ✗  ✗  ✗  ✗  ✗  ✗  ✗  
P8  ✗  ✗  ✗  ✗  ✗  ✗  ✗  ✗  


P16, in this case, is the added parity bit that allows double error detection. By monitoring this bit and checking whether the bit is odd or even allows the double bit error to be detected, which is shown in Table
Hamming [16, 11, 4]_{2} is an extended version of Hamming code. With an additional parity bit, the code is capable of double error detection (DED). This code was implemented in a nonsystematic manner, which simplifies the detection of double errors. The construction of the generated codeword is shown in Table
Construction of the Hamming [16, 11, 4] codeword.
Codeword ( 


Information data ( 
Parity ( 

D1  D2  D3  D4  D5  D6  D7  D8  D9  D10  D11  P1  P2  P3  P4  P5 
Calculated performance aspects of Hamming [16, 11, 4].
Scheme 


Code rate (%)  Bit overhead (%) 

Hamming [16, 11, 4]_{2}  2  1  68.75  45.45 
In order to implement the Hamming [16, 11, 4]_{2}, a generator matrix (
Submatrix (
Identity matrix (
From (1), the generator matrix is calculated:
Following Hamming rules,
By considering the nonsystematic Hamming bit layout in Table
Identity matrix (
Hamming rules state
By considering the nonsystematic Hamming bit layout in Table
Once
Hamming [16, 11, 4]_{2} makes use of syndrome decoding to locate and correct any errors that occurred in the codeword during transmission or storage. The syndrome is calculated according to (
Hamming code was implemented in both Matlab and VHDL. The approach taken to achieve the desired results is explained with the help of detailed flow charts.
For each variation of the Hamming codes, a proof of concept model was designed in Matlab. The approach is outlined in Figure
Overview of Matlab code (flow chart).
Once proof of concept was established using Matlab, Quartus was used to implement the working VHDL model. The Hamming code was programmed using VHDL as it allows the behaviour of the required system to be modelled and simulated. This is a major advantage when optimization is required. A working model of Hamming [8, 4, 4]_{2} and Hamming [16, 11, 4]_{2} was programmed in VHLD using the approached detailed in Figure
Overview of VHDL code (flow chart).
In this section, the optimization of Hamming [16, 11, 4]_{2} is done. The aim of optimization is to reduce resource usages, reduce time delays, improve efficiency, etc.
There are many ways of optimizing VHDL code. Some of the main topics when it comes to optimization are [
Efficient adder implementation
State machines
Signal selection
Storage structure
Placement and Routing
In this paper, the Quartus Prime package is used to code, analyse, compile, and optimize the Hamming code.
Using the RTL viewer provided under tools in Quartus Prime, an overview of the I/O and VHDL code layout can be seen in Figure
I/O overview of VHDL code for Hamming [16, 11, 4]_{2}.
Using the RTL viewer tool, it is possible to step into both the encoder and decoder. The RTL viewer optimizes the netlist in order to maximize readability. This allows a unique insight into each VHDL code. The RTL view of the encoder and decoder is shown in Figures
RTL overview of the encoder for Hamming [16, 11, 4]_{2}.
RTL overview of the decoder for Hamming [16, 11, 4]_{2}.
The following steps are taken to optimize the code:
Remove unnecessary and redundant code
Reduce constants and variables where possible
Minimize the use of if statements and loops
Convert code to structural level or gate level
The Hamming [16, 11, 4]_{2} was reduced to structure or gate level, which resulted that all redundant codes, IF statements, loops, constants, and variables were either removed or reduced. By reducing the code to gate level, the following changes occurred:
Encoder contains no constants or variables
Encoder went from performing 320 logic (AND and XOR) bit operations to only 30 XOR operations
Decoder contains no constants
Decoder contains a reduced amount of variables
Decoder went from 2 IF statements to none and from 1 case statement to none
The results of reducing Hamming [16, 11, 4]_{2} to gate level is shown for the decoder using Figure
RTL overview of the optimized decoder for Hamming [16, 11, 4]_{2}.
Hamming codes have many communication and memory applications. They are extremely popular for their effectiveness when it comes to correction of singlebit flips and the detection of doublebit flips.
Hamming [16, 11, 4]_{2} allows SECDED, while providing a better code rate and bit overhead than standard Hamming codes. Hamming [16, 11, 4]_{2} generates a codeword of doublebyte size, which is convenient as most memory blocks work on a byte standard. The code was implemented in VHDL on both a behaviour/dataflow and gate level (optimized) during implementation. Hamming [16, 11, 4]_{2} code was optimized from a resource reduction and timing approach, after which it was tested thoroughly using software techniques.
The toplevel design in Figure
Functional block diagram of Hamming [16, 11, 4]_{2}.
Using software, the developed Hamming code is tested and analysed. This is done on three levels, namely, functionality (ModelSim), resource usage (compilation report), and timing analysis (TimeQuest). An overview of the tested VHDL code is shown in Figure
Full RTL overview of VHDL code for Hamming [16, 11, 4]_{2}.
Hamming [16, 11, 4]_{2} is capable of singleerror correction and doubleerror detection. With the help of ModelSim, this is clearly shown in Figure
All registers are cleared using the clear signal “clr” (this is shown using
Singlebit errors are introduced in memory using a bit flip in data_to_memory (bits 0 to 15) and flagged by SEC (this is shown using
Doublebit errors are introduced in memory using bit flips in data_to_memory (bits 0 to 15) and flagged by DED (this is shown using
Note: thanks to Hamming [16, 11, 4], dataout is unaffected by singlebit errors and only gets cleared upon the detection of doublebit errors.
ModelSim simulation of Hamming [16, 11, 4] SECDED capabilities.
In this paper, EDAC schemes are extensively discussed. ZAcube 2 nanosatellite was used as a case study when conducting research on space radiation, error correction codes, and Hamming code. All findings, results, and recommendations are concluded in the sections to follow.
Space radiation has caused numerous mission failures. Through research, it became apparent that failures caused by SEU and MEU are extremely common and SEEs are more frequent while the nanosatellite is in the SAA. It was found that there are a number of EDAC schemes and techniques currently used, most commonly Hamming, RS codes, and TMR. The EDAC schemes are usually implemented using an FPGA. From the literature survey, it is clear that there is a need for research in the area of EDACs. By conducting an indepth literature review, it was established that Hamming code was capable of performing the functionality desired.
In order to understand space radiation, a study was conducted using the orbital parameters of nanosatellite ZACube 2. This radiation study was conducted using OMERE and TRIM software which allows the simulation of earth radiation belts (ERBs), galactic cosmic radiation (GCR), solar particle events (SPE), and shielding. In the case of ERBs, protons of a maximum integral flux of 1.65 × e^{3}°cm^{−2}·s^{−1} flux at energy ±100 KeV were trapped, which decays to a minimum integral flux of 1.55 cm^{−2} s^{−1} flux at energy ±300 MeV. It was found that the common nanosatellite casing of 2 mm Al is only effective as a shield against protons below 20 MeV and heavy ions below 30 MeV. In order to ensure that SEE does not occur, additional mitigation techniques are needed to protect sensitive/vulnerable devices. These techniques could be triple modular redundancy (TMR), software EDAC schemes, and others.
There are two types of ECC, namely, error detection codes and error correction codes. For protection against radiation, nanosatellites use error correction codes like Hamming, Hadamard, Repetition, Four Dimensional Parity, Golay, BCH, and Reed Solomon codes. Using detection capabilities, correction capabilities, code rate, and bit overhead, each EDAC scheme is evaluated. The evaluation of Hamming codes is shown in Table
Evaluation of Hamming code.
Schemes ( 


Code rate (%)  Bit overhead (%)  

Hamming  
7  4  3  1  1  57.14  75.00 
15  11  3  1  1  73.33  36.36 
31  26  3  1  1  83.87  19.23 
63  57  3  1  1  90.48  10.53 


Extended hamming  
8  4  4  2  1  50.00  100.00 
16  11  4  2  1  68.75  45.45 
64  58  4  2  1  90.63  10.34 
1024  1017  4  2  1  99.32  0.69 
Hamming codes are classified as error detection and correction codes that are forward error correction block binary codes. These codes are based on the use of parity bits which allows EDAC using a generator matrix and a paritycheck matrix. Normal Hamming codes make use of a syndrome decoder which ultimately allows the error to be located. Once located, the error is corrected to its original state. Three variations of Hamming was designed and tested during the completion of this paper. A short summary of these codes is shown in Table
Summary of developed codes.
Hamming scheme  Variation  Approach  Capabilities  Improvements  Matlab model  VHDL model 

Hamming [7, 4, 3]_{2}  Original  Systematic  SECSED  None  Yes  Yes 
Hamming [8, 4, 4]_{2}  Extended  Nonsystematic  SECDED  Hamming distance  Yes  No 
Hamming [16, 11, 4]_{2}  Extended  Nonsystematic  SECDED  Hamming distance, overhead, and code rate  Yes  Yes 
Hamming [16, 11, 4]_{2} was then converted to gate level and optimized from a resource approach and timing approach. The results of the optimized code are shown in Table
Original vs optimized Hamming compression.
Hamming [16, 11, 4]_{2}  

Description  Original  Resource reduction  Timing reduction  
Resource summary  ALM  12  12  12 
ALUT  13  13  13  
7input  0  0  0  
6input  7  2  7  
5input  0  0  0  
4input  0  0  0  
≤3input  6  22  6  
Dedicated logic registers  24  24  24  
I/O pins  27  27  27  
Max fanout  24  24  24  
Total fanout  165  145  165  
Average fanout  1.81  1.59  1.81  


Timing analysis  Clock period  1 ns  2.25 ns  1.8 ns 
From node  Datain_s[5]  Datain_s[2]  Datain_s[8]  
To node  Dataout_s[10]∼reg0  Dataout[1]∼reg0  Dataout[8]∼reg0  
Data arrival time  5.624 ns  5.987 ns  5.394 ns  
Data required time  4.827 ns  6.076 ns  5.491 ns  
Slack  −0.797 ns (violation)  0.089 ns  0.097 ns 
In this paper, a detailed look at different EDAC schemes, together with a code comparison study was conducted. This study provides the reader with a good understanding of all common EDAC schemes, which is extremely useful should different EDAC capabilities be needed.
Hamming code was extensively studied and implemented using different approaches, languages, and software. The final version of the Hamming code was Hamming [16, 11, 4]_{2}. This code allows SECDED. Using only 12 adaptive logic modules (ALMs), the code is extremely small, meaning the selected FPGA will consume a minimal amount of power. By optimizing the resource usage, the average fanout can be reduced from 1.81 to 1.59 and runs on a period of 1.8 ns with no violation and an arrival time of 5.987 ns. When optimized from a timing perspective, the code can be optimized to runs off a clock period of 1.8, with no violations and an arrival time of 5.394 ns.
Due to Hamming [16, 11, 4]_{2} resource usage of the original code already being so small, the timing optimization approach is recommended it is 0.593 ns faster. This implies that a Hamming code was developed capable of protecting 11 bits of information against SEU and capable of DED. The code is capable of reading and writing to memory within 5.394 ns using only 12 ALMs and 24 registers.
The data from Alsat1 is considered as a worst case scenario. This means Hamming [16, 11, 4]_{2} is theoretically capable of preventing all singlebit errors (SBE) or ±98.6% of all SEUs experienced onboard ZAcube 2. Hamming [16, 11, 4]_{2} detection capability also allows the prevention of some multiplebit errors (MBE). Should the nanosatellite be traveling through the South Atlantic Anomaly (SAA), it is possible to implement triple modular redundancy (or a similar EDAC scheme) together with Hamming [16, 11, 4]_{2}. This will equip the nanosatellite to deal with doublebyte errors and severe errors.
The field of nanosatellites is constantly evolving and growing at an astonishing pace! This is due to the fact that it provides a platform from which the boundaries of space and technology are constantly being pushed. As technology advances memory chip cell architecture is becoming more and denser, especially with the development of nanotechnology. This creates a growing demand for a more advanced and reliable EDAC system that is capable of protecting all memory aspects of satellites. The code developed in this paper guarantees SECDED at fast speeds.
In this paper, EDAC schemes with a focus on Hamming codes are extensively discussed and studied. The ZAcube 2 nanosatellite was used as a case study when conducting research on error correction codes, Hamming codes, and the optimizing of Hamming codes.
The data wherever required is referenced in the paper.
The authors declare that they have no conflicts of interest.