Implementing and Optimizing an Open-Source SD-card Host Controller for RISC-V SoCs

Abstract: Recent announcements have shown the viability of end-to-end open-source (OS) Linux-capable RISC-V systems on chip (SoCs). However, practical application and software development platforms require efficient non-volatile storage, which is not adequately served by common SPI-based interfaces due to their limited throughput. Secure Digital (SD) cards are the de facto standard storage medium for embedded Linux systems; efficient SD host controller (SDHC) integration is thus essential for open-source RISC-V platforms. We present an OS SD host controller interface (SDHCI) peripheral integrated into the end-to-end OS Cheshire RISC-V SoC platform. The controller and its software stack are designed with full awareness of CVA6's memory system and Linux driver behavior; during evaluation, we identify a significant performance bottleneck caused by the RISC-V memory model and CVA6's implementation of the fence instruction, which flushes the pipeline and data cache on memory-mapped register accesses when cache management operations (CMOs) are unavailable. By customizing the driver's register access paths and avoiding unnecessary fences, we substantially reduced this overhead. Our fully OS controller achieves up to 11.1 MB/s throughput, approaching the 12.5 MB/s limit of the SD interface and providing up to 6.5 times the throughput of SPI-based storage.

• The paper introduces an SDHCI v1.0-compliant controller achieving up to 11.4MB/s writes and an 8x throughput boost over SPI interfaces.
• Efficient hardware-software co-design, including direct AXI crossbar integration and customized driver optimizations, minimizes latency and reduces silicon footprint.
• Benchmark comparisons under bare-metal and Linux conditions validate scalable performance improvements, advancing robust embedded Linux systems.

Implementing and Optimizing an Open-Source SD-card Host Controller for RISC-V SoCs

Abstract and Motivation

The proliferation of open-source, Linux-capable RISC-V system-on-chip (SoC) platforms necessitates performant, reliable non-volatile storage interfaces. Legacy support for SPI- or I2C-connected storage limits throughput, impeding the realization of practical embedded Linux platforms. Secure Digital (SD) cards, the prevalent medium for embedded non-volatile storage, call for integration of an SD host controller (SDHC) supporting high-throughput operation and tight hardware-software co-design. This work addresses this gap via the open-source implementation of an SDHCI v1.0-compliant peripheral tailored for the Cheshire RISC-V SoC, optimizing both RTL and host driver to exploit platform specifics and substantially improve storage performance.

SDHC Architecture and SoC Integration

The SDHC architecture adheres to SD card protocol conventions, separating the command and data paths into distinct architectural blocks to maximize concurrency and minimize cross-channel interference. The SD clock is derived from the SoC main clock via a programmable divider, with careful synchronization between command-complete signaling and data transfers to avoid underrun/overflow. Memory-mapped registers conforming to the SDHCI v1.0 standard expose all operational controls and status for integration with standard SD card drivers.

Unlike most Cheshire peripherals, which connect through a low-performance register bus, the SDHC is attached directly to the AXI crossbar to minimize latency. This design choice arises from the CVA6 RISC-V core’s limited support for outstanding memory-mapped register requests, necessitating rapid turnaround for host-initiated data movement to avoid stalling transfer operations. Through this architecture, read access latency is constrained to 11 cycles, permitting a sustainable 4B transfer every 29 cycles in bare-metal operation; write-side latency is even lower, at 9 cycles per transaction.

Figure 1: High-level SDHC functional partitioning and integration into the Cheshire SoC, showing distinct command/data paths and direct AXI connection for latency minimization.

Software and Driver Co-Optimization

Linux integration exploits upstream SDHCI driver infrastructure, requiring less than 100 LoC extension for platform support. During validation, a marked performance bottleneck was attributed to the treatment of memory fences on the CVA6 core—absence of cache management operation (CMO) support leads to pipeline and D-cache flush on every fence, imposing roughly 500-cycle penalties for each 32b register access. This pathological overhead is sidestepped by customizing the driver’s register access to skip unnecessary fences specific to the memory-mapped SDHC space, maintaining coherency while drastically reducing execution stalls.

A bespoke bare-metal driver was also developed for boot scenarios, offering a substantial decrease in boot ROM footprint relative to the incumbent SPI-based solution (4.2kGE versus 8kGE).

Performance and Area Results

Empirical benchmarking demonstrates a significant increase in throughput over the SPI baseline. In a best-case ("Ideal") scenario, the SDHC achieves 11.1MB/s reads and 11.4MB/s writes, representing an 8x improvement over SPI, and approaching the protocol-limited maximum of 12.5MB/s. In realistic ("Bare") integration with Cheshire, throughput remains high at 6.3MB/s (reads) and 9.1MB/s (writes), or 6.5x and 4.5x over SPI, respectively.

Linux benchmarks further highlight the impact of software-level optimizations. Skipping fences improves read throughput from 224kB/s to 945kB/s and write throughput from 159kB/s to 485kB/s—factors of 24.9x and 11.3x over the SPI setup. Extrapolation to 500MHz host frequency with a 25MHz SD card recovers nearly full throughput, validating scalability.

The area efficiency is also notable: the SDHC occupies only 24.2kGE in IHP’s 130nm open PDK, 3.6x less than the SPI controller, enabling silicon area savings and integration in resource-constrained SoCs.

Figure 2: Throughput on bare metal at 50MHz host frequency demonstrates high efficiency compared to SPI and scalability with software optimizations.

Theoretical and Practical Implications

This research illuminates platform-specific bottlenecks, particularly the memory model’s interaction with I/O device register accesses in RISC-V. By leveraging software-driver co-optimization, the authors circumvent design limitations—highlighting the importance of tight hardware/software co-design in open hardware ecosystems, especially where mainstream Linux support is a requirement.

Practically, the open-source dissemination of a compact, efficient SDHCI peripheral advances the accessibility of fully open embedded Linux platforms, enabling rapid adoption in educational, prototyping, and edge system domains. On the theoretical front, the findings motivate further hardware investment in cache management extensions (e.g., CMO), out-of-order register accesses, and hardware/fence co-design, to match the expectations of general-purpose OSes.

Future Directions

Next-generation performance will benefit from full CMO extension deployment in CVA6 and associated SoCs, reducing the cost of fences to align with standard RISC-V memory models. Enabling multiple outstanding register accesses will allow further loop unrolling and data pipelining optimizations. Upgrading to SDHCI v3.0 is proposed, exposing SD card-side DMA—in principle, this can move throughput closer to the limits of the SD PHY and improve OS-level responsiveness. Hardware contributions such as HPDcache, already supporting CMO-lite semantics, provide a near-term path to deployment.

Conclusion

This work demonstrates the critical value of hardware/software co-design in open-source silicon for practical embedded Linux systems. The presented SDHC implementation combines protocol-conformant architecture, low-latency SoC integration, efficient open-source RTL, and driver-level optimizations to deliver substantial throughput and area benefits over legacy solutions. The holistic approach detailed in this study offers a blueprint for future SoC peripheral development where open hardware, Linux support, and real-world performance are imperative.