Découvrir le langage Lucid avec une carte de développement FPGA d’Alchitry

Le code du module débute avec la déclaration des ports. C’est l’endroit où vous déclarez les entrées-sorties de votre module.

module au_top (
    input clk,              // 100MHz clock
    input rst_n,            // reset button (active low)
    output led [8],         // 8 user controllable LEDs
    input usb_rx,           // USB->Serial input
    output usb_tx           // USB->Serial output
  )

Dans ce cas, comme il s’agit du module principal, ces déclarations référencent les signaux disponibles sur les périphériques de la carte elle-même : horloge 100 MHz, bouton reset, jeu de 8 LED programmables, et port USB. Les localisations des broches de la puce vers lesquelles sont dirigées les entrées-sorties du module principal sont définies dans le fichier alchitry.acf (Alchitry Constraint File) à la rubrique Constraints de l’explorateur.

Le code à partir de la ligne 11 montre le contenu d’un bloc d’instanciation :

  .clk(clk) {
    // The reset conditioner is used to synchronize the reset signal to the FPGA
    // clock. This ensures the entire FPGA comes out of reset at the same time.
    reset_conditioner reset_cond;
  }

Ce genre de blocs s’écrit sous la forme :

.port_name(EXPR), #PARAM_NAME(CONST_EXPR) {
SIGNAL_AND_MODULE_INSTANCES
}

À l’intérieur du bloc, vous trouvez ligne 14 une déclaration d’instance de module.

Pour toute instanciation, vous utilisez tout simplement le nom de la ressource suivi par le nom de cette instance particulière. Ainsi, la ligne reset_conditioner reset_cond; crée une instance du module reset_conditioner nommée reset_cond.

Le bloc débute avec une syntaxe du type .port(signal) qui permet de déclarer des connexions.

Dans notre cas, le module comporte un port clk, et ce port clk de l’instance est donc connecté au signal clk du module principal « top ».

Plus loin dans le code , l’entrée de cette instance est reliée au bouton reset de la carte :

reset_cond.in = ~rst_n; // input raw inverted reset signal

Le bloc always est l’endroit où vous décrivez toute la logique du comportement de votre module.

À l’intérieur du bloc always, un ensemble de déclarations structurelles ou comportementales : affectations de signaux, structures conditionnelles if ou case, boucles for, etc.

Ici, le bloc ne comprend que des affectations de signaux. Il faut imaginer des câbles de connexion tendus entre les signaux dont les expressions figurent de part et d’autre du signe = (avec la condition que l’on puisse « écrire » sur le signal de l’expression à gauche du signe =, et que le signal de l’expression à sa droite puisse être « lu »).

  always {
    reset_cond.in = ~rst_n; // input raw inverted reset signal
    rst = reset_cond.out;   // conditioned reset

    led = 8h00;             // turn LEDs off

    usb_tx = usb_rx;        // echo the serial data
  }

Dans l’ordre :

• l’entrée in de l’instance reset_cond est connectée au signal (inversé avec ~) du bouton reset ;
• le signal rst provient de la sortie out de l’instance reset_cond ;
• les signaux dirigés vers les 8 LED sont à l’état bas (8h00 : signal de largeur 8 bits mis à zéro, h pour indiquer un format hexadécimal) ;
• les signaux reçus sur Rx de la liaison série sont renvoyés vers Tx.

La configuration conçue avec le fichier au_top.luc par défaut peut être résumée par le schéma-blocs suivant :

Réalisé sous Word, ce schéma n’est en rien normalisé, mais il est très utile en phase de réflexion pendant la mise au point du projet. Il est toutefois très proche de celui obtenu après coup avec une analyse sous Vivado :

Finalement, toute cette partie met à disposition un circuit de conditionnement du signal sur appui du bouton reset, synchronisé avec l’horloge. Le signal rst en sortie est indispensable pour réinitialiser proprement (et simultanément) les composants de votre projet (reset local).

Un blinker pour débuter, quelle surprise !

Le schéma-blocs du projet ci-dessous comprend deux instances d’un nouveau module blinker : myBlinker et myOtherBlinker. Chaque blinker a deux entrées (signal d’horloge clk et reset rst) et une sortie out. Sur la sortie out d’un blinker, le module génère un signal carré de période donnée. Il reste à connecter la sortie out d’un blinker à une LED pour la faire clignoter.

On repart du module principal au_top.luc d’un nouveau projet que l’on complète ainsi :

module au_top (
    input clk,              // 100MHz clock
    input rst_n,            // reset button (active low)
    output led [8],         // 8 user controllable LEDs
    input usb_rx,           // USB->Serial input
    output usb_tx           // USB->Serial output
  ) {
  
  sig rst;                  // reset signal
  
  .clk(clk) {
    // The reset conditioner is used to synchronize the reset signal to the FPGA
    // clock. This ensures the entire FPGA comes out of reset at the same time.
    reset_conditioner reset_cond;
    
    .rst(rst) {
      blinker myBlinker(#DELAY(50000000)); // 50000000 = 0,5s
      blinker myOtherBlinker(#DELAY(25000000)); // 25000000 = 0,25s
      }
  }
  
  always {
    reset_cond.in = ~rst_n; // input raw inverted reset signal
    rst = reset_cond.out;   // conditioned reset
       
    led = c{myOtherBlinker.out, 6x{b0}, myBlinker.out};
    
    usb_tx = usb_rx;        // echo the serial data
  }
}

Lignes 17 et 18 : déclaration de deux instances du module blinker nommées myBlinker et myOtherBlinker. Sur la sortie out d’un blinker, le module génère un signal carré de période donnée. La période est définie grâce au paramètre DELAY. DELAY correspond au nombre de ticks de l’horloge avant basculement de l’état du signal. Avec une horloge à 100 MHz, soit 100 millions de ticks par seconde, un DELAY fixé à 50 millions générera un basculement on/off ou off/on toutes les 0,5 s, et donc un signal carré de période 1 s.

Notez comment sont imbriquées les connexions aux ports. L’instance reset_cond est connectée à l’horloge clk seule. Les deux instances de blinker sont reliées à l’horloge clk et au signal reset rst.

Ligne 26 : les sorties des deux instances de blinker sont dirigées vers les LED. La syntaxe c{…} permet la concaténation de tableaux. Ici, on concatène la sortie myOtherBlinker.out (largeur 1 bit) avec 6 bits à 0 puis avec la sortie myBlinker.out (largeur 1 bit). L’ensemble concaténé a une largeur 8 bits et est dirigé vers le tableau led connecté au jeu de 8 LED.

Il reste à coder le comportement du blinker dans un nouveau fichier source blinker.luc rajouté depuis l’EDI :

Mais avant cela, il vous faudra étudier le comportement d’un composant essentiel de logique séquentielle : la bascule D.

VII-A-1. La bascule D▲

Une bascule D (ou D-type Flip Flop, soit DFF) est un circuit logique qui peut mémoriser un état.

Quand précédemment on avait écrit :

 

Sélectionnez

reset_cond.in = ~rst_n;

Vous devez garder à l'esprit que reset_cond.in n’est pas une variable mémorisant une valeur. Vous venez seulement de connecter un point A à un point B pour transporter un signal… c’est tout. Il n’y a pas de valeur stockée dans une variable ici.

Pour autant, un système sans mémoire est plutôt limité, et c’est là que la bascule D intervient.

Une bascule D peut être schématisée comme suit :

Elle a une entrée d’horloge clk de synchronisation (ici, sur front montant de l’horloge).

Le but de ce circuit est de recopier la donnée qui se présente à l’entrée D (Data) sur sa sortie Q à chaque front montant de l’horloge. Entre deux fronts montants de l’horloge, l’état de la sortie Q est maintenu quels que soient les changements sur l’entrée D. Dans cet intervalle de temps, il y a bien un état « mémorisé ».

Ce circuit, dit à logique séquentielle, se distingue des circuits à logique combinatoire où la sortie ne dépend que de l’état courant des entrées.

En Lucid, il n’y a pas explicitement d’interface avec l’entrée en (enable), la bascule est active tant que la carte est alimentée.

Lorsqu’un signal à l’état haut arrive sur l’entrée reset rst (typiquement avec le circuit de reset conditionné et synchronisé vu plus haut pour réinitialiser toutes les bascules du circuit simultanément), la sortie Q est réinitialisée (par défaut à zéro).

Pour déclarer une bascule D en Lucid, il suffit de l’instancier en précisant le type dff :

 

Sélectionnez

dff ma_bascule;

Le fonctionnement de la bascule D peut-être généralisé avec des signaux de largeur n bits.

 

Sélectionnez

dff octet[8];

Dans ce cas, l’octet qui arrive sur D sera recopié sur la sortie Q de largeur 8 bits à chaque front d’horloge.

Comme toute instance, on accède aux entrées-sorties avec la syntaxe : ma_bascule.d, ma_bascule.q, et ma_bascule.rst.

On peut préciser l’état ou la valeur initiale de la sortie Q à la mise en alimentation de la carte ou après un reset avec un paramètre. Par exemple :

 

Sélectionnez

dff compteur[8] (#INIT(100)); // compteur 8 bits initialisé à 100

Tout est prêt pour comprendre le fonctionnement du blinker.

VII-A-2. Module blinker▲

On donne le code du blinker (dans un nouveau fichier blinker.luc rajouté au projet) :

blinker.luc

Sélectionnez

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.

module blinker #(DELAY = 50000000 : DELAY > 0) (
    input clk,  // clock
    input rst,  // reset
    output out  // blink signal
  ) 

{ 
  .clk(clk) {
    .rst(rst) {
      dff counter[$clog2(DELAY)];
      dff blink;
    }    
  }

  always {
    counter.d = counter.q + 1;
    if (counter.q == DELAY - 1) {
      counter.d = 0;
      blink.d = ~blink.q;
    }
    out = blink.q;
  }
}

Lignes 10 et 11 : instanciation de deux bascules D raccordées aux signaux d’horloge clk et de reset rst : counter et blink.

La première bascule est un simple compteur qui s’incrémentera à chaque front montant de l’horloge. La largeur du compteur en nombre de bits dépend de la valeur de DELAY, et est calculée avec la fonction $clog2 (logarithme en base 2).

La deuxième bascule blink produit le signal carré sur sa sortie.

Dans le bloc always, on met en Å“uvre l’incrémentation du compteur : counter.d = counter.q + 1;

Juste avant le débordement du compteur, on remet le compteur à zéro et on bascule l’état du signal en sortie : blink.d = ~blink.q;.

Voici le schéma logique du projet obtenu sous Vivado :

Et maintenant, on admire le résultat après transfert du fichier binaire…

La LED du bas clignote à la fréquence de 1 Hz. Celle du haut clignote deux fois plus vite.

Pour ce deuxième exemple, vous allez avoir besoin d’un générateur de signaux PWM. Vous pourriez le développer vous-même, mais autant vous affranchir de cette tâche en allant piocher un composant dédié dans la bibliothèque de composants proposés depuis l’EDI. Pour cela, il faut aller dans le menu Project→ Add components et cocher Pulse Width Modulator (avec sa dépendance Counter) dans le sélecteur de composants :

Les deux nouveaux fichiers pwm.luc et counter.luc correspondants apparaissent dans les sources à la rubrique Components :

L’analyse de ces fichiers, notamment les commentaires au début et la déclaration des entrées-sorties du module nous renseignent sur leur fonctionnement.

Ainsi, avec l’instanciation suivante dans le module au_top.luc, vous déclarez un générateur PWM nommé myPwm de résolution 8 bits raccordé à l’horloge principale et au signal reset :

clk(clk) {
    // The reset conditioner is used to synchronize the reset signal to the FPGA
    // clock. This ensures the entire FPGA comes out of reset at the same time.
    reset_conditioner reset_cond;
    
    .rst(rst) {
      pwm myPwm(#WIDTH(8));
      // ...
    }

Le but est de générer des vagues avec le jeu de LED qui s’allume progressivement, puis s’éteint progressivement et ainsi de suite, comme le montre la vidéo suivante :

Pour générer ces vagues successives, on va aussi avoir besoin d’un compteur nommé ici counterUp.

counter counterUp(#SIZE(9), #DIV(18), #UP(1));

Le compteur instancié est un compteur 9 bits et la vitesse de comptage dépend de l’horloge 100 MHz associée à un diviseur de fréquence par 2¹⁸. Ainsi, ce compteur va mettre (512 x 2¹⁸) / 100 000 000 = 1,34 s pour évoluer de 0 à 511. Le code devient :

clk(clk) {
    // The reset conditioner is used to synchronize the reset signal to the FPGA
    // clock. This ensures the entire FPGA comes out of reset at the same time.
    reset_conditioner reset_cond;
    
    .rst(rst) {
      pwm myPwm(#WIDTH(8));
      counter counterUp(#SIZE(9), #DIV(18), #UP(1));
    }

Tel quel, le compteur évolue entre 0 et 511 en 1,34 s, mais avec un retour à zéro sur débordement, ce qui donne un signal en dents de scie comme sur la figure ci-dessous :

Si vous voulez générer une « vague » avec des transitions « douces », il faut se rapprocher du signal triangulaire suivant :

Il se trouve que le passage du signal en dents de scie au signal triangulaire est assez aisé à obtenir grâce à une astuce décrite dans un tutoriel sur le site de Sparkfun : First FPGA Project - Getting Fancy with PWM.

Comme le compteur a une résolution de 9 bits, son bit de poids fort est à 1 quand le compteur dépasse la valeur 255. Il faudrait qu’à partir de là le compteur se mette à compter à rebours : 255, 254, 253, etc. Ce compte à rebours peut être obtenu par simple inversion de bits. Si on devait par exemple compter de 0 à 7, cela donnerait en binaire : 000, 001, 010, 011, … , 111. Inversez les bits un par un et vous obtiendrez :111, 110, 101, …, 000, soit le compte à rebours voulu : 7, 6, 5, …, 0.

On va donc rajouter cette ligne dans le bloc always :

myPwm.value = counterUp.value[7-:8] ^ 8x{counterUp.value[8]};

• Le signe ^ est celui du OU exclusif (XOR). En effet, a xor 1 inverse le bit a.
• counterUp.value[7-:8] met de côté le bit 8 de poids fort. On récupère les 8 bits restants à partir du bit 7.
• 8x{counterUp.value[8]} forme un nombre 8 bits en concaténant huit fois le bit de poids fort du compteur, soit 1111 1111 pour toute valeur du compteur à partir de 256, et 0000 0000 sinon.

Faites le calcul à la main avec quelques valeurs pour vérifier que vous avez compris le principe, c’est imparable.

Il reste à diriger la sortie du signal PWM vers le jeu de 8 LED et on obtient le code final :

module au_top (
    input clk,              // 100MHz clock
    input rst_n,            // reset button (active low)
    output led [8],         // 8 user controllable LEDs
    input usb_rx,           // USB->Serial input
    output usb_tx           // USB->Serial output
  ) {
  
   sig rst;                  // reset signal
  
  .clk(clk) {
    // The reset conditioner is used to synchronize the reset signal to the FPGA
    // clock. This ensures the entire FPGA comes out of reset at the same time.
    reset_conditioner reset_cond;
    
    .rst(rst) {
      pwm myPwm(#WIDTH(8));
      counter counterUp(#SIZE(9), #DIV(18), #UP(1));
    }
  }
  
  always {
    reset_cond.in = ~rst_n; // input raw inverted reset signal
    rst = reset_cond.out;   // conditioned reset
    
    myPwm.value = counterUp.value[7-:8] ^ 8x{counterUp.value[8]};
    myPwm.update = 1;  // always update
       
    led = c{8x{myPwm.pulse}};  // pulse leds

    usb_tx = usb_rx;        // echo the serial data
  }
}

Et si vous voulez une validation plus rigoureuse du fonctionnement, vous pouvez vous tourner à nouveau vers la suite Vivado de Xilinx et faire une simulation comportementale. La copie d’écran ci-dessous du résultat de cette simulation montre les signaux du compteur 9 bits (tout en bas, en orange) et de la valeur 8 bits du PWM (juste au-dessus, en rouge) aux alentours de t = 0,67 s. Avant de lancer la simulation, il faut « forcer » le signal d’horloge à 100 MHz et le signal reset rst à 0 :

On voit qu’au-delà de 255 pour le compteur, la valeur du PWM commence à décroître. À t = 0,67 s, les LED sont à la luminosité maximale.

Aux alentours de t = 1,34 s :

Lorsque le compteur 9 bits déborde, la valeur du PWM revient à 0. À ce moment-là, les LED sont éteintes, la première « vague » est passée comme prévu à t = 1,34 s. La simulation montre bien une évolution conforme au signal triangulaire souhaité.

Dans cet exemple, l’unique bouton en surface de la carte est détourné de sa fonction d’origine (reset) pour piloter une LED. Ici, chaque appui sur le bouton doit basculer l’état de la LED. Un premier appui pour allumer la LED, un deuxième appui pour l’éteindre, etc.

Pour cela, il faut détecter les fronts montants du signal. Après quelques tests, on se rend compte aussi qu’un système anti-rebonds sur le bouton (debouncer) est nécessaire pour un bon fonctionnement.

Il y a plusieurs moyens d’atteindre l’objectif, mais ici on fera appel aux composants de la bibliothèque, soit : Button Conditionner, et Edge Detector. Là encore, voir les fichiers source de ces modules pour découvrir les entrées-sorties et les paramètres optionnels.

Le premier composant élimine les rebonds du bouton :

{
      .clk(clk) {  
        // ...
        
           .in(btn) {  
              button_conditioner myButtonCond;
            }
           
        // ...
      }

Et la sortie du conditionneur est raccordée à l’entrée du détecteur de front montant :

{
      .clk(clk) {  
        // ...
        
           .in(btn) {  
              button_conditioner myButtonCond;
            }
          
           .in(myButtonCond.out) {
              edge_detector myEdgeDetector(#RISE(1), #FALL(0));
            }
      }

Voici le code du module toggle_button.luc.

module toggle_button (
    input clk,  // clock
    input btn,  // button
    output out
  ) {
      .clk(clk) {  
        dff toggle;
        
           .in(btn) {  
              button_conditioner myButtonCond;
            }
          
           .in(myButtonCond.out) {
              edge_detector myEdgeDetector(#RISE(1), #FALL(0));
            }
      }

  always {
    out = toggle.q;
    if (myEdgeDetector.out) { 
      toggle.d = ~toggle.q;
    }
  }
}

Dans le bloc always, on organise la sortie out de façon à basculer uniquement sur front montant du signal d’entrée (le bouton).

Et voici le code du module principal au_top.luc, qui instancie un toggle_button. La sortie est dirigée vers les LED :

module au_top (
    input clk,              // 100MHz clock
    input rst_n,            // reset button (active low)
    output led [8],         // 8 user controllable LEDs
    input usb_rx,           // USB->Serial input
    output usb_tx           // USB->Serial output
  ) {  
    .clk(clk) {
      .btn(~rst_n) {
         toggle_button myToggleButton;
      }
    }
  
    always {          
      led = c{8x{myToggleButton.out}};
    
      usb_tx = usb_rx;        // echo the serial data
    }
  }

Dans ce dernier exemple, on propose de configurer la carte de sorte qu’elle envoie en continu un simple Hello World! toutes les secondes sur la liaison série. L’animation qui suit est le résultat obtenu dans le terminal série intégré à l’EDI Alchitry Labs (menu Tools→ Serial Port Monitor) :

Pour la communication série, l’EDI intègre déjà dans ses composants la plupart des protocoles courants : UART, SPI, I²C et SCCB :

Pour transmettre un message sur la liaison série, on cochera donc le composant UART TX.

Dès lors, la configuration s’avère plus complexe que les exemples précédents, et une description par schéma-blocs devient indispensable :

Module uart_tx : ce module représenté par le bloc en haut à droite est le composant rajouté au projet depuis le sélecteur de l’EDI. Les signaux du message série de la sortie tx sont dirigés vers le port USB selon le protocole série UART. Quand une transmission est en cours, le signal busy est à 1 pour indiquer que la liaison est occupée. Comme leur nom l’indique, l’entrée new_data sera mise à 1 pour signaler l’arrivée d’une nouvelle donnée, l’octet de donnée à transmettre arrivant sur l’entrée data de largeur 8 bits.

Module timer : ce module du bloc en bas à gauche envoie une impulsion toutes les secondes sur son unique sortie, afin de cadencer l’envoi du message Hello World!.

Module controller : ce module est chargé de préparer le message textuel et d’envoyer les codes ASCII des caractères un par un au module suivant uart_tx. Une description plus précise des blocs contenus dans ce module est proposée ci-dessous.

On donne le code du sous-module message.luc :

module message (
    input index[4],
    output letter[8]
  ) {

  const TEXT = $reverse("Hello World!\n\r");
  
  always {
    letter = TEXT[index];
  }
}

Le texte du message sous la forme d’une chaîne de caractères "Hello World!\n\r" est stocké en ROM. En sortie, vous aurez le code ASCII letter à l’indice de position index de la chaîne.

Par exemple si index=0, la sortie sera le code ASCII du premier caractère « H », etc. À noter que la chaîne doit être retournée avant d’être stockée (fonction $reverse) pour sortir le message dans le bon ordre.

En amont, on a donc besoin d’un compteur counter dont la fonction est de faire varier l’indice de position dans la chaîne de caractères entre 0 et 13, 13 étant la position du dernier caractère \r de la chaîne.

L’envoi des codes ASCII par ce controller est géré par une machine à états finis grâce à l’instanciation d’un nouveau type fsm. Le type fsm est semblable au type dff pour les bascules D avec son entrée d et sa sortie q, à l’exception que ces dernières sont des états.

On donne l’extrait du code correspondant au fonctionnement de cette machine à états :

.clk(clk) {
    .rst(rst) { 
      fsm state = {IDLE, TX};
      // ...
    }
  }
// …

  always {
    myMessage.index = counter.q;
    ctl_tx_data = myMessage.letter;
    ctl_tx_new = 0; // default to 0
    
     case (state.q) {
      state.IDLE:
        counter.d = 0;
        if (ctl_start) {
          state.d = state.TX;
        }
 
      state.TX:
        if (!ctl_tx_busy) {
          counter.d = counter.q + 1;
          ctl_tx_new = 1;
          if (counter.q == NUM_LETTERS - 1)
            state.d = state.IDLE;
        }
    }            
  }
}

L’instance state peut prendre deux états : un état repos IDLE, et un état TX pour indiquer une transmission d’un code ASCII en cours. Les actions et les transitions sont gérées dans le bloc case comme en C/C++. À l’état repos, l’indice de position est remis à 0 et on attend le signal start pour démarrer la transmission. À l’état actif TX, on envoie les codes ASCII un par un en incrémentant l’indice de position jusqu’au dernier caractère de la chaîne, et on retourne à l’état repos IDLE.

Ci-après le code complet des différents modules, n’oubliez pas de rajouter le composant de bibliothèque UART TX avec le sélecteur :

module au_top (
    input clk,              // 100MHz clock
    input rst_n,            // reset button (active low)
    output led [8],         // 8 user controllable LEDs
    input usb_rx,           // USB->Serial input
    output usb_tx           // USB->Serial output
  ) {
  
  sig rst;                  // reset signal
  sig rx;
    
  .clk(clk) {
    // The reset conditioner is used to synchronize the reset signal to the FPGA
    // clock. This ensures the entire FPGA comes out of reset at the same time.
    reset_conditioner reset_cond;
    
     .rst(rst) {
        uart_tx tx (#BAUD(1000000), #CLK_FREQ(100000000)); 
        controller myController;
        timer myTimer(#PERIOD(100000000));    
     }
  }
    
  always {
    reset_cond.in = ~rst_n; // input raw inverted reset signal
    rst = reset_cond.out;   // conditioned reset
    
    usb_tx = tx.tx;         // connect tx output
    rx = usb_rx;            // rx not used
    
    tx.new_data = myController.ctl_tx_new;
    tx.data = myController.ctl_tx_data;
    myController.ctl_tx_busy = tx.busy;
    
    myController.ctl_start = myTimer.out;
             
    tx.block = 0;           // no flow control, do not block
    
    led = 8h00;             // turn LEDs off

  }
}

module controller (
    input clk,  // clock
    input rst,  // reset
    input ctl_tx_busy,  // busy tx
    input ctl_start,
    output ctl_tx_new,
    output ctl_tx_data[8]
    
  ) {
  const NUM_LETTERS = 14;
  
  .clk(clk) {
    .rst(rst) { 
      fsm state = {IDLE, TX};
      dff counter[$clog2(NUM_LETTERS)];
    }
  }
  
  message myMessage;
  
  always {
    myMessage.index = counter.q;
    ctl_tx_data = myMessage.letter;
    ctl_tx_new = 0; // default to 0
    
     case (state.q) {
      state.IDLE:
        counter.d = 0;
        if (ctl_start)
          state.d = state.TX;
 
      state.TX:
        if (!ctl_tx_busy) {
          counter.d = counter.q + 1;
          ctl_tx_new = 1;
          if (counter.q == NUM_LETTERS - 1)
            state.d = state.IDLE;
        }
    }            
  }
}

module message (
    input index[4],
    output letter[8]
  ) {

  const TEXT = $reverse("Hello World!\n\r");
  
  always {
    letter = TEXT[index];
  }
}

module timer #(PERIOD = 100000000 : PERIOD > 0) (
    input clk,  // clock
    input rst,  // reset
    output out
  ) {

  dff count[$clog2(PERIOD)] (.clk(clk), .rst(rst) );
  
  always {
    count.d = count.q + 1;
    out = 0;
    if (count.q == PERIOD - 1) {
      out = 1;
      count.d = 0;
    }
  }
}