Kicad Master · 24 October 2026

OrthoRoute : l’autorouteur GPU de KiCad à l’épreuve des faits (2026)

Depuis des décennies, l’autoroutage de PCB reste le parent pauvre de la CAO électronique : lent, rigide, cantonné aux designs simples. En 2026, un plugin KiCad nommé OrthoRoute bouscule ce dogme en exploitant la puissance des GPU pour router des cartes que les algorithmes classiques n’osent même pas effleurer. Mais entre la promesse technique et l’adoption réelle, le fossé reste immense — et les benchmarks publiés viennent sérieusement tempérer l’enthousiasme. Décryptage d’une innovation qui pourrait — ou pas — changer la donne pour les concepteurs de cartes complexes, à l’heure où KiCad 10.0.x achève son cycle de rattrapage.

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 comme les modes Walk Around et Shove de KiCad, complétés par FreeRouting pour les cas les plus lourds.

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. Hackaday, qui a relayé le projet le 1er juillet 2026, résume bien l’esprit : Benchoff avait « un véritable monstre de PCB avec des milliers de nets à router », un design qui aurait pris des mois à la main, et il a créé OrthoRoute pour résoudre ce problème précis — en prévenant lui-même que l’outil n’est « pas plus digne de confiance que n’importe quel autre autorouteur, mais au moins il est rapide ».

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 — puis confrontons la promesse aux chiffres.

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 (publié à l’origine par McMurchie et Ebeling, référence ACM), 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.

Un point important, souligné par Hackaday : OrthoRoute ne gère que les composants montés en surface — pas de traversant. Tous les composants vont sur la couche supérieure, et les couches inférieures ne contiennent que la grille de routage. C’est une contrainte de conception forte, qui limite d’emblée le champ d’application.

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 » — Hackaday parle de « peut-être une poignée de personnes tout au plus » —, 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.

À noter par ailleurs que FreeRouting n’est pas non plus exempt de défauts : une régression signalée fin août 2026 sur la version 2.3.0 fait état de routes qui présentent des violations de clearance auto-déclarées, là où la 2.2.4 routait proprement. Un rappel utile que l’autoroutage, CPU comme GPU, exige systématiquement une validation DRC derrière.

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 — à condition toutefois que le design reste en CMS pur.

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. C’est précisément le terrain où KiCad 10.0.x a progressé côté manuel — routage différentiel haute vitesse, éditeur de règles DRC graphique, variantes de conception — mais ces avancées concernent le routage assisté, pas l’autoroutage GPU.

Les angles morts de l’autoroutage GPU : règles avancées, traversants et confiance

L’enthousiasme autour d’OrthoRoute ne doit pas masquer une série de limites structurelles, qui expliquent pourquoi l’outil reste, de l’aveu même de son auteur, une curiosité pour happy few.

Pas de traversants. L’impossibilité de placer des composants traversants est un frein majeur : beaucoup de designs réels (connecteurs, alimentation, relais) en comportent. OrthoRoute impose un monde 100 % CMS, ce qui exclut de facto une large partie des cartes de prototypage et d’industrie.

Pas de règles avancées. Impédance contrôlée, paires différentielles, longueurs matchées, contraintes de couches de référence : rien de tout cela n’est pris en charge. Pour un backplane lent, ce n’est pas bloquant ; pour une carte série-différentielle, c’est rédhibitoire.

La confiance, nerf de la guerre. Benchoff lui-même avertit que son autorouteur n’est « pas plus digne de confiance que n’importe quel autre ». La leçon vaut pour tous : un routage automatique doit être validé par DRC et inspection visuelle. Les déboires de FreeRouting 2.3.0 (violations de clearance auto-déclarées) rappellent que même les outils matures peuvent produire des routes douteuses. La bonne pratique 2026 reste : configurer les règles, placer les composants intelligemment, router en Walk Around/Shove, puis passer l’autorouteur et toujours valider par DRC et contrôles de fabrication.

Un écosystème qui bouge, mais sans OrthoRoute au premier plan. L’écosystème des plugins KiCad s’est considérablement structuré en 2026 — l’API est mûre, le Plugin and Content Manager centralise l’installation, et des projets comme Quilter ou PCB Auto Router occupent le terrain de l’autoroutage assisté par apprentissage. OrthoRoute, lui, reste un projet de recherche personnel, modulaire et ouvert, dont « les parties difficiles sont toutes faites » selon Hackaday — une base à réutiliser ou étendre plus qu’un produit prêt à l’emploi.

Ce qu’il faut retenir pour un utilisateur de KiCad en 2026

OrthoRoute n’est pas l’autorouteur universel dont rêvent les concepteurs. C’est une preuve de concept aboutie qui démontre que l’accélération GPU du routage PCB est faisable dans KiCad, et qui excelle sur un cas extrême — le backplane géant — là où les routeurs CPU abandonnent. Pour 99 % des cartes du quotidien, FreeRouting et les outils intégrés restent de bien meilleurs choix, comme le confirment les benchmarks D2 et D3-A.

L’intérêt réel du projet est ailleurs : il ouvre une voie. Si la communauté s’empare du code modulaire de Benchoff pour y greffer la gestion des traversants, des règles avancées et une meilleure intégration DRC, l’autoroutage GPU pourrait devenir une brique sérieuse du workflow KiCad. En attendant, la règle d’or demeure : autorouter, oui ; faire confiance, jamais sans DRC.

Pour aller plus loin, le dépôt GitHub et la page portfolio de Benchoff contiennent le code, les vidéos de démonstration et les détails d’implémentation. Et pour replacer OrthoRoute dans le paysage KiCad 2026 — KiCad 10.0.7 sortie le 7 octobre 2026, 10.0.8 en release candidate depuis le 22 octobre, importateurs natifs Allegro/PADS/gEDA, DRC graphique, variantes de conception —, notre dossier sur l’écosystème 10.0.x reste la meilleure porte d’entrée.

Sources

• GPU-Accelerated Autorouter Handles Monstrous PCB Designs — Hackaday (1er juillet 2026)
• OrthoRoute — dépôt GitHub (bbenchoff/OrthoRoute)
• OrthoRoute — Benchoff Design Portfolio
• PathFinder — référence ACM (McMurchie & Ebeling)
• OrthoRoute: GPU-Accelerated Autorouting Comes to KiCad in 2026 — nextpcbgen
• KiCad Version 10.0.7 Release Candidate 2 Available — kicad.org (3 octobre 2026)
• KiCad 10.0.6 Release — kicad.org (29 août 2026)
• 2.3.0 regression: routes ship self-reported clearance violations — FreeRouting (GitHub, 28 août 2026)
• KiCad Autorouting Made Easy: Walk Around, Shove, and Freerouting — rottenwifi.com (13 août 2026)
• awesome-kicad — liste de plugins et extensions (joanbono)

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