Réponse courte: les gestionnaires veulent une preuve de fonction simple et testable avant de s'engager à des millions (ou plus) de dollars dans une conception. Les outils actuels ne donnent tout simplement pas ces réponses aux conceptions asynchrones.
Les micro-ordinateurs et microcontrôleurs utilisent généralement un schéma de synchronisation pour assurer le contrôle de la synchronisation. Tous les coins de processus doivent maintenir la synchronisation à travers tous les effets de tension, température, processus, etc. sur les vitesses de propagation du signal. Il n'y a pas de portes logiques actuelles qui changent instantanément: chaque porte commute en fonction de la tension qui lui est fournie, du lecteur qu'elle reçoit, de la charge qu'elle pilote et de la taille des appareils qui sont utilisés pour la fabriquer, (et bien sûr le nœud de processus (taille de l'appareil) dans lequel il est fabriqué, et à quelle vitesse CE processus se déroule réellement --- CECI passe par le fab). Pour passer à la commutation "instantanée", vous devez utiliser la logique quantique, ce qui suppose que les appareils quantiques peuvent basculer instantanément; (Je ne suis pas sûr).
La logique cadencée permet de prouver que la synchronisation sur l'ensemble du processeur fonctionne sur les variables de tension, de température et de traitement attendues. Il existe de nombreux outils logiciels disponibles qui permettent de mesurer ce timing, et le processus net est appelé «fermeture du timing». La synchronisation peut (et, selon mon expérience, le fait ) prendre entre 1/3 et 1/2 de la puissance utilisée dans un microprocesseur.
Alors, pourquoi pas une conception asynchrone? Il existe peu ou pas d'outils de fermeture de synchronisation pour prendre en charge ce style de conception. Il existe peu ou pas d'outils automatisés de localisation et de routage qui peuvent gérer et gérer une grande conception asynchrone. Si rien d'autre, les gestionnaires n'approuvent rien qui n'a pas de preuve de fonctionnalité simple et générée par ordinateur.
Le commentaire selon lequel la conception asynchrone nécessite "une tonne de" signaux de synchronisation, ce qui nécessitait "beaucoup plus de transistors", ignore les coûts de routage et de synchronisation d'une horloge globale, ainsi que le coût de toutes les bascules qu'exige le système d'horloge. Les conceptions asynchrones sont, (ou devraient être), plus petites et plus rapides que leurs homologues synchronisées. (On prend simplement le chemin de signal ONE le plus lent, et l'utilise pour renvoyer un signal "prêt" à la logique précédente).
La logique asynchrone est plus rapide, car elle n'a jamais à attendre une horloge qui a dû être étendue pour un autre bloc ailleurs. Cela est particulièrement vrai dans les fonctions de registre à logique à registre. La logique asynchrone n'a pas de multiples problèmes de "configuration" et de "maintien", car seules les structures réceptrices terminales (registres) ont ces problèmes, contrairement à un ensemble logique de pipelines avec des bascules entrecoupées pour espacer les délais de propagation de la logique jusqu'à l'horloge limites.
Peut-on le faire? Certainement, même sur un milliard de transistors. Est-ce plus difficile? Oui, mais seulement parce que prouver qu'il fonctionne sur une puce entière (ou même un système) est beaucoup plus impliqué. Obtenir le timing sur papier est raisonnablement direct pour n'importe quel bloc ou sous-système. Il est beaucoup plus difficile de contrôler ce chronométrage dans un système automatisé de localisation et d'itinéraire, car l'outillage n'est PAS configuré pour gérer l'ensemble potentiel de contraintes de chronométrage beaucoup plus important.
Les microcontrôleurs ont également un ensemble potentiellement important d' autres blocs qui s'interfacent avec des signaux externes (relativement) lents, ajoutés à toute la complexité d'un microprocesseur. Cela rend le timing un peu plus compliqué, mais pas beaucoup.
La réalisation d'un mécanisme de signal de «verrouillage» du premier arrivé est un problème de conception de circuit, et il existe des moyens connus pour y faire face. Les conditions de course sont un signe de 1). mauvaise pratique de conception; ou 2). signaux externes entrant dans le processeur. La synchronisation introduit en fait une condition de concurrence signal / horloge qui est liée aux violations de "configuration" et de "maintien".
Personnellement, je ne comprends pas comment une conception asynchrone pourrait entrer dans une situation de blocage ou dans toute autre condition de concurrence. Cela pourrait bien être ma limitation, mais à moins que cela ne se produise lors de l'entrée de données dans le processeur, cela ne devrait JAMAIS être possible dans un système logique bien conçu, et même alors, puisque cela peut se produire lorsque les signaux entrent, vous concevez pour y faire face.
(J'espère que ça aide).
Cela dit, si vous avez de l'argent ...