Efficient Interleaver Architecture for Modern Global Navigation Satellite Systems

Abstract

In modern Global Navigation Satellite Systems (GNSS), interleavers are essential for improving system performance. However, limited research has focused on interleaver hardware optimization specifically for GNSS, primarily due to GNSS authorities strictly adhering to Interface Control Documents (ICDs), which discourage significant deviations in hardware implementations. Traditional GNSS interleavers employ double buffering and typically require extensive hardware resources, specifically 2N registers and 2(N $-$ 1) $+$ 1 multiplexers (MUXs), leading to increased complexity, power consumption, and latency. To bridge this gap, this paper presents a novel and efficient interleaver hardware architecture optimized specifically for modern GNSS by leveraging Lifetime Analysis and Forward–Backward Register Allocation. Lifetime Analysis precisely identifies the minimum number of registers necessary, and Forward–Backward Register Allocation ensures efficient utilization of these resources under continuous operation. Experiments were conducted for all seven currently used GNSS interleaving configurations. Synthesis results, obtained using a standard 28 nm Complementary Metal-Oxide Semiconductor (CMOS) process, demonstrate significant reductions in chip area (38.82% reduction), power consumption (52.01% reduction), and latency (25.05% improvement) compared to conventional architectures. These benefits become increasingly critical as the interleaver data length N continues to grow, providing a practical, ICD-compliant solution for resource-constrained satellite payloads and receiver designs.

1. Introduction

Global Navigation Satellite Systems (GNSS) are essential infrastructures that provide positioning, navigation, and timing (PNT) services, crucial for various modern applications, including transportation, telecommunications, and national security [1]. Initially introduced through the Global Positioning System (GPS) by the United States in 1978, GNSS technology has significantly evolved, expanding globally with systems such as Russian GLONASS, European Galileo, Chinese BeiDou Navigation Satellite System (BDS), Japanese Quasi-Zenith Satellite System (QZSS), and Indian Navigation with Indian Constellation (NavIC) [2]. Among these, QZSS and NavIC are Regional Navigation Satellite Systems (RNSS), designed to provide regional coverage optimized for their respective service areas. Additionally, BDS has expanded from regional to global coverage. Early GNSS, such as GPS L1 C/A and GLONASS L1OF, provided fundamental navigation services using simple data structures with minimal error correction capabilities [3,4]. However, as GNSS services expanded globally and their applications became increasingly critical, the demand for enhanced reliability and data integrity significantly increased. To address these evolving needs, modern GNSS signals have adopted more sophisticated signal structures and advanced error-correcting techniques. For example, early GNSS signals like GPS L1 C/A employed basic error-correction algorithms such as Cyclic Redundancy Check (CRC) and Bose–Chaudhuri–Hocquenghem (BCH) codes, which can only correct a limited number of bit errors. In contrast, modern GNSS signals incorporate advanced methods such as Low-Density Parity-Check (LDPC) codes, offering significantly superior error-correcting capabilities, and symbol-based Reed–Solomon (RS) codes [5].

Moreover, combining interleaving with Forward Error Correction (FEC) significantly enhances error-correcting performance [6]. Interleaving is an effective technique used in communication systems to mitigate burst errors by rearranging encoded data, thus converting burst errors into random errors, which are more effectively corrected by FEC algorithms [7]. Recently developed GNSS signals increasingly adopt interleavers to enhance data reliability and system robustness.

Table 1. Summary of GNSS/RNSS signals and interleaver usage.

Constellation	Signal	Type	Interleaver Size	Year
GPS	L1C/A	GNSS	$-$	1978
	L2C	GNSS	$-$	2005
	L5	GNSS	$-$	2010
	L1C	GNSS	38 $\times$ 46	2018
GLONASS	L1OF	GNSS	$-$	1982
	L2OF	GNSS	$-$	2003
	L3OC	GNSS	$-$	2003
	L2OC	GNSS	$-$	2011
	L1OC	GNSS	$-$	2017
Galileo	E1B	GNSS	8 $\times$ 30	2011
	E5a	GNSS	8 $\times$ 61	2011
	E5b	GNSS	8 $\times$ 30	2011
	E6B	GNSS	8 $\times$ 123	2011
BDS	B1I	GNSS	2 $\times$ 15	2007
	B2I	GNSS	2 $\times$ 15	2007
	B3I	GNSS	2 $\times$ 15	2007
	B2a	GNSS	$-$	2015
	B2b	GNSS	$-$	2015
	B1C	GNSS	36 $\times$ 48	2015
QZSS	L1C/A	RNSS	$-$	2010
	L2C	RNSS	$-$	2010
	L5	RNSS	$-$	2010
	L1C	RNSS	38 $\times$ 46	2010
	L1C/B	RNSS	$-$	2021
NavIC	L5 SPS	RNSS	8 $\times$ 73	2013
	S SPS	RNSS	8 $\times$ 73	2013
	L1 SPS	RNSS	38 $\times$ 46	2023

Note. Signal specifications are based on official ICDs, and broadcasting years are referenced from International GNSS Service (IGS) Multi-GNSS Experiment (MGEX) constellation service pages: GPS [3,8,9,10], Galileo [11,12,13,14], GLONASS [4,15], BDS [16,17,18,19], QZSS [20,21], and NavIC [22,23].

summarizes the interleaver adoption status in major GNSS signals, highlighting the transition from early systems without interleaving to modern GNSS signals extensively employing interleavers. As indicated in Table 1, modern GNSS signals significantly incorporate interleavers, emphasizing the importance of robust error correction and improved signal integrity.

Many studies have addressed interleaver optimization in communication systems, such as 4G Long-Term Evolution (LTE) and 5G New Radio (NR), to enhance hardware efficiency in terms of area, power consumption, and latency [24,25,26,27,28]. However, limited research has focused on interleaver hardware optimization specifically for GNSS, primarily due to GNSS authorities strictly adhering to Interface Control Documents (ICDs), thus discouraging significant deviations in hardware implementations. Due to stringent requirements for power efficiency, low complexity, and compact hardware implementation, GNSS urgently require efficient hardware design solutions [29,30,31]. To bridge this gap, this paper presents a novel and efficient interleaver hardware specifically developed for modern GNSS constellations. An innovative architecture is proposed utilizing two powerful Very-Large-Scale Integration (VLSI) optimization techniques: Lifetime Analysis and Forward–Backward Register Allocation. We implement both conventional and proposed architectures for all interleaver sizes listed in Table 1 and demonstrate significant reductions in hardware complexity, area, power consumption, and latency. The proposed interleaver architecture offers practical advantages for both satellite payloads and GNSS receivers and is suitable for existing GNSS constellations as well as emerging navigation systems [32].

The remainder of this paper is organized as follows. Section 2 presents the theoretical background and analyzes conventional GNSS interleaver structures. Then, Section 3 introduces the proposed optimization methodology and describes the novel interleaver architecture. Section 4 presents experimental results comparing the proposed architecture against conventional designs. Finally, Section 5 concludes the paper and summarizes the key contributions.

2. Background

GNSS transmits PNT data from satellites to terrestrial receivers through structured signal processing stages, as depicted in Figure 1 [33]. In modern satellite payloads, navigation data are encoded using FEC techniques to ensure robust data integrity during transmission. Subsequently, the encoded data undergo interleaving, rearranging bits across multiple frames to enhance error correction capability. The interleaved bits are then modulated, converting digital data into suitable radio frequency (RF) signals for reliable transmission. In contrast, incoming signals at the receiver front end undergo a reverse sequence of processing steps. The received signals are demodulated, deinterleaved, and decoded using FEC algorithms to correct transmission errors and restore accurate navigation data.

During transmission channels from satellites to terrestrial receivers, GNSS signals typically encounter two primary types of errors: random errors and burst errors. Random errors occur sporadically and are primarily attributed to clock errors, orbital errors, ephemeris inaccuracies, tropospheric delays, ionospheric delays, receiver clock instabilities, and thermal noise. Conversely, burst errors affect consecutive bits and are generally caused by ionospheric scintillation, multipath effects, and signal blockage [1]. To handle these errors, FEC techniques are typically employed, with their error-correction capability defined based on fixed-length data frames. For example, a BCH (n, k, t) code encodes a k-bit message into an n-bit codeword, enabling correction of up to t bit errors per codeword. However, despite these measures, burst errors can often surpass the correction capability of standard FEC codes, especially when multiple consecutive errors occur within a single frame, potentially causing critical decoding failures [34].

To enhance robustness against burst errors, interleaving is commonly employed in modern GNSS as a data rearrangement technique [35]. It redistributes encoded bits across multiple frames, transforming burst errors into random-like errors manageable by FEC. Figure 2 illustrates the operation of an $N_R\times N_C$ block interleaver, where $N_R$ and $N_C$ represent the number of rows and columns, respectively. Data bits are typically filled into this interleaver matrix column-wise and read out row-wise, or vice versa. This rearrangement disperses consecutive bits across separate frames, ensuring burst errors encountered during transmission are distributed across multiple code words. For instance, Figure 3 illustrates an FEC scheme capable of correcting 1 bit error per 5-bit frame combined with a 5 $\times$ 3 block interleaver structure. Without interleaving, as shown in Figure 3a, a burst error concentrated within a single frame can exceed the FEC correction capability, leading to decoding failures. In contrast, Figure 3b illustrates that with interleaving, burst errors are effectively distributed across multiple frames, enabling each frame to remain within the correction limits of the FEC. At the receiver, a deinterleaver restores the interleaved data stream to its original order by performing the inverse index mapping of the block interleaver. Since interleaving and deinterleaving form a mathematically symmetric pair, the same optimization framework can be applied by constructing an allocation schedule for the inverse mapping. Through this transmit-receive rearrangement process, burst errors are dispersed across multiple frames, thereby creating conditions under which FEC can correct errors more effectively.

Thus, interleaving significantly enhances the effectiveness of FEC algorithms, improving the reliability and accuracy of GNSS data recovery, particularly in environments susceptible to burst errors. In addition, Figure 4 illustrates a typical 5 $\times$ 3 interleaver architecture consisting of 2N registers, 2(N $-$ 1) $+$ 1 multiplexers (MUXs), and dedicated control logic, where N = $N_R\times N_C$ [36]. During the write operation, input data bits are sequentially stored in registers following normal order. Conversely, during the read operation, data bits are retrieved from these registers in an interleaved sequence predetermined by the $N_R\times N_C$ interleaving matrix, as depicted in Figure 2. The associated control logic manages this read–write sequence by generating appropriate control signals, allowing the MUX tree to select the required data bit from among N registers. Furthermore, a double buffering scheme is crucial to prevent data collisions and ensure continuous operation in this conventional interleaver structure. Specifically, while one register array is being filled with incoming data in normal order, the other simultaneously outputs previously interleaved data. Figure 5 illustrates the timing diagram corresponding to the architecture shown in Figure 4. During the initial 15 clock cycles, Register Array 0 stores bits A0 through O0 sequentially in normal order. In the subsequent 15 clock cycles, these stored bits are read through the MUX tree in an interleaved sequence according to the 5 $\times$ 3 interleaving pattern. Concurrently, during the same 15 clock cycles, Register Array 1 is filled sequentially with bits A1 through O1.

Although the conventional interleaver architecture effectively supports data rearrangement, it demands substantial hardware resources, specifically 2N registers and 2(N $-$ 1) $+$ 1 MUXs. Although Figure 2, Figure 3, Figure 4 and Figure 5 illustrate examples with N = 15, practical modern GNSS interleavers employ significantly larger values for $N_R$ and $N_C$, thus resulting in considerably larger [1]. As shown in Table 1, the largest practical values of $N_R$ and $N_C$ are 38 and 46, respectively, leading to a significantly large value of N = 1748. Since hardware complexity directly scales with N, increased values inevitably result in greater implementation complexity, chip area, and power consumption. Moreover, the inherent latency introduced by double buffering adversely impacts GNSS system responsiveness. These hardware-intensive requirements present significant challenges for resource-constrained GNSS applications, including satellite payloads and receiver designs, emphasizing the critical need for optimized interleaver architectures to effectively address these constraints [37].

3. Proposed Interleaver Architecture

The primary objective of the proposed GNSS interleaver architecture is to minimize hardware resource usage, particularly focusing on delay registers. To achieve this goal, this paper employs two well-established VLSI digital signal processing (DSP) optimization methods, Lifetime Analysis and Forward–Backward Register Allocation. These techniques were first introduced by K. K. Parhi and have been widely recognized for their ability to significantly improve hardware efficiency in real-time digital system implementations [38,39]. In this chapter, these optimization methodologies are described and demonstrated through a detailed application to a 5 $\times$ 3 block interleaver structure. First, Lifetime Analysis is performed to precisely determine the minimum number of registers required for the interleaver implementation. Then, an efficient Forward–Backward Register Allocation is described to efficiently reuse those registers over time. Finally, we introduce the proposed interleaver architecture, which integrates both optimization techniques. Throughout this chapter, the 5 $\times$ 3 interleaver structure is consistently employed to maintain clarity and validate the effectiveness of the proposed methods.

3.1. Life Time Analysis

Conventional GNSS interleaver architectures employ double buffering, requiring 2N registers to support continuous data operation. However, this approach often results in substantial hardware redundancy, as many registers remain idle during specific phases of the interleaving process [40]. To address this inefficiency, Lifetime Analysis is employed to accurately determine the minimum number of registers required for implementation.

In an $N_R\times N_C$ block interleaver, the lifetime of a data sample is defined as the interval between its input and output [41]. Data are typically written into registers in natural order and read in interleaved order, creating a timing misalignment between each input and output. Thus, precise analysis of this timing difference is critical to minimizing register usage. For a data sample at position ($n_r$, $n_c$), where 0 $\le$ $n_r<$ $N_R$ and 0 $\le$ $n_c<N_C$, the input time $T_{in}$ and zero-latency output time $T_{zlout}$ are computed as:

$$T_{in}=n_c+N_C{n}_r$$

(1)

$$T_{zlout}=n_r+N_R{n}_c$$

(2)

where $T_{in}$ denotes the clock cycle at which the sample is written, $T_{zlout}$ represents the clock cycle at which the sample would ideally be read without latency. To illustrate this, consider a 5 $\times$ 3 block interleaver structure and a data sample labeled G, positioned at $n_r$ = 2, $n_c$ = 0, as depicted in Figure 2. Using Equations (1) and (2), the input and zero-latency output times for sample G are calculated as, $T_{in}=0+\left(3\times 2\right)=6$, $T_{zlout}=2+\left(5\times 0\right)=2\left(5\times 0\right)=2$. In this case, the output is scheduled at clock cycle 2, four cycles earlier than its input at clock cycle 6. It is clear that this time difference violates causality.

To evaluate causal implementability, the time difference should be considered as follows:

$$T_{diff}=T_{zlout}-T_{in}=\left(N_R-1\right)n_c-\left(N_C-1\right)n_r$$

(3)

A negative value of $T_{diff}$ indicates that the architecture attempts to output future data before it is written, which is physically unrealizable [42]. For sample G, $T_{diff}$ $=2-6=-4$, meaning the output would require access to a sample four cycles ahead. To resolve this issue, a global latency offset equal to $\left|min\left(T_{diff}\right)\right|$ across all samples is added to all output timings. The actual output time is thus given by:

$$T_{out}=T_{zlout}+\left|\mathrm{m}\mathrm{i}\mathrm{n}\right\{T_{diff}|T_{diff}<0\}|$$

(4)

In the 5 $\times$ 3 interleaver case, assuming $\left|min\left(T_{diff}\right)\right|$ = 8, the latency offset is 8 cycles. Accordingly, the output time of sample G is adjusted to $T_{out}=2+8=10$. As a result, sample G remains active in the system from cycle $T_{in}=6$ to $T_{out}=10$.

The complete lifetime information for all samples in the 5 $\times$ 3 block interleaver is summarized in

Table 2. Lifetime table for 5 $\times$ 3 sequential block interleaver.

Sample	${\mathit{T}}_{\mathit{i}\mathit{n}}$	${\mathit{T}}_{\mathit{z}\mathit{l}\mathit{o}\mathit{u}\mathit{t}}$	${\mathit{T}}_{\mathit{d}\mathit{i}\mathit{f}\mathit{f}}$	${\mathit{T}}_{\mathit{o}\mathit{u}\mathit{t}}$	Life Period
A	0	0	0	8	0 $\to$ 8 (8)
B	1	5	4	13	1 $\to$ 13 (12)
C	2	10	8	18	2 $\to$ 18 (16)
D	3	1	$-$2 *	9	3 $\to$ 9 (6)
E	4	6	2	14	4 $\to$ 14 (10)
F	5	11	6	19	5 $\to$ 19 (14)
G	6	2	$-$4 *	10	6 $\to$ 10 (4)
H	7	7	0	15	7 $\to$ 15 (8)
I	8	12	4	20	8 $\to$ 20 (12)
J	9	3	$-$6 *	11	9 $\to$ 11 (2)
K	10	8	$-$2 *	16	10 $\to$ 16 (6)
L	11	13	2	21	11 $\to$ 21 (10)
M	12	4	$-$8 **	12	12 $\to$ 12 (0)
N	13	9	$-$4 *	17	13 $\to$ 17 (4)
O	14	14	0	22	14 $\to$ 22 (8)

Note. Values with $T_{diff}<0$ are marked with *; the minimum with **.

, listing the input time $T_{in}$, $T_{zlout}$, $T_{diff}$, and $T_{out}$ for each data sample. This lifetime data forms the basis for calculating the number of concurrently active samples at each cycle [38,39]. Additionally, Figure 6 illustrates the timing relationship among $T_{in}$, $T_{zlout}$, and $T_{out}$ for the 5 $\times$ 3 block interleaver. In this configuration, six of the fifteen samples exhibit negative $T_{diff}$ values, indicating violations of causality. Sample M presents the most severe violation, with $T_{diff}=-$8, determining the global latency offset. By shifting all zero-latency output times by 8 clock cycles, the adjusted timing chart ensures causal validity for all outputs, defining the earliest feasible implementation schedule [43].

Based on the lifetime data in Table 2, a Lifetime Chart illustrating register activity over time can be constructed, as shown in Figure 7. This chart clearly indicates the required number of registers at each clock cycle by showing each data sample’s active period from $T_{in}$ to $T_{out}$ [44]. The horizontal axis represents clock cycles, and each bar corresponds to the active period of an individual data sample. The number of concurrently active samples at a specific clock cycle directly indicates the number of registers required at that moment. For instance, at clock cycle 10, eight samples (B, C, E, F, G, H, I, J) are concurrently active, indicating that at least eight registers are necessary at this point. Thus, the maximum number of concurrently active samples during the entire interleaving process defines the minimum number of registers required for implementation.

This value represents the worst-case scenario for register usage from natural-order input to interleaved-order output. While this analysis provides a lower bound for a single interleaving cycle, practical systems must consider continuous data streaming. Specifically, sequential block interleavers require analyzing overlapping lifetimes across consecutive interleaving cycles. In such continuous-operation scenarios, the total number of required registers depends on the combined number of samples remaining active from the end of the $i$-th interleaving period and new samples entering at the start of the ($i+1$)-th period. According to Figure 7, even when considering continuous data flow into the subsequent interleaving period, the maximum number of concurrently active samples remains eight. This result indicates that only eight registers are necessary to support continuous operation of the $5\times 3$ block interleaver without any additional hardware or data collision.

3.2. Forward–Backward Register Allocation

As shown in Figure 4, the conventional $5\times 3$ block interleaver typically requires 30 registers for continuous data processing. However, the lifetime analysis, as shown in Figure 7, indicates that only eight registers are necessary. Thus, an efficient register allocation strategy is essential as the next step toward hardware implementation to effectively utilize this minimal set. In the proposed interleaver architecture, a Forward–Backward Register Allocation based on data lifetime information is utilized. This method assigns incoming data samples first in a forward manner and then, for samples with remaining lifetimes, reallocates registers in a backward manner [45]. To clarify this approach, consider the minimal set of eight registers labeled R0 through R7, each assumed to have a shift-register structure. Initially, incoming data samples are sequentially assigned to registers starting from R0 and shifted forward each clock cycle using forward allocation. Data samples with lifetimes of eight cycles or fewer expire naturally before reaching the final register R7, thus requiring only forward allocation. However, samples whose lifetimes exceed eight cycles remain active upon reaching the final register R7, necessitating backward allocation. In these cases, backward allocation reassigns the samples to available registers previously occupied by samples whose lifetimes have expired. As lifetime analysis guarantees a maximum of eight concurrently active samples, availability of registers for backward reallocation is always ensured [46].

Figure 8 presents the Register Allocation Table for the optimized $5\times 3$ block inter leaver using the Forward–Backward approach. The horizontal axis indicates the eight registers (R0 to R7) determined by lifetime analysis, while the vertical axis represents clock cycles. Data samples A through O enter sequentially in natural order from cycle 0 to cycle. Furthermore, the proposed optimized allocation approach ensures efficient register utilization both within a single interleaving cycle and across consecutive cycles under continuous data flow conditions. Unlike the conventional structure that requires double buffering to prevent data collisions, the proposed register allocation shown in Figure 8 enables continuous and collision-free input/output interleaving with only eight registers.

3.3. Detailed Interleaver Hardware Architecture

Based on the previously described register minimization and efficient allocation methods, this section details the proposed hardware architecture for the $5\times 3$ block interleaver. Figure 9 illustrates the optimized hardware implementation, clearly highlighting the minimal number of registers and MUXs required. Specifically, the data paths are color-coded for clarity: forward reallocation in black, backward reallocation in blue, and output selection in red. The proposed architecture consists of eight registers, eight MUXs, and associated control circuits. The eight registers, labeled R0 through R7 as determined by Lifetime Analysis, are arranged in a shift-register configuration. Original data enter sequentially into register R0 and shift forward through subsequent registers with each clock cycle.

The conventional interleaver shown in Figure 4 requires double buffering and utilizes 30 registers to ensure continuous data processing. However, the proposed architecture efficiently achieves the same interleaving operation using only eight registers. Specifically, Forward Allocation is applied to data samples with lifetimes of eight cycles or fewer, as these samples naturally expire before reaching the final register R7. Conversely, Backward Allocation is employed for samples with lifetimes exceeding eight cycles, as these samples remain active upon reaching R7. These active samples are reassigned backward into previously freed registers, maximizing register reuse.

Additionally, the proposed architecture significantly reduces MUX requirements. Specifically, four MUXs are strategically placed between registers to enable backward data reallocation, guided by the Register Allocation Table shown in Figure 8. Another four MUXs are employed at the output stage to select the final interleaved outputs. Unlike the conventional structure, which requires N − 1 MUXs per register array, yielding a total of 29 MUXs, the proposed design restricts output selection specifically to the input, R1, R3, R5, and R7, thereby reducing the MUX count to eight. Lastly, the control logic systematically manages data movement and register selection, ensuring continuous and collision-free operation aligned with the proposed allocation strategy. In particular, the output MUX logic is derived from the Register Allocation Table in Figure 8, where the output selection at each clock cycle is determined by the register index in which the corresponding data sample was stored at the end of its lifetime. The highlighted region in Figure 8 represents the final output sequence obtained by rearranging data samples A ~ O according to the defined interleaving rule. In the $5\times 3$ example, the interleaved data are restricted to be output from one of the following locations: the input, R1, R3, R5, and R7. Accordingly, the output stage in Figure 9 constructs the final interleaved sequence by hierarchically selecting the stored values from these registers using a cascade of 2-to-1 MUXs.

The control path, as shown in Figure 9, consists of a counter and a decoder, where the counter generates a cycle index indicating the current position within a block. The decoder takes this index as an input and generates the SEL signals for each MUX according to the predefined selection rule. This coordinated control enables deterministic register-to-register data reallocation and output selection at every clock cycle, thereby supporting continuous data streaming without register collisions.

Furthermore, Figure 10 presents the timing diagram of the proposed block interleaver, clearly demonstrating its operational advantage over the conventional structure shown in Figure 5. While the conventional interleaver requires numerous registers, many of which remain idle during operation, the proposed architecture achieves equivalent interleaving functionality with only eight registers and fully eliminates idle states. The timing diagram confirms complete register utilization, highlighting the improved efficiency of the proposed method. Lastly, the conventional double buffering approach introduces latency equal to the data length N. For example, when N = 15, outputs are produced 15 clock cycles after inputs. In contrast, the proposed architecture employs a global latency offset derived from Lifetime Analysis, enabling outputs to begin earlier specifically after only eight clock cycles. As a result, the proposed interleaver architecture ensures continuous data streaming with significantly reduced latency. Compared to the conventional double buffering structure, the earlier output start directly reduces the baseband processing latency of the interleaver stage. Consequently, the proposed design can also contribute to lowering the overall end-to-end latency in practical GNSS processing pipelines. As a result, this optimized hardware architecture significantly reduces the required number of registers and MUXs, leading to decreased hardware complexity, power consumption, and chip area. Simultaneously, it enhances latency performance, making it more suitable for efficient GNSS signal processing applications.

4. Experimental Results

To evaluate the effectiveness of the proposed interleaver architecture, several interleavers employed in modern GNSS signals listed in Table 1 were implemented. The performance of the proposed architecture was compared against the conventional architectures across seven interleaving configurations corresponding to the following signals: GPS L1C; BDS B1C, B1I, B2I, and B3I; Galileo E1B, E5a, E5b, and E6B; QZSS L1C; and NavIC L1 SPS, L5 SPS, and S SPS. Note that certain signals share identical interleaving schemes. Quantitative comparisons of hardware resource utilization between conventional and proposed architectures were first analyzed. Figure 11 clearly compares the required number of registers and MUXs, highlighting significant reductions achieved by the proposed architecture. Conventional architectures, depicted in Figure 4, typically require double buffering and extensive multiplexing to maintain continuous data outputs, resulting in increased hardware complexity. Specifically, hardware complexity scales directly with interleaving size N, posing substantial challenges for larger interleavers. In contrast, the proposed architecture shown in Figure 9 utilizes Lifetime Analysis and Forward–Backward Register Allocation to significantly minimize register usage and optimize resource utilization. Quantitative results indicated average reductions of approximately 45.80% in register count and 58.51% in MUX count, demonstrating that the proposed architecture nearly halves hardware complexity without degrading interleaving performance.

To further validate these improvements practically, synthesis experiments were performed using a standard 28 nm CMOS process. All interleaver configurations were implemented in Verilog Hardware Description Language (HDL) and synthesized using Synopsys Design Compiler at an operating frequency of 500 MHz.

Table 3. Synthesis results for GNSS block interleavers (28 nm CMOS).

	GPS	BDS				Galileo				QZSS	NavIC			Average
	L1C	B1C	B1I	B2I	B3I	E1B	E5a	E5b	E6B	L1C	L1 SPS	L5 SPS	S SPS
Size	$38\times 46$	$36\times 48$	$2\times 15$	$2\times 15$	$2\times 15$	$8\times 30$	$8\times 61$	$8\times 30$	$8\times 123$	$38\times 46$	$38\times 46$	$8\times 73$	$8\times 73$	$16\times 48$
Area $({10}^3\mathsf{\mu }{\mathrm{m}}^2$)
Conv.	14.53	14.35	0.28	0.28	0.28	2.03	4.15	2.03	8.22	14.53	14.53	4.89	4.89	6.54
Prop.	10.52	10.39	0.11	0.11	0.11	1.25	2.61	1.25	5.50	10.52	10.52	3.30	3.30	4.58
Imp. (%)	27.60	27.60	60.71	60.71	60.71	38.42	37.11	38.42	33.09	27.60	27.60	32.52	32.52	38.82
Power (mW)
Conv.	7.91	7.82	0.16	0.16	0.16	1.12	2.24	1.12	4.46	7.91	7.91	2.67	2.67	3.56
Prop.	4.23	4.22	0.06	0.06	0.06	0.55	1.10	0.55	2.23	4.23	4.23	1.33	1.33	1.86
Imp. (%)	46.52	46.04	62.50	62.50	62.50	50.89	50.89	50.89	50.00	46.52	46.52	50.19	50.19	52.01
Latency (#cycle)
Conv.	1748	1728	30	30	30	240	488	240	984	1748	1748	584	584	783.23
Prop.	1665	1645	14	14	14	203	420	56	854	1665	1665	504	504	709.46
Imp. (%)	4.75	4.80	53.33	53.33	53.33	15.42	13.93	76.67	13.21	4.75	4.75	13.70	13.70	25.05

Abbreviations: Conv. = conventional; Prop. = proposed; Imp. = improvement, computed as (Conv. $-$ Prop.)/Conv. $\times$ 100%.

summarizes key implementation results, including chip area, power consumption, and latency for both conventional and proposed architectures across all evaluated GNSS interleavers. As interleavers primarily consist of registers and MUXs, reductions in these elements directly correlate with improvements in chip area and power consumption. According to the synthesis results, the proposed architecture achieved substantial average improvements of approximately 38.82% in chip area and 52.01% in power consumption, respectively. Although the improvement ratio tends to decrease as the interleaver size increases and the control path occupies approximately 40% of the total area, the proposed architecture consistently maintains superior performance compared to the conventional method. These improvements align closely with the quantitative hardware resource reductions illustrated previously in Figure 11, confirming that efficiency improvements are primarily driven by decreased register and MUX usage. The proposed architecture also improved latency by approximately 25.05% compared to conventional designs. This latency reduction results from completely eliminating double buffering and leveraging the global latency offset calculated through Lifetime Analysis, allowing outputs to begin at the earliest feasible clock cycle.

In summary, the experimental results consistently confirm performance improvements across all existing GNSS interleaver configurations. The proposed architecture significantly reduces hardware complexity, chip area, power consumption, and latency without sacrificing interleaving performance. These advantages underscore its practical suitability for efficient implementation in current and next-generation GNSS applications.

5. Conclusions

This paper proposed an optimized hardware architecture for interleaving in modern GNSS using Lifetime Analysis and Forward–Backward Register Allocation techniques. Conventional GNSS interleavers typically require significant hardware resources, including numerous registers, and MUXs, leading to increased chip area, power consumption, and latency. To address these issues, Lifetime Analysis was employed to precisely determine the minimum register count, significantly reducing hardware redundancy. Additionally, Forward–Backward Register Allocation was utilized to maximize the efficiency of register utilization. This method systematically allocates data samples based on their lifetime information, ensuring that each register is optimally employed throughout the entire interleaving process. The synthesis results demonstrated substantial improvements compared to conventional architectures, with average reductions of approximately 38.82% in chip area and 52.01% in power consumption. Additionally, latency performance improved by approximately 25.05% by eliminating the double buffering structure and implementing a global latency offset calculated through Lifetime Analysis, allowing outputs to begin significantly earlier. These experimental results confirm that the proposed interleaver architecture effectively maintains robust interleaving performance while minimizing hardware complexity and resource usage. The reduced complexity leads directly to lower power consumption and a smaller chip footprint, making the proposed approach highly suitable for resource-constrained GNSS receivers and satellite payloads. The architecture also ensures continuous, collision-free data streaming with improved latency performance. Therefore, the proposed optimized hardware interleaver architecture presents a significant advancement in addressing practical GNSS implementation challenges, offering substantial benefits for current and future navigation systems.