Kicad Master · 1 September 2026

OrthoRoute : l’autoroutage GPU pour KiCad entre promesses et réalité des benchmarks

Depuis des décennies, l’autoroutage de PCB reste le parent pauvre de la CAO électronique : lent, rigide, cantonné aux designs simples. Mais en 2026, un plugin KiCad nommé OrthoRoute vient bousculer ce dogme en exploitant la puissance des GPU NVIDIA pour router des cartes que les algorithmes classiques n’osent même pas effleurer. Pourtant, entre la promesse technique et l’adoption réelle, le fossé reste immense – et les premiers benchmarks publiés viennent tempérer l’enthousiasme. Décryptage d’une innovation qui pourrait – ou pas – changer la donne pour les concepteurs de cartes complexes.

Le grand bond du routage automatique : quand le GPU entre dans la danse

Si vous avez déjà passé des heures à router manuellement des centaines de nets entre deux BGA à pas fin, vous connaissez la frustration. Les autorouteurs CPU classiques – qu’il s’agisse de l’algorithme de Lee, de A* ou du maze routing – peinent sur les designs modernes. Leur complexité temporelle explose avec le nombre de connexions et de couches, et leur approche séquentielle (un net après l’autre) les condamne à des temps d’exécution rédhibitoires sur les backplanes multi-couches ou les cartes HDI. Résultat : beaucoup de concepteurs préfèrent router à la main, ou se contenter d’outils semi-automatiques.

C’est dans ce contexte que Brian Benchoff, figure bien connue de la communauté (notamment pour son travail sur Hackaday), a dévoilé OrthoRoute, un plugin pour KiCad qui promet de dompter les designs « monstrueux » grâce à l’accélération GPU. L’idée n’est pas neuve : le routage assisté par GPU est exploré depuis une dizaine d’années dans le monde académique et pour les circuits intégrés (avec des outils comme VPR ou DREAMPlace). Mais l’adapter à un logiciel open source de conception de PCB, et le rendre accessible via un simple plugin, voilà qui change la donne.

La question centrale est simple : l’autoroutage GPU peut-il vraiment révolutionner le workflow des concepteurs de PCB, ou n’est-il qu’une démonstration technique fascinante mais inutilisable en pratique ? Pour y répondre, plongeons sous le capot.

PathFinder sous le capot : l’algorithme FPGA qui dompte les PCB

OrthoRoute ne réinvente pas la roue : il emprunte un algorithme éprouvé dans le routage de FPGA, le PathFinder, et l’adapte au monde des PCB. PathFinder a été initialement développé pour router les réseaux logiques programmables, où la congestion est le problème central. Son principe est élégant : plutôt que d’essayer de trouver un routage parfait du premier coup, il procède par itérations successives.

Première passe : greedy. On route tous les nets de manière gloutonne, sans se soucier des conflits. Chaque net prend le chemin le plus court possible sur la grille de Manhattan (traces orthogonales uniquement, avec vias enterrés ou borgnes). Forcément, certaines arêtes ou nœuds se retrouvent surutilisés – c’est la congestion.

Itérations suivantes : négociation. Le coût des arêtes et nœuds congestionnés est augmenté, et on reroute les nets qui les empruntent. Ceux-ci sont alors incités à trouver des chemins alternatifs, même plus longs. Le processus se répète jusqu’à ce que tous les conflits soient résolus, ou qu’un nombre maximal d’itérations soit atteint. C’est ce qu’on appelle une « négociation basée sur la congestion ».

Comme l’explique le dépôt GitHub du projet, OrthoRoute traite le PCB comme un graphe : les nœuds sont les intersections d’une grille x-y où les vias peuvent être placés, et les arêtes sont les segments entre intersections où les pistes de cuivre peuvent circuler. Chaque arête et chaque nœud est traité comme une ressource partagée. L’idée simplifiée : placer tous les composants sur la couche supérieure, et sur les couches inférieures créer une grille de pistes – uniquement horizontales sur une couche, uniquement verticales sur la suivante, et ainsi de suite. Le routage se fait à travers cette « grille de Manhattan » avec des vias borgnes et enterrés.

Cette approche est particulièrement adaptée à la parallélisation, car chaque itération peut être traitée indépendamment pour chaque net – du moins en partie. Mais attention : contrairement à ce qu’on pourrait croire, PathFinder ne route pas tous les nets en parallèle. Les nets sont traités séquentiellement sur une carte de congestion partagée. C’est à l’intérieur de chaque recherche de chemin que le GPU entre en jeu.

Comparé aux algorithmes CPU classiques (A*, Lee), PathFinder présente un avantage fondamental : il ne cherche pas une solution optimale globale, mais une solution réalisable par itérations. Cela le rend plus tolérant aux grands graphes et aux contraintes multiples. Là où un A* classique exploserait en mémoire sur un design à 20 couches et 5000 nets, PathFinder peut converger en un nombre raisonnable d’itérations, à condition que chaque recherche de chemin soit rapide.

CUDA au service du plus court chemin : comment la parallélisation change la donne

Le cœur de l’accélération GPU dans OrthoRoute repose sur le calcul du plus court chemin dans un graphe pondéré. Pour chaque net, il faut trouver le chemin de moindre coût entre ses broches, en tenant compte des coûts dynamiques (congestion, longueur, vias). Ce problème, connu sous le nom de SSSP (Single-Source Shortest Path), est classiquement résolu par l’algorithme de Dijkstra. Sur CPU, Dijkstra traite les nœuds un par un, avec une file de priorité.

Sur GPU, on peut implémenter un « parallel Dijkstra » où plusieurs nœuds sont explorés simultanément. C’est exactement ce que fait OrthoRoute avec CUDA. La carte de congestion est représentée sous forme de grille 3D (couches × lignes × colonnes), chaque cellule étant un nœud du graphe. Le GPU peut alors lancer des milliers de threads pour explorer les voisins en parallèle, réduisant drastiquement le temps de calcul pour chaque net.

Cependant, le parallélisme reste limité. Comme mentionné plus haut, les nets sont routés séquentiellement : on ne peut pas lancer 5000 Dijkstra en même temps, car ils partagent la même carte de congestion. Chaque net modifie la carte après son routage, ce qui impose une dépendance de données. Le gain vient donc de la rapidité de chaque recherche individuelle, pas d’un parallélisme massif entre nets.

Une autre contrainte est la mémoire VRAM. La grille de Manhattan pour un PCB de 300×300 mm avec une résolution de 0,1 mm et 20 couches représente environ 18 millions de nœuds. Chaque nœud doit stocker son coût, son état, et les liens vers ses voisins. Avec des données 32 bits, on atteint plusieurs centaines de mégaoctets – ce qui tient sur une carte graphique récente (8 Go ou plus). Mais pour des designs encore plus grands ou avec une résolution plus fine (0,05 mm pour les BGA à pas fin), la mémoire peut devenir un goulot d’étranglement. Le développeur lui-même prévient que l’outil est utile à « environ cinq personnes sur la planète », soulignant le caractère encore très niche de l’approche.

Benchmarks enfin disponibles : ce que disent vraiment les chiffres

Contrairement à ce que nous écrivions dans une version antérieure de cet article, des benchmarks chiffrés existent désormais. Le dépôt GitHub d’OrthoRoute référence un article académique intitulé PCBWorld: A Benchmark Environment for Engine-Grounded PCB Design Automation (Song et al.), dans lequel OrthoRoute a été comparé à FreeRouting, KiCadRoutingTools et plusieurs agents de routage par apprentissage sur des jeux de données synthétiques et open-source.

Les résultats sont sans appel pour les designs classiques :

• Sur le jeu de données synthétique D2, OrthoRoute n’a obtenu qu’un taux de passage propre de 1 % et une routabilité de 30 %.
• Sur D3-A, un ensemble de 99 cartes open-source, il a atteint 2 % de passage propre et 51 % de routabilité.
• En comparaison, FreeRouting et KiCadRoutingTools ont obtenu des performances dramatiquement meilleures sur ces mêmes jeux de données.

Il est crucial de noter que ces benchmarks ont été réalisés sur des cartes de petite taille et de complexité ordinaire, avec les paramètres par défaut d’OrthoRoute. Ils ne testent pas la charge de travail cible de l’outil : les backplanes de plusieurs milliers de nets. L’auteur précise d’ailleurs que ces résultats démontrent qu’OrthoRoute est un très mauvais choix par défaut pour le routage de PCB ordinaires.

En revanche, pour le design qui a motivé sa création – un backplane de 16 connecteurs, 1 100 broches par connecteur, soit 17 600 pads et 8 192 airwires –, les performances sont radicalement différentes. Là où FreeRouting n’a routé que 4 % des traces en sept heures, OrthoRoute parvient à router l’intégralité du design en un temps bien plus court (le développeur n’a pas publié de chiffre exact, mais évoque « quelques heures »). C’est sur ce type de design que l’accélération GPU et l’algorithme PathFinder montrent leur intérêt.

Le tableau ci-dessous résume les différences conceptuelles et les performances connues :

Quels designs pour quel gain ? Scénarios d’usage potentiels

Malgré des performances médiocres sur les designs classiques, OrthoRoute peut apporter un gain décisif dans des cas très spécifiques, en se basant sur la description de l’outil et les limitations des routeurs CPU.

Grands backplanes multi-couches. Ces cartes comportent souvent plusieurs centaines de nets répartis sur 12 à 30 couches, avec des contraintes de routage orthogonales. Les routeurs CPU classiques s’effondrent sur de tels designs, car la taille du graphe et le nombre de chemins possibles deviennent prohibitifs. PathFinder, avec sa négociation itérative, est conçu pour ce type de problème. Le cas d’usage initial d’OrthoRoute – un backplane de 8 192 nets – en est la preuve.

Motifs BGA à pas fin (0,5 mm ou moins). Le fan-out d’un BGA dense nécessite de nombreuses micro-vias et des chemins complexes pour sortir les signaux des rangées intérieures. Les routeurs CPU ont du mal à gérer la densité et la congestion locale. L’approche itérative de PathFinder pourrait mieux gérer ces goulots d’étranglement.

Cartes à très haute densité d’interconnexion (HDI). Avec des vias borgnes et enterrés, des pistes fines, et des empilages complexes, ces designs sont un cauchemar pour l’autoroutage traditionnel. OrthoRoute supporte nativement les vias enterrés/borgnes dans sa grille Manhattan, ce qui le rend potentiellement adapté.

En revanche, pour les designs haute vitesse (contraintes de longueur, impédance contrôlée) et RF (via stitching, blindage), l’autoroutage automatique – même accéléré par GPU – reste très difficile. Ces domaines exigent un contrôle fin des géométries, des paires différentielles, des longueurs matchées, et une gestion des couches de référence. Aucun autorouteur actuel ne gère correctement ces contraintes, et OrthoRoute ne fait pas exception. Le développeur ne mentionne d’ailleurs aucun support pour les règles de conception avancées.

Les angles morts de l’autoroutage GPU : règles, DFM, et designs mixtes

OrthoRoute est une preuve de concept impressionnante, mais ses limites sont nombreuses et clairement assumées par son auteur.

Absence de gestion des règles de conception complexes. Le plugin ne prend pas en compte les net classes, les clearances spécifiques, les paires différentielles, les contraintes d’impédance, ou les longueurs maximales/minimales. Il se contente de router des connexions point à point sur une grille, sans savoir qu’un signal analogique doit être éloigné d’un signal numérique, ou qu’une horloge doit avoir une longueur contrôlée. Pour tout design non trivial, le résultat nécessitera une reprise manuelle importante.

Pas de support pour les designs mixtes analogiques/numériques. La séparation des plans de masse, la gestion des boucles de courant, le découplage : autant de contraintes que l’autoroutage ignore superbement. OrthoRoute ne fait pas exception, et son auteur le reconnaît volontiers.

Aucune considération DFM. L’outil ne vérifie pas si les angles des pistes respectent les contraintes de fabrication, si les vias sont assez espacés des pads, ou si les couronnes sont suffisantes. Le résultat devra passer par une passe de nettoyage manuelle et une validation DRC rigoureuse avant envoi en fabrication.

Le contexte KiCad 10. Il faut noter que ce plugin s’inscrit dans un écosystème KiCad 10 en pleine effervescence. La version 10.0.6, sortie en août 2026, a stabilisé la majeure lancée en mars 2026, avec notamment un éditeur de règles DRC graphique, le routage différentiel haute vitesse et les variantes de conception. La bibliothèque CERN a franchi le cap des 17 000 composants validés. D’autres outils d’autoroutage GPU émergent également, comme PCB Auto Router, qui promet un routage accéléré par GPU avec support des paires différentielles et de l’adaptation de longueur. Mais aucun n’a encore publié de benchmarks aussi détaillés que ceux d’OrthoRoute.

Verdict : un outil de niche, pas une révolution généralisée

Au final, OrthoRoute est un outil remarquablement honnête sur ses propres limites. Son auteur le dit sans détour : « OrthoRoute n’est pas un autorouteur généraliste. Il est conçu pour une classe étroite de backplanes extrêmement grands, denses et très réguliers, et de motifs d’évasion BGA. Il est utile à environ cinq personnes sur la planète, et vous n’en faites probablement pas partie. Pour un PCB conventionnel, utilisez autre chose. »

Cette transparence est rafraîchissante dans un monde où les promesses marketing dépassent souvent la réalité. Les benchmarks de PCBWorld confirment que pour les designs ordinaires, FreeRouting et KiCadRoutingTools restent largement supérieurs. Mais pour le cas d’usage précis qui a motivé sa création – le backplane de 8 192 nets –, OrthoRoute fait ce qu’aucun autre outil open source ne sait faire : router l’intégralité du design en quelques heures, là où FreeRouting abandonne après 4 % en sept heures.

La vraie question pour l’avenir est de savoir si cette approche GPU pourra être généralisée à des designs plus variés, avec la prise en compte des règles de conception avancées. En attendant, OrthoRoute reste une démonstration technique fascinante, un outil de niche pour les concepteurs de backplanes, et une source d’inspiration pour la prochaine génération d’autorouteurs. Dans un écosystème KiCad 10 qui s’emballe entre plugins IA, autoroutage GPU et bibliothèque CERN, il incarne à la fois le meilleur et le plus frustrant de l’innovation open source : une avancée spectaculaire, mais cantonnée à un domaine très étroit.

Sources

• Dépôt GitHub OrthoRoute
• Build log d’OrthoRoute par Brian Benchoff
• Article Hackaday : GPU-Accelerated Autorouter Handles Monstrous PCB Designs
• Article Hackster.io sur OrthoRoute
• PCB Auto Router – Intelligent PCB Auto Routing Tool
• KiCad 10.0.5 Release (kicad.org)
• KiCad 10.0.5 Release Candidate 1 (kicad.org)
• L’autoroutage Kicad simplifié – Groupe Kunming PCBA
• KiCad Autorouting Made Easy (rottenwifi.com)

Article recherché et rédigé automatiquement · Magazine Electrosens