Journal de fabrication d’une carte pour réseau logique discret
Cet article fait partie d’une série consacrée au processus de construction d’un système informatique complet à l’aide de circuits logiques discrets. À ce jour, l’auteur a créé un ordinateur capable d’exécuter des applications réseau comme un serveur HTTP ou des jeux en LAN.
Vue d’ensemble
- L’an dernier, l’auteur a fabriqué un adaptateur de couche physique qui convertit le signal Ethernet 10BASE-T en SPI et inversement. À l’époque, son fonctionnement avait été testé avec un microcontrôleur STM32, et il implémente désormais un module de couche MAC pour le connecter à son ordinateur maison.
- Les deux adaptateurs sont full-duplex et possèdent chacun des sections d’émission et de réception indépendantes.
Récepteur
Résumé du fonctionnement du récepteur :
- Les données série SPI sont converties en données parallèles par octet, et une horloge d’octet est extraite.
- Les 6 premiers octets sont comparés à une référence d’adresse MAC de destination, et les trames qui ne correspondent pas sont rejetées.
- Les octets sont écrits dans un tampon en RAM statique.
- À la fin de la trame, le récepteur est désactivé, et les trames supplémentaires sont rejetées jusqu’à ce que l’utilisateur le redémarre. Le compteur d’octets s’arrête et sa valeur est fournie à l’utilisateur.
Capture des données
- Il faut convertir les données SPI série en flux d’octets.
- Les données série sont décalées dans un registre à décalage (
U32).U30etU31comptent respectivement les bits et les octets. - Le signal d’écriture vers la RAM statique
recv_buf_weest formé à l’aide de la bascule DU29B. Ce signal passe brièvement à l’état bas après chacun des 8 bits des données d’entrée. - Les octets reçus sont écrits dans un tampon de RAM statique 2 kB 6116 (
U20). U13,U16,U18forment un multiplexeur d’adresses qui sélectionne soit le compteur d’octets, soit le bus d’adresses système comme entrée d’adresse de la SRAM (U20).- Le buffer trois états
U21envoie les octets reçus vers la RAM.
Filtrage de l’adresse MAC
- En analysant le trafic Ethernet, l’auteur a constaté que les trames arrivent généralement par petits groupes (3 à 4 trames séparées par une courte latence). Les trames d’un même groupe ont en général des adresses MAC de destination différentes.
- Cela lui a fait penser que son ordinateur ne pourrait pas filtrer les trames reçues par MAC et redémarrer le récepteur assez vite pour capter celles qui lui sont destinées. Un filtrage matériel des adresses MAC était nécessaire.
- Stocker quelque part une adresse MAC personnalisée puis la comparer aux 6 premiers octets reçus était trop complexe. La créer à partir de la répétition d’un seul octet (par exemple
FE:FE:FE:FE:FE:FE) était possible, mais peu intéressant. - Pour apporter un peu de variation à son adresse MAC, il l’a définie comme fonction de l’index d’octet :
- le bit 0 est fixé à 0
- le bit 1 est fixé à 1
- les bits 2 à 4 sont l’inversion de l’index d’octet
- les bits 5 à 7 sont fixés à 1
- Avec cette règle, l’adresse MAC devient
FE:FA:F6:F2:EE:EA. Il faut aussi accepter l’adresse MAC de broadcastFF:FF:FF:FF:FF:FFpour que cela fonctionne avec ARP.
Émetteur
- Comme pour le récepteur, l’émetteur n’implémente pas la génération du FCS en matériel ; elle est réalisée en logiciel.
- Pour simplifier davantage l’émetteur, l’auteur a décidé de ne prendre en charge que des trames de longueur fixe. Cela évite d’avoir besoin d’un comparateur numérique complexe, et la logique d’émission ne dépend alors que d’un seul bit du compteur d’octets.
- La longueur de trame a été fixée à 1024 octets, ce qui est proche de la MTU courante de 1500 octets.
- Le préambule de trame requis par le 10BASE-T (une séquence de
0x55suivie de0xD5) est également inclus dans ces 1024 octets et doit être chargé par le logiciel.
Compteurs
- Comme pour le récepteur, deux compteurs sont utilisés pour compter les bits (
U12) et les octets (U14). - Le premier compteur est alimenté par l’horloge 20 MHz d’un oscillateur intégré.
- Le signal 20 MHz n’est pas utilisé directement et est au minimum divisé par 2. Ainsi, le rapport cyclique de l’oscillateur n’affecte pas le signal de sortie.
Flux de données
- Pour sélectionner l’entrée d’adresse de la RAM (
U22), les mêmes trois multiplexeurs 74HC157 que dans le récepteur sont utilisés (non montrés ici). U23sert à charger les données dans la RAM.U24joue le rôle de stockage intermédiaire pour l’octet en cours de transmission. L’idée est similaire à celle du pipeline VGA de l’auteur.- Le compteur d’octets 74HC4040 est un compteur ripple et met du temps à se stabiliser ;
U24fournit donc une sortie stable pendant que la sortie RAM n’est pas encore valide. - Ces données sont ensuite envoyées au registre à décalage
U28et décalées bit par bit.
Interface CPU
Du point de vue du programmeur, l’interface de cet adaptateur Ethernet est la suivante :
- Les deux tampons de trame sont mappés à
0xF000. - Deux registres en lecture seule sont disponibles :
- un registre d’état 8 bits à
0xFB00avec deux drapeaux :RX_FULL- une trame a été reçueTX_BUSY- une trame est en cours de transmission
- un registre 16 bits de longueur des données reçues à
0xFB02
- un registre d’état 8 bits à
- Écrire une valeur quelconque à
0xFB00redémarre le récepteur. - Écrire une valeur quelconque à
0xFB01lance la transmission. - Il n’y a pas d’interruptions, car le CPU de l’auteur ne les prend pas en charge.
Programmation
L’auteur voulait une prise en charge réseau, mais ne souhaitait pas implémenter lui-même une pile TCP/IP complète. De plus, son premier compilateur était médiocre, et programmer en assembleur était pénible ; il voulait donc un compilateur C correct. Il a donc créé un compilateur C. Celui-ci est désormais assez mature pour compiler uIP 1.0 (une petite bibliothèque TCP/IP). Malgré la très faible densité de code de son CPU, uIP est suffisamment compact pour tenir en RAM tout en laissant de la place pour de vraies applications.
Les performances réseau sont très faibles, mais compte tenu de l’absence de CPU commercial ou de puce spécialisée, le résultat reste très satisfaisant :
- temps moyen d’aller-retour du ping : 85 ms
- vitesse de téléchargement du serveur HTTP : 2.6kB/s (fichiers statiques servis depuis une carte SD)
Dépôt du projet
Les modèles, fichiers de schéma et plans de PCB sont disponibles sur GitHub.
L’avis de GN⁺
- Ce projet montre une compréhension approfondie du matériel et une grande passion de la part du développeur. L’effort consistant à tout implémenter soi-même est extrêmement impressionnant, même si sa praticité peut être questionnée.
- Les systèmes informatiques modernes sont très complexes et spécialisés, si bien que tout implémenter depuis zéro est très inefficace. En particulier pour des domaines bien établis et optimisés comme les piles de protocoles réseau, il est judicieux de réutiliser des implémentations existantes.
- Malgré cela, ce type de projet a une très grande valeur pédagogique. Il permet d’expérimenter directement la manière dont le matériel et le logiciel de bas niveau interagissent, ainsi que la façon dont les protocoles sont implémentés.
- En outre, à une époque où la compréhension du matériel tend à diminuer chez les développeurs, ce genre de projet peut constituer un exemple précieux rappelant les fondements des systèmes informatiques.
- Le point regrettable est que les performances sont très faibles. Une implémentation davantage optimisée serait nécessaire pour accroître sa viabilité pratique. Mais cela ne semble pas être l’objectif principal du projet.
1 commentaires
Commentaires Hacker News