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

Cet article présente l'intégration et l'optimisation d'un contrôleur hôte de carte SD open source pour la plateforme SoC RISC-V Cheshire, où l'adaptation du pilote logiciel aux spécificités du modèle mémoire CVA6 a permis de réduire les goulots d'étranglement liés aux instructions de barrière et d'atteindre un débit de 11,1 Mo/s, soit six fois supérieur aux solutions SPI.

L'essentiel

🌍 Le Contexte : Une voiture électrique sans réservoir

Imaginez que les chercheurs de l'ETH Zurich ont construit une voiture électrique de pointe (un processeur RISC-V appelé "Cheshire") entièrement conçue avec des plans libres et gratuits (Open Source). C'est une merveille de technologie : elle est rapide, elle peut faire tourner un système d'exploitation complet comme Linux, et elle est fabriquée avec des outils ouverts.

Mais il y a un gros problème : elle n'a pas de réservoir d'essence efficace.

Actuellement, pour stocker des données (comme le système d'exploitation, vos photos, vos fichiers), cette voiture utilise une vieille connexion appelée SPI. C'est un peu comme essayer de remplir un réservoir de 50 litres avec une paille à boire. C'est lent, frustrant, et ça ne permet pas de faire de grands voyages.

Pour que cette voiture soit vraiment utile au quotidien, il lui faut un réservoir standard, rapide et peu coûteux : une carte SD (comme celle qu'on met dans nos appareils photo ou nos téléphones).

🛠️ La Solution : Le nouveau "Piston" (Le Contrôleur SD)

L'équipe a donc créé et intégré un nouveau composant, un contrôleur SD, directement dans la puce de la voiture.

1. Le Design (L'architecture) :
   Imaginez que la carte SD envoie deux types de messages : des ordres (Commandes) et des colis (Données). Au lieu de les envoyer sur une seule route encombrée, les chercheurs ont construit deux autoroutes séparées : une pour les ordres et une pour les colis. Cela évite les embouteillages. De plus, ils ont connecté ce contrôleur directement au cœur du processeur (l'autoroute principale), au lieu de le mettre sur une petite route de service, pour gagner du temps.

2. Le Problème Caché (Le "Fence" ou Barrière) :
   C'est ici que l'histoire devient intéressante. Le processeur (le cerveau de la voiture) est très intelligent, mais il a un défaut de conception dans sa façon de gérer la mémoire.
   Imaginez que le conducteur (le logiciel) doit vérifier un indicateur sur le tableau de bord. Normalement, il regarde juste. Mais à cause d'une règle de sécurité trop stricte (l'instruction "Fence" dans le processeur), à chaque fois qu'il regarde un indicateur, il doit arrêter le moteur, vider le réservoir, et tout remettre en place avant de continuer.
   Résultat : Le système devient extrêmement lent. C'est comme si vous deviez éteindre votre voiture à chaque fois que vous vouliez vérifier l'heure sur votre montre.

3. L'Optimisation (Le "Hack" intelligent) :
   Les chercheurs ont pris le manuel d'utilisation du logiciel (le pilote Linux) et l'ont réécrit. Ils ont dit au conducteur : "Hé, pour cette voiture précise, tu n'as pas besoin de faire tout ce ménage à chaque fois. Tu peux juste regarder l'indicateur et continuer."
   En supprimant ces arrêts inutiles, ils ont fait exploser la vitesse.

📊 Les Résultats : De la paille à l'autoroute

Voici ce que ça donne en chiffres, traduits en langage courant :

• Avant (SPI / Paille) : C'était très lent.
• Après (SDHC / Autoroute) :
  • En mode "brut" (sans système d'exploitation complexe), ils ont atteint 11,1 Mo/s. C'est presque la vitesse maximale théorique de la carte SD elle-même (12,5 Mo/s). C'est 6,5 fois plus rapide que l'ancienne méthode.
  • En mode "Linux" (avec le système d'exploitation), avant l'optimisation, c'était catastrophique à cause du problème de "barrière". Après l'optimisation, la vitesse a été multipliée par 25 pour la lecture !

🏗️ L'Avantage Supplémentaire : Plus petit et plus léger

En plus d'être rapide, ce nouveau contrôleur est plus petit que l'ancien système SPI.

• Imaginez que l'ancien système prenait la place d'un gros coffre dans la voiture.
• Le nouveau système prend la place d'une petite boîte à gants.
  Cela libère de l'espace sur la puce pour ajouter d'autres fonctionnalités plus tard.

🔮 Et pour le futur ?

Les chercheurs ne s'arrêtent pas là. Ils prévoient deux améliorations majeures :

1. Mettre à jour le processeur pour qu'il gère mieux ces vérifications (en utilisant une fonction appelée "CMO"), ce qui rendra le système encore plus fluide.
2. Ajouter un "Directeur de la circulation" (DMA) : Au lieu que le processeur fasse tout le travail de chargement des données lui-même, il délèguera la tâche à un assistant dédié. Cela libérera le cerveau de la voiture pour faire autre chose, augmentant encore la vitesse.

En résumé

Ce papier raconte comment une équipe a transformé un système informatique open-source prometteur mais lent en une machine prête pour le grand public. Ils ont remplacé une connexion lente (SPI) par une connexion rapide (SD), et surtout, ils ont appris à "parler" au processeur d'une manière qui évite les goulots d'étranglement inutiles.

C'est une victoire pour l'informatique libre : cela prouve qu'on peut construire des ordinateurs complets, rapides et fiables, entièrement avec des outils et des plans gratuits.

Résumé technique

1. Problématique

Bien que les systèmes sur puce (SoC) RISC-V capables de démarrer Linux et entièrement open-source (comme la plateforme Cheshire et le démonstrateur Basilisk) aient prouvé leur viabilité, ils souffrent d'un goulot d'étranglement critique : le stockage non volatil.

• Limitations actuelles : Les solutions de stockage actuelles reposent sur des interfaces SPI ou I2C, qui offrent un débit insuffisant pour des applications Linux pratiques (démarrage, système de fichiers racine, données utilisateur).
• Besoin : Les cartes Secure Digital (SD) sont le standard de facto pour le stockage embarqué Linux en raison de leur faible coût et de leur interface commodité. Cependant, l'intégration d'un contrôleur hôte SD (SDHC) efficace et open-source pour les plateformes RISC-V faisait défaut.
• Défi spécifique : L'architecture mémoire du cœur CVA6 (utilisé dans Cheshire) et son modèle de mémoire RISC-V introduisent des pénalités de performance importantes lors de l'accès aux registres mappés en mémoire, notamment en raison de l'instruction fence.

2. Méthodologie

Les auteurs ont conçu, implémenté et optimisé un contrôleur hôte SD (SDHC) compatible avec la norme SDHCI version 1.0, intégré directement dans le SoC Cheshire.

• Architecture Matérielle (RTL) :
  • Le contrôleur sépare les canaux de commande et de données en blocs architecturaux distincts, synchronisés par des notifications.
  • Contrairement aux autres périphériques de Cheshire connectés à un bus de registres multiplexé, le SDHC est connecté directement à la croix AXI principale. Cette décision vise à réduire la latence, car la configuration actuelle de CVA6 ne supporte pas plusieurs requêtes en attente vers les registres mappés en mémoire.
  • La latence de lecture a été réduite à 11 cycles, permettant un transfert de 4 octets tous les 29 cycles en boucle de copie bare-metal.
• Optimisation Logicielle (Pilote) :
  • Un pilote Linux a été développé en réutilisant le pilote SDHCI existant avec moins de 100 lignes de code supplémentaire.
  • Problème identifié : Lors de l'exécution sous Linux, l'instruction fence de CVA6 (utilisée lorsque les opérations de gestion de cache - CMO - sont désactivées) vide le pipeline et le cache de données à chaque accès de registre, ajoutant environ 500 cycles de surcharge par accès.
  • Solution : Les auteurs ont personnalisé les callbacks du pilote pour contourner les instructions fence inutiles lors des accès aux registres du SDHC, éliminant ainsi cette surcharge massive.
  • Un pilote bare-metal a également été créé pour le démarrage depuis la carte SD, réduisant la taille du code dans la ROM de démarrage.

3. Contributions Clés

1. Implémentation Open-Source : Une implémentation optimisée d'un contrôleur SDHC (SDHCI v1.0) intégrée à la plateforme SoC Cheshire, dont le code RTL est disponible sous licence open-source permissive.
2. Optimisation Pilote Spécifique : Un pilote Linux et bare-metal adapté à la configuration CVA6, résolvant les goulots d'étranglement liés au modèle de mémoire RISC-V et à l'instruction fence.
3. Comparaison de Performance et de Surface : Une analyse détaillée comparant l'approche SDHC directe à l'accès SD via SPI, tant en termes de débit que de surface de silicium.
4. Validation sur SoC Linux : Démonstration de la viabilité d'un système Linux complet sur RISC-V avec un stockage non volatil performant.

4. Résultats

Les résultats sont présentés pour deux scénarios : exécution bare-metal et exécution sous Linux (avec et sans optimisation), à 50 MHz (mesure) et extrapolés à 500 MHz (scénario de sortie industrielle).

• Débit (Throughput) :
  • Scénario Idéal (Bare-metal, accès registre 1 cycle) : 11,1 Mo/s en lecture et 11,4 Mo/s en écriture. Cela représente environ 8 fois le débit du SPI et approche la limite théorique de l'interface SD (12,5 Mo/s).
  • Scénario Cheshire (Bare-metal) : 6,3 Mo/s (lecture) et 9,1 Mo/s (écriture), soit 6,5 fois et 4,5 fois le débit du SPI respectivement.
  • Sous Linux (Avant optimisation) : Très faible (224 Ko/s lecture, 159 Ko/s écriture) à cause des fence.
  • Sous Linux (Après optimisation - "Opt") : Le débit passe à 945 Ko/s (lecture) et 485 Ko/s (écriture). L'optimisation apporte une amélioration de 24,9 fois en lecture et 11,3 fois en écriture par rapport au SPI.
  • Extrapolation à 500 MHz : Le système optimisé récupère la majeure partie de la performance théorique.
• Surface (Area) :
  • Le contrôleur SDHC occupe 24,2 kGE (Gate Equivalents) dans le nœud 130 nm d'IHP, contre 86 kGE pour le périphérique SPI actuel. C'est une réduction de 3,6 fois.
  • La contribution à la ROM de démarrage est réduite de 8 kGE à 4,2 kGE, un gain crucial pour la densité d'implantation.

5. Signification et Perspectives

Cet travail démontre qu'il est possible de réaliser des systèmes embarqués RISC-V open-source complets et performants, capables de gérer un stockage non volatil efficace, comblant ainsi une lacune majeure pour l'adoption de Linux sur RISC-V.

• Impact immédiat : La solution permet aux cartes de développement basées sur Cheshire (comme Basilisk) d'utiliser des cartes SD pour le stockage de masse, rendant le système plus pratique pour les développeurs et les applications réelles.
• Perspectives futures :
  • L'ajout des opérations de gestion de cache (CMO) via l'extension HPDcache permettrait d'utiliser des fence plus légers et de permettre plusieurs accès en attente, réduisant encore la latence.
  • La mise à jour vers la norme SDHCI version 3.0 permettrait d'implémenter un DMA (Direct Memory Access) pour le SD, augmentant massivement le débit et libérant le processeur.

En conclusion, cette recherche fournit une base solide pour l'écosystème open-source RISC-V, prouvant que l'optimisation conjointe du matériel (RTL) et du logiciel (pilote) est essentielle pour surmonter les défis spécifiques aux architectures de processeurs modernes.