TD: Introduction aux automates matériels

Transparents du mini cours sur les automates matériels

Sommaire

  1. Mini-cours sur les bus de communication
  2. Le contrôleur de bus simple
  3. Le problème de l'équité

1. Mini-cours sur les bus de communication

Qu'est-ce qu'un bus de communication ? Lorsque, au sein d'un système complexe, plusieurs dispositifs électroniques doivent communiquer entre eux on peut imaginer de relier chaque élément à tous les autres. Cette situation, illustrée par la figure ci-dessous, est probablement la première qui vient à l'esprit. C'est aussi la plus puissante car elle permet un nombre très important de communications simultanées.

Malheureusement elle est aussi très coûteuse car le nombre de connexions nécessaires est très important. Il suffit d'imaginer pour s'en convaincre que les arcs du schéma ci-dessus véhiculent des informations codées sur 32 bits. En outre elle n'offre pas une grande flexibilité car il n'est pas possible d'ajouter des éléments à notre réseau (le nombre d'entrées et de sorties de chaque élément est fixé à la construction). Ce système n'est pas très "plug and play". C'est dommage car le "plug and play" est justement très à la mode. Une autre solution, plus raisonnable et aussi plus courante, est le bus central :

Les possibilités d'échanges sont limitées mais chaque élément peut tout de même communiquer avec n'importe quel autre et le nombre de connexions est considérablement réduit. Il est en outre théoriquement possible d'ajouter à l'infini de nouveaux éléments au système. La gestion d'une telle organisation des communications nous servira de thème tout au long de ce TD.

2. Le contrôleur de bus simple.

Nous nous proposons de concevoir un contrôleur de bus de communication. Le système au sein duquel notre contrôleur doit s'intégrer comporte un arbitre de bus et un nombre indéterminé mais potentiellement très grand de points d'accès au bus. Chaque point d'accès est composé d'un contrôleur et d'un client. La figure ci-dessous représente le système de communication complet :

L'arbitre est chargé de répartir la ressource de communication (le bus) entre les différents points d'accès. En effet, le système n'admet pas que plusieurs points d'accès émettent simultanément des informations sur le bus. Si cela se produisait il y aurait conflit et perte d'informations. La présence d'un arbitre est donc nécessaire. C'est lui qui autorise successivement les points d'accès à écrire sur le bus en leur attribuant un "jeton". Le point d'accès possesseur du jeton peut écrire sur le bus. Les autres ne peuvent que lire. Lorsque le point d'accès a terminé sa transaction il rend le jeton à l'arbitre qui peut alors l'attribuer à un autre point d'accès. L'absence de conflit est garantie par l'unicité du jeton.

Les clients sont les utilisateurs du bus. Lorsqu'un client désire écrire sur le bus il en informe son contrôleur associé et attend que celui-ci obtienne le jeton et lui donne le feu vert.

Les contrôleurs servent d'interface entre l'arbitre et leur client. C'est l'un de ces contrôleurs que nous allons concevoir. Ses entrées - sorties sont décrites dans le schéma et la table ci-dessous. A l'exception de l'horloge et du signal de reset toutes les entrées - sorties sont actives à '1'.

 

 

Nom Direction Description
CLK (Clock) Entrée Horloge principale. Le contrôleur est synchrone sur front montant de cette horloge.
RST (Reset) Entrée Signal de reset asynchrone, actif à '0'. Lorsque ce signal est à état bas ('0') le contrôleur est entièrement réinitialisé.
TOK (Token) Entrée Ce signal provient de l'arbitre et indique que le contrôleur peut disposer du bus. Il signifie donc que l'arbitre offre le jeton au contrôleur. Il n'est actif que pendant une période d'horloge. Si le contrôleur n'a pas besoin du jeton il le rend (voir le signal PSS). Sinon il le garde jusqu'à ce qu'il n'en ait plus l'utilité.
REQ (Request) Entrée Ce signal est émis par le client et indique que ce dernier demande à disposer du bus. Le client maintient ce signal jusqu'à la fin de sa transaction sur le bus. Il ne le relache que lorsqu'il n'a plus besoin du bus.
ACK (Acknowledge) Entrée Ce signal provient du client et indique que le client a pris le bus et commence sa transaction. Il n'est actif que pendant une période d'horloge.
PSS (Pass Token) Sortie Ce signal est destiné à l'arbitre et l'informe que le contrôleur rend le bus, soit parce que l'arbitre le lui a proposé alors qu'il n'en a pas besoin, soit parce que la transaction du client est terminée. Il signifie donc que le contrôleur rend le jeton à l'arbitre qui pourra ensuite en disposer et l'attribuer à un autre contrôleur, voire au même. Il n'est actif que pendant une période d'horloge.
GNT (Grant) Sortie Ce signal est destiné au client et l'informe qu'il peut disposer du bus. Il est maintenu tant que le client n'a pas répondu (par le signal ACK) qu'il a pris le bus.

Le graphe d'états.

  • 2.1 Dessinez un chronogramme représentant une ou plusieurs transactions complètes entre un contrôleur, son client et l'arbitre.
  • 2.2 Le contrôleur est un automate synchrone. Imaginez et dessinez son graphe.
  • 2.3 Vérifiez la cohérence du graphe (complet, non contradictoire)
  • 2.4 Ecrivrez le code SystemVerilog de votre automate

Une optimisation possible.

Les échanges entre l'arbitre et le contrôleur (signaux TOK et PSS) présentent l'inconvénient de ralentir inutilement les opérations et donc de gaspiller des cycles d'utilisation du bus. En effet, un cycle est perdu lorsqu'un contrôleur se voit proposer le jeton alors qu'il n'en a pas l'usage. Le chronogramme ci-dessous illustre ce phénomène :

TOKA et TOKB sont les signaux TOK destinés à deux contrôleurs, A et B. PSSA est le signal PSS émis par le contrôleur A et indiquant qu'il rend le jeton que l'arbitre vient de lui confier et dont il n'a pas l'usage. On voit que l'arbitre, lui aussi synchrone sur front montant de CLK, ne peut pas proposer immédiatement le jeton à un autre contrôleur.

Pour améliorer les performances du système nous voudrions obtenir le chronogramme suivant :

  • 2.5 Proposez des modifications du contrôleur permettant d'obtenir ce nouveau comportement.
  • 2.6 Décrivez l'automate en langage SystemVerilog.

3. Le problème de l'équité.

Le contrôleur équitable.

Le contrôleur que nous venons de concevoir n'est pas entièrement satisfaisant car il n'est pas équitable. En d'autres termes, il ne garantit pas qu'un client n'accaparera pas le bus au détriment des autres. Il ne garantit même pas qu'un client, après avoir obtenu l'accès au bus, l'utilisera effectivement puis le relachera. Il est en effet possible qu'un client ne réponde jamais au signal GNT de son contrôleur (ce qu'il est sensé faire à l'aide du signal ACK). Le système complet serait alors bloqué par un "mauvais" client qui monopolise une ressource dont il n'a pas l'usage. Pour remédier à cet inconvénient il faut à nouveau modifier le contrôleur.

  • 3.1 Imaginez des solutions afin de rendre équitable le contrôleur optimisé du premier exercice

L'arbitre équitable.

Pour obtenir que l'ensemble du système soit équitable la modification du contrôleur seul ne suffit pas. L'arbitre doit, lui aussi, adopter un comportement particulier. 

  • 3.2 Pourquoi ? Donnez un exemple de comportement non équitable possible de l'arbitre et ses conséquences.
  • 3.3 Imaginez et décrivez des comportements possibles de l'arbitre équitable.

Correction du TD

La correction sera disponible après la dernière séance du TD.