I. INTRODUCTION

Connected and automated vehicles (CAVs) are rapidly emerging as a transformative technology in the automotive domain, promising significant improvements in traffic safety, energy efficiency, and user convenience ^{[1- 7]}. By leveraging advanced sensing, communication, and control systems, CAVs enable real-time cooperation among vehicles, roadside infrastructure, and cloud-based services. A critical enabler of this ecosystem is vehicle-to-everything (V2X) communication, supported by dedicated short-range communications (DSRC) and 5G New Radio V2X (NR-V2X), which provide high data rates and low latency for exchanging information among dynamic entities on the road ^{[8- 12]}. However, the proliferation of wireless connectivity also exposes CAVs to severe cybersecurity risks. Each vehicle continuously generates and transmits a large volume of sensitive information, including positional data, control commands, and sensor streams, all of which are attractive targets for malicious adversaries ^[13]. The expansion of the attack surface significantly increases the likelihood of unauthorized access, message injection, replay attacks, and other forms of intrusion ^{[14- 16]}. Consequently, ensuring secure, reliable, and low-latency communication is paramount for the safe operation of CAVs. Cryptography provides the fundamental mechanism for securing vehicular communications. Among the numerous algorithms available, the Advanced Encryption Standard (AES) and the ChaCha20 stream cipher are the two most widely adopted solutions in practice ^{[17, 18]}. AES, as the de facto standard for symmetric-key encryption, is widely deployed due to its proven security strength and extensive hardware/software support. ChaCha20, a modern ARX (Addition-Rotation-XOR) based stream cipher, has been standardized in IETF protocols and adopted in security frameworks such as TLS 1.3 and WireGuard due to its efficiency and strong resistance to timing-based side-channel attacks. These two algorithms constitute the core cryptographic primitives for safeguarding both internal in-vehicle data exchange and external V2X communication.

Although both AES and ChaCha20 can be implemented purely in software, their software-based execution on CPUs or GPUs presents limitations in the context of CAVs. Real-time vehicular communication is characterized by short yet frequent packets, often with strict latency constraints. Software implementations incur non-negligible per-packet overhead due to padding, mode initialization, and memory access operations in the case of AES, or due to repeated ARX operations in ChaCha20. Moreover, when these operations compete with other computation-heavy automotive workloads, the cumulative cost can impose substantial burdens on the host processor, leading to increased latency and reduced energy efficiency. This overhead is particularly problematic in safety-critical scenarios where even microseconds of delay can impact the responsiveness of autonomous driving functions. To address these challenges, dedicated hardware acceleration of symmetric-key ciphers has emerged as a promising direction. Hardware implementations can exploit parallelism and pipelining at the architectural level, thereby achieving significantly higher throughput, lower latency, and improved energy efficiency compared with software-only approaches. Prior studies have explored hardware-oriented realizations of AES, ChaCha20, and other crypto-algorithms, demonstrating their ability to sustain high-performance under resource constraints ^{[19- 37]}. Building upon this trend, the focus of this work is to design an optimized ChaCha20 hardware accelerator tailored for secure and real-time CAV communications.

Several prior studies have explored ChaCha20 hardware implementations with varying degrees of unrolling and optimization. Early works investigated datapaths instantiating $1\times$, $4\times$, and $8\times$ quarter-round (QR) units, where the labels denote spatial parallelism. Henzen et al. reported that the $8\times$QR design achieved 6.78 Gbps, while the $4\times$QR variant offered a more favorable trade-off between throughput and area efficiency ^[20]. Nevertheless, these single-state designs preserve the sequential execution of column and diagonal rounds, leaving the round hardware underutilized during alternating phases. Other approaches emphasized different design goals. Mozaffari-Kermani et al. prioritized reliability in a 65-nm CMOS implementation, where the baseline ChaCha20 core reached 9.6 Gbps ^[21]. Serrano et al. presented an area-efficient ChaCha20 core in 180-nm technology, evaluating $1\times$, $2\times$, and $4\times$QR configurations, with the $4\times$QR design reaching 3.65 Gbps and being integrated into a RISC-V SoC ^[22]. However, the constraints of single-state scheduling and the use of older process nodes limited performance scalability. At the system level, Le et al. introduced a reconfigurable crypto accelerator that achieved up to 75.4 Gbps throughput through resource sharing and multi-core parallelism, albeit at the expense of area efficiency ^[23]. At the microarchitectural level, Rashidi et al. improved the ARX datapath using a sparse parallel prefix adder and resource sharing to reduce area and delay ^[24]. On reconfigurable platforms, Dani demonstrated an Artix-7 FPGA design achieving 5.6 Gbps using pipelining, though duplicating round logic increased hardware cost ^[25]. These studies collectively demonstrate the trade-offs in ChaCha20 hardware design: while unrolling and pipelining enhance throughput, they often either leave round hardware idle or demand excessive resources. This motivates the need for an alternative architecture that simultaneously maintains compact area, avoids idle cycles, and sustains high throughput-objectives that form the foundation of the dual-state interleaving approach proposed in this work.

In this paper, we first present three single-state based ChaCha20 architectures, CR-1, CR-2, and CR-4, which instantiate different degrees of round unrolling and serve as reference points for performance and efficiency comparisons. These baseline designs were originally introduced in our prior work ^[19], where we demonstrated their effectiveness in balancing throughput, area, and power. Building on this foundation, we now extend the work by proposing a dual-state ChaCha20 (DSCC20) hardware design that interleaves two independent states in an alternating fashion, thereby eliminating idle cycles and maximizing round utilization. The proposed design delivers high throughput and area efficiency while maintaining moderate hardware cost, making it well suited for resource-constrained embedded systems, including latency-sensitive applications in the automotive domain. In contrast to conventional single-state architectures, the DSCC20 alternately processes two states with only one additional cycle of overhead, resulting in significantly improved throughput and area efficiency. The architecture is described in Verilog HDL, synthesized using 28-nm CMOS technology, and comprehensively evaluated in terms of area, power, delay, throughput, and area efficiency, with results compared against both the CR baselines and existing ChaCha20 and AES designs.

In summary, the contributions of this work are outlined as follows:

II. BACKGROUND

ChaCha20 is a member of the ChaCha family, introduced as a modification of Salsa20 to achieve faster diffusion per round while retaining algorithmic simplicity ^[18]. It is a symmetric-key stream cipher that generates a 512-bit keystream block from a $4 \times 4$ matrix of 32-bit words, referred to as the state. The initial state consists of four components: a 128-bit constant, a 256-bit secret key, a 32-bit block counter, and a 96-bit nonce. These values are arranged in row-major order, with the constants in the first row, the key in the second and third rows, the counter in the first column of the fourth row, and the nonce in the remaining positions. All values are represented in little-endian format, consistent with the algorithm's internal word ordering. The ChaCha20 block function transforms the initialized 512-bit state through 20 rounds of computation, organized into 10 double rounds. Each double round consists of a ColumnRound() function, which operates on the vertical columns of the state, followed by a DiagonalRound() function, which mixes the diagonal elements. Once all rounds are completed, the transformed state is added element-wise to the preserved initial state to generate the final keystream block. This feed-forward addition enhances diffusion and ensures that the transformation is not trivially invertible.

Algorithm 1 illustrates how the state $s$ is processed during two consecutive rounds. The function explicitly takes the 512-bit state $s = s[0], s[1], \dots, s[15]$ as input and modifies it in place. During the ColumnRound(), four independent QuarterRound() operations are applied to each of the four columns of the $4 \times 4$ state matrix. During the DiagonalRound(), another four QuarterRound() operations are applied, this time to diagonal word groups, ensuring that every word interacts with different neighbors across rounds. By alternating these two transformations, ChaCha20 guarantees rapid and uniform diffusion of the key, counter, and nonce across the entire state. At the core of both ColumnRound() and DiagonalRound() is the QuarterRound() function, shown in Algorithm 2. This function operates on four 32-bit words of the state, $(a,b,c,d)$, and performs a fixed sequence of ARX operations. Specifically, $+$ denotes 32-bit integer addition modulo $2^{32}$, $\oplus$ is bitwise XOR, and $\ll n$ is a left rotation by $n$ bits. The choice of rotation distances (16, 12, 8, and 7) ensures that different bit positions are mixed uniformly across rounds. The QuarterRound() function provides the fundamental nonlinear transformation that propagates changes from one word across the others, and when applied repeatedly across the state matrix, it ensures strong diffusion. Over the course of 20 rounds, each word of the state is updated multiple times through different pairings, which greatly enhances security margin of the cipher.

Algorithm 1: Two round of ChaCha20 stream cipher.

Algorithm 2: Quarter round of ChaCha20.

ChaCha20's reliance solely on ARX operations makes it highly attractive for accelerator design. Unlike AES, it does not require substitution boxes (S-boxes), lookup tables, or Galois field multiplications, thus eliminating the need for complex memory structures or logic. Its regular matrix structure maps naturally to parallel datapaths and pipelining, allowing designers to scale throughput without introducing irregular control overhead. The predictable timing of ARX operations simplifies synthesis and timing closure, while its side-channel resistance against cache-based attacks is advantageous for secure embedded implementations. Furthermore, since ChaCha20 is stream-oriented and does not require padding, it introduces minimal per-packet overhead, which is especially beneficial in CAV communications where short, frequent messages dominate. In addition, the lightweight nature of ARX-based processing reduces switching activity and energy consumption, making it well suited for automotive platforms with stringent power budgets. These structural advantages also allow ChaCha20 accelerators to be seamlessly integrated into heterogeneous systems-on-chip (SoC), supporting both dedicated security modules and reconfigurable cryptographic engines in emerging vehicular architectures.

III. PROPOSED CHACHA20 DESIGN

The conventional ChaCha20 hardware accelerator processes one 512-bit keystream block at a time and requires multiple clock cycles to complete the 20-round block function ^[20]. In a single-state schedule, strict data dependencies between the column and diagonal rounds enforce sequential execution, which causes only one round module to be active at any given cycle. As a result, the other round logic remains idle, leading to underutilization of hardware resources and suboptimal throughput.

To mitigate this inefficiency, our prior work introduced an $N\times$ combinational-round (CR) design, in which $4 \times N$ QuarterRound units are instantiated as combinational logic to perform $N$ rounds per-cycle ^[19]. Fig. 1 illustrates the CR-1 baseline architecture. A single round is composed of four combinational QuarterRound instances, with the ColumnRound and DiagonalRound implemented as distinct combinational blocks. A round controller time-multiplexes these phases: it activates either the column or diagonal round block in each cycle and routes the 512-bit state through a multiplexer (MUX) back into the state register. This mechanism serializes the two phases over successive cycles, such that one block remains idle while the other is active. After completing the 20 rounds, the transformed state is word-wise added to the preserved initial state, and the 512-bit result is serialized in little-endian order to form the keystream block. Building on the CR-1, we also explored the CR-2 and CR-4 architectures, which reduce the total cycle count by chaining multiple rounds into a single cycle. Specifically, the CR-2 combines a column and diagonal round into one cycle, requiring 15 cycles to complete the 20-round block function, while the CR-4 chains four rounds into one cycle, reducing the latency to 10 cycles. Although this approach reduces nominal cycle count, it also lengthens the critical path substantially due to deeper combinational logic, thereby lowering the maximum achievable clock frequency. Consequently, CR-2 and CR-4 demonstrate higher theoretical throughput but suffer from degraded timing closure and reduced efficiency in practice. These observations demonstrate a fundamental trade-off: unrolling more logic per-cycle improves cycle count but worsens frequency scalability, while single-state scheduling leaves hardware resources underutilized. This motivates the need for an alternative approach that raises utilization without incurring a critical path penalty.

Fig. 1. CR-1 baseline single-state ChaCha20 hardware architecture with QuarterRound ARX dataflow and little-endian serializer mapping from 512-bit state to keystream.

To address this challenge, we propose a dual-state ChaCha20 architecture that interleaves two independent states in an alternating fashion. By introducing a lightweight interleaving mechanism, the DSCC20 eliminates idle cycles while maintaining the same critical path as CR-1, thereby improving hardware utilization without additional round unrolling. The key idea is to introduce a lightweight interleaving mechanism that allows two independent states to be processed alternately, thereby eliminating idle cycles while keeping the round hardware fully utilized. Fig. 2(a) shows the overall DSCC20 hardware architecture. The inputs are provided as two consecutive tuples (Key$_1$, Nonce$_1$, Count$_1$) and (Key$_2$, Nonce$_2$, Count$_2$), representing successive blocks rather than separate physical ports. Compared with the CR-1 baseline in Fig. 1, the datapath adds only a second 512-bit state register file and a small amount of steering logic. The round logic itself is unchanged: a single ColumnRound module and a single DiagonalRound module are shared between the two states. After 20 rounds, the transformed state is combined with the preserved initial state in the Add-and-Serialize block, and the resulting keystream is XORed with the message (i.e. Message$_1$ and Message$_2$) to produce Cipher$_1$ and Cipher$_2$, respectively. The Round Control block simply selects which state feeds the round logic and where the results are written back, requiring only a small finite state machine (FSM) and a round counter.

Fig. 2. Proposed ChaCha20 hardware design; (a) dual-state architecture with shared round logic and duplicated state banks and (b) interleaved execution schedule showing that ColumnRound and DiagonalRound remain active every cycle.

This interleaved execution achieves several important advantages. By alternating two states, the design eliminates idle cycles and ensures that the Column and Diagonal modules are fully utilized in every clock cycle. At the same time, because only one round is evaluated per-cycle as in CR-1, the critical path length remains unchanged, which allows the maximum operating frequency to be preserved. The additional hardware overhead is also minimal, since the architecture requires only a second 512-bit state register, rather than duplicating the round logic. As a result, two keystream blocks are produced in nearly the same latency as a single block in CR-1, leading to a substantial improvement in effective throughput. It is worth noting that this design differs fundamentally from CR-2 and CR-4. Those architectures reduce cycle count by chaining multiple rounds in a single cycle, which improves nominal latency but significantly lengthens the critical path, making it difficult to sustain high clock frequencies. In contrast, the DSCC20 maintains the same per-cycle workload as CR-1, but achieves higher throughput by eliminating idle cycles through interleaving. This distinction allows DSCC20 to combine the advantages of high utilization and frequency scalability, resulting in a balanced trade-off between throughput and hardware cost.

Although the proposed architecture focuses on dual-state interleaving, the concept can be naturally extended to a multi-state design. By introducing additional state registers, multiple states could be interleaved in a round-robin fashion, keeping the Column and Diagonal modules continuously occupied across an even larger number of inputs. Such a multi-state scheme has the potential to further increase throughput and hardware utilization, while still avoiding the excessive logic replication of deeply unrolled designs. However, scaling beyond two states also introduces greater control complexity and additional register overhead, which must be carefully balanced against the expected performance gains.

IV. EXPERIMENTAL RESULTS

To evaluate the performance of the proposed DSCC20 architecture, we implemented it along with three baseline ChaCha20 designs, CR-1, CR-2, and CR-4, using Verilog HDL and synthesized them with Synopsys Design Compiler and a 28-nm CMOS standard-cell library to obtain area, power, delay, and maximum operating frequency. Throughput was derived from the number of processed rounds per-cycle and the maximum achievable frequency, while area efficiency was calculated as throughput normalized by the total gate equivalent (GE) count, where one GE corresponds to the area of a two-input NAND gate. For a fair comparison, each design was evaluated at its own maximum frequency. The area was reported in kilo-gate equivalents (kGE), and power consumption was measured using gate-level switching activity estimated under typical conditions. The proposed DSCC20 architecture was further benchmarked against three categories of designs: 1) the CR-1/2/4 baselines to highlight improvements from interleaving, 2) prior ChaCha20 hardware implementations reported in the literature, and 3) representative AES hardware accelerators across various technology nodes. In addition, the software-based Libsodium ChaCha20 implementation executed on general-purpose CPUs (x86 and ARM architectures) was included as a baseline reference to demonstrate the clear performance gap between hardware and software realizations ^[38]. Finally, although AES and ChaCha20 employ different cryptographic structures (block cipher versus stream cipher), the AES hardware designs were considered as comparison points because both algorithms are widely deployed in CAV security frameworks, making the evaluation relevant to real-world automotive communication scenarios.

Table 1 summarizes the area, power, throughput, and area efficiency results for the baseline CR-1/2/4 designs and the proposed DSCC20 synthesized in 28-nm CMOS technology, as well as software ChaCha20 performance measured on modern CPUs. At 763 MHz, the proposed DSCC20 achieves 30.06 Gbps, which corresponds to $1.88\times$, $1.87\times$, and $2.32\times$ the throughput of CR-1, CR-2, and CR-4, respectively. In terms of area, DSCC20 is larger than CR-1 and CR-2 by 17.0% and 10.4%, respectively, but is 37.9% smaller than CR-4. The power consumption of the DSCC20 is $1.20\times$, $2.01\times$, and $2.62\times$ higher than CR-1, CR-2, and CR-4, respectively, primarily due to the additional state register and control logic. However, the total consumption of 16.08 mW is several orders of magnitude lower than the operating power of common automotive electronic control units (ECUs), which typically range from a few watts to hundreds of watts. As such, this overhead is insignificant and does not hinder real-time V2X operation. Nevertheless, DSCC20 delivers the best area efficiency at 904.92 Kbps/GE, reflecting the benefit of removing idle cycles while keeping a compact datapath. These results demonstrate that, while CR-2 and CR-4 reduce idle cycles through round unrolling, such chaining extends the critical path, prevents operation at high frequencies, and results in lower efficiency. In contrast, DSCC20 leverages dual-state interleaving to sustain higher operating frequency with balanced area overhead, thereby nearly doubling throughput compared to single-state architectures.

The software performance of ChaCha20 was evaluated using the Libsodium library on two CPU platforms: an Apple M4 processor (ARM architecture) and an AMD Threadripper PRO 5975WX processor (x86 architecture). For a realistic comparison with vehicular communication traffic, throughput was measured with an 800-byte payload size representative of V2X messages ^[39]. To improve timing precision and amortize non-cryptographic overheads, each encryption was repeated 1,000 times per run, and the average execution time was used to compute throughput. The Apple M4 achieved 2.06 Gbps and the AMD Threadripper reached 9.36 Gbps, both with significantly higher power budgets (40 W and 280 W, respectively) compared with the 16.08 mW of DSCC20. By contrast, DSCC20 achieves 30.06 Gbps, which corresponds to roughly $15\times$ the throughput of the M4 and $3.2\times$ that of the AMD CPU. These results clearly highlight the decisive advantage of hardware acceleration, demonstrating that the proposed DSCC20 not only outperforms prior ChaCha20 baseline hardware but also vastly exceeds software implementations, making it highly suitable for real-time secure communication in CAV systems.

Table 2 compares the proposed DSCC20 design with previously presented ChaCha20 hardware accelerators across different technology nodes. For clarity, we explicitly state that all ChaCha20 accelerators evaluated here, including the proposed DSCC and previously reported designs, use the standard 20-round ChaCha20 block function, ensuring that all throughput and efficiency comparisons are performed under the same cryptographic configuration. Even though the earlier designs were implemented in various process technologies, the proposed DSCC20 clearly demonstrates superior performance and efficiency. Operating at 763 MHz in 28-nm CMOS node, the DSCC20 achieves a throughput of 30.06 Gbps, which is up to $8.2\times$ higher than the values earlier designs in ^{[20- 22]}. Compared to the most recent design in ^[23], DSCC20 still delivers higher throughput while operating at a lower frequency, confirming the benefit of sustaining utilization without aggressive pipelining or duplication of round logic. In terms of area, the proposed design requires 33.22 kGE, which is comparable to or smaller than many prior works, despite delivering much higher throughput. For example, the design in ^[21] consumes 56.5 kGE and the one in ^[22] requires 25.05 kGE, yet both offer significantly lower performance. Most notably, the proposed DSCC20 achieves an area efficiency of 904.92 Kbps/GE, which surpasses all prior ChaCha20 implementations by a wide margin. It improves efficiency by $4.6\times$, $5.3\times$, and $6.2\times$ compared to the designs in ^{[20, 21]}, and ^[22], respectively. Even when compared with ^[23], which reports relatively high efficiency at 666.57 Kbps/GE, the proposed design still delivers 36% better efficiency, validating the advantage of dual-state interleaving over conventional single-state or partially unrolled designs. These comparisons confirm that the proposed DSCC20 architecture offers the best balance between throughput and hardware cost among existing ChaCha20 accelerators. By sustaining higher utilization without incurring deep unrolling or excessive logic replication, DSCC20 demonstrates a scalable architecture that outperforms prior works in both absolute throughput and normalized efficiency.

Furthermore, to enable a fair comparison of throughput and frequency across different process technologies, all ChaCha20 implementations in Table 2 were normalized to an equivalent 28-nm reference node. We employed the DeepScaleTool framework, which provides voltage-frequency-delay scaling across 7-nm to 130-nm CMOS nodes ^[40]. For designs originally implemented in 180-nm technology, which DeepScaleTool does not directly support, we first applied a linear geometric scaling factor to map the results to an equivalent 130-nm node, consistent with prior literature ^[41], and subsequently normalized them to 28-nm using DeepScaleTool. This two-step process ensures consistent and defensible normalization for all evaluated designs and isolates architectural effects from technology-dependent frequency variation. The normalized results in Table 2 show that the performance advantage of DSCC20 remains substantial even after removing technology-node differences. When scaled to a common 28-nm reference, the throughput of prior ChaCha20 designs increases proportionally with technology scaling, with several implementations reaching normalized values in the 14~29 Gbps range. Despite this upward shift, the proposed DSCC20 design still achieves the highest normalized throughput at 30.06 Gbps, indicating that its performance benefit originates from architectural efficiency rather than fabrication node. Although our DSCC20 does not exhibit the highest normalized frequency among all designs, it still has the highest due to the elimination of idle cycles through dual-state interleaving. These normalized results confirm that the proposed architecture provides consistent advantages independent of process technology, reinforcing the DSCC20 design as one of the most scalable and resource-efficient ChaCha20 accelerator designs to date.

To further assess the competitiveness of the proposed DSCC20 architecture, we compare it against several existing AES hardware accelerators. Although ChaCha20 and AES employ different cryptographic primitives, ChaCha20 is an ARX-based stream cipher while AES is an S-box-based block cipher, both are widely adopted in secure automotive and vehicular communication frameworks. Therefore, evaluating the proposed DSCC20 alongside various AES designs provides meaningful insight into its viability as a hardware accelerator in practical CAV deployments.

As shown in Table 3, the proposed DSCC20 achieves 30.06 Gbps throughput with 33.22 kGE, yielding an area efficiency of 904.92 Kbps/GE. This value is considerably higher than most AES designs, which typically achieve 100 ~ 234 Kbps/GE, and it also exceeds the efficiency of the most competitive prior AES implementations. Even against the optimized design in ^[30], which reaches 831.10 Kbps/GE, the DSCC20 still delivers 9% higher efficiency while operating in a more advanced process node. These results highlight that ChaCha20, when mapped to hardware with interleaving, can rival or even surpass the efficiency of carefully optimized AES architectures. Throughput comparisons also emphasize this trend. Certain AES accelerators, such as designs in ^[28] and ^[29], report higher peak throughput values of 35.5 ~ 42.7 Gbps. However, these designs incur heavy area costs (182 ~ 352 kGE), resulting in far lower normalized efficiency. In contrast, the proposed DSCC20 provides a more balanced profile: it sustains over 30 Gbps throughput with a compact 33.22 kGE area footprint, demonstrating that interleaving achieves high utilization without excessive logic replication. This balance is particularly advantageous in embedded platforms where area and power budgets are strictly constrained. The structural distinction between ChaCha20 and AES also explains the observed efficiency gap. The AES relies on S-box lookups and Galois field multiplications, which are expensive in hardware and often limit area efficiency unless aggressively optimized. ChaCha20, by contrast, consists solely of addition, rotation, and XOR (ARX) operations, which map naturally onto simple arithmetic and logic units. Our DSCC20 architecture further exploits this property by ensuring that the round hardware is continuously active, translating algorithmic simplicity into practical gains in both throughput and efficiency.

The normalized results in Table 3 provide a fair comparison of AES accelerators after removing technology-node differences. When scaled to an equivalent 28-nm reference, several AES designs exhibit significantly higher normalized frequencies and throughputs, with some exceeding 1.3 GHz in normalized frequency and achieving normalized throughputs above 140~170 Gbps. These increases mainly stem from the aggressive round unrolling and deep pipelining strategies typically applied in high-performance AES cores. However, such throughput scaling comes at the cost of substantial hardware resources: these designs require more than 180~350 kGE, which places them far to the right on the throughput-area trade-off curve. In contrast, the proposed DSCC20 maintains a normalized throughput of 30.06 Gbps within a compact 33.22 kGE footprint, yielding a normalized efficiency that remains competitive despite its lower absolute throughput. The normalized comparison therefore confirms that the DSCC20 design achieves a more favorable throughput-area trade-off, delivering high sustained performance without the heavy logic duplication characteristic of high-throughput AES accelerators.

In summary, these comparisons demonstrate that the proposed architecture not only advances ChaCha20 acceleration beyond prior works but also establishes ChaCha20 as a compelling alternative to AES in automotive security. By combining lightweight ARX-based operations with dual-state interleaving, the DSCC20 achieves a superior balance of throughput, area efficiency, and implementation cost, making it particularly well suited for latency-sensitive and resource-constrained CAV environments.

To provide a more comprehensive comparison, we perform a joint analysis of throughput and hardware area, as these two metrics together determine the practicality of a cryptographic accelerator in embedded systems. High throughput alone may be insufficient if achieved at excessive silicon cost, while minimal area is of limited value if throughput cannot meet real-time communication demands. Therefore, plotting throughput against area reveals the efficiency frontier and highlights which designs achieve the best balance. Fig. 3 presents the joint throughput-area comparison of the proposed DSCC20, baseline ChaCha20 designs, earlier ChaCha20 accelerators, AES hardware implementations, and software baseline under AMD 5975WX and Apple M4. The proposed DSCC20 is clearly positioned at the Pareto front, achieving the best balance between throughput and area. With 30.06 Gbps throughput at only 33.22 kGE, the DSCC20 lies in the upper-left corner of the design space, which corresponds to the region of highest efficiency. This position reflects the effectiveness of dual-state interleaving in keeping the round logic continuously utilized without the excessive logic replication that characterizes deeply unrolled designs. Compared with the single-state baselines (CR-1/2/4), the proposed DSCC20 shifts upward significantly in throughput while remaining within a similar area range. The CR-4, for instance, consumes more than 50 kGE but achieves only 12.96 Gbps, whereas the DSCC20 delivers over twice the throughput with a smaller area. This demonstrates that interleaving is superior to unrolling as a means of eliminating idle cycles, since unrolling quickly inflates gate count and extends the critical path. Relative to prior ChaCha20 accelerators, our DSCC20 consistently dominates in both axes. Reported implementations either occupy the lower-left corner with modest throughput (3 ~ 10 Gbps) or scale throughput upward at the expense of large area footprints. The proposed design, in contrast, demonstrates that high throughput can be achieved within a compact datapath, establishing a new benchmark for ChaCha20 hardware design. When compared with AES accelerators, the proposed DSCC20 again demonstrates its balanced efficiency. Some AES designs, such as ^[28] and ^[29], reach raw throughput values exceeding 35 Gbps, but they do so with extremely high area costs ($\ge 180$ kGE), pushing them far to the right on the plot. Our DSCC20 instead provides nearly comparable throughput while using an order of magnitude fewer gates, which translates into substantially higher normalized efficiency. Finally, the AMD 5975WX software baseline demonstrates the stark contrast between hardware and software execution. Despite operating at 4.5 GHz and consuming 280 W, the CPU achieves only 9.36 Gbps, placing it far below and to the right of dedicated hardware designs. A similar observation holds for the Apple M4 processor, which delivers only 2.06 Gbps under a 40 W power budget. Both cases highlight the severe inefficiency of software-based ChaCha20, reinforcing the necessity of hardware acceleration to achieve the throughput and energy efficiency required for CAV communication workloads. The DSCC20 delivers more than $3\times$ the throughput at milliwatt-scale power and within a fraction of the area, underscoring the indispensability of hardware acceleration for CAV communication workloads.

Fig. 3. Joint throughput-area comparison of the proposed DSCC20, prior ChaCha20 and AES designs, and software based ChaCha20 implementations.

Overall, the joint throughput-area analysis confirms that DSCC20 achieves the most favorable balance among ChaCha20 and AES designs, outperforming both prior hardware and software baselines. Its location at the Pareto frontier validates the dual-state interleaving approach as an efficient and scalable solution for high-performance, resource-constrained secure communication systems.

V. CONCLUSION

This paper presented a dual-state based ChaCha20 hardware accelerator tailored for secure and real-time communication in CAVs. By interleaving two independent states on shared round hardware, the proposed DSCC20 architecture eliminates idle cycles while preserving the critical path length, thereby achieving a favorable balance of throughput, area, and power. When implemented in a 28-nm CMOS technology, the proposed design achieves 30.06 Gbps throughput with 904.92 Kbps/GE area efficiency, representing up to $2.3\times$ improvement in throughput over baseline single-state architectures (CR-1/2/4). In addition, the DSCC20 surpasses earlier ChaCha20 designs and demonstrates competitive performance compared with the AES accelerators.

Overall, our DSCC20 establishes ChaCha20 as a practical and efficient cryptographic primitive for vehicular security, delivering high throughput within a compact and energy-conscious design. When contrasted with software baselines, the DSCC20 provides more than $15\times$ higher throughput than Apple M4 and over $3\times$ higher throughput than AMD Threadripper, while consuming only 16.08 mW of power. The proposed interleaving strategy can also be naturally extended beyond two states, offering further opportunities to scale throughput while retaining efficiency. These results demonstrate that the proposed DSCC20 provides a compact and efficient ChaCha20 accelerator well suited for future secure and real-time CAV communication systems.