Débogage sur puce du processeur

Cette section va présenter le principe de fonctionnement du debug dans la plateforme de réveil, la manière de stopper le cœur, de le relancer et de faire du pas à pas sur l’exécution du code.

Toute la stratégie de debug du cœur se passe dans le signal Continue (figure 5.8) venant de la machine d’état du DECODER. Ce signal est juste un signal Single Rail (SREVENT : 1 fil de signal + 1 fil d’acquittement) (voir section 6.1) qui permet de signaler à l’unité de calcul du Program Counter (PC UNIT) qu’il peut prendre en compte le nouveau type d’instruction qui s’exécute ou qui a été exécuté (I_type_ctrl dans Figure 5.8) pour pouvoir calculer le nouveau PC et charger la nouvelle instruction. En effet la PC UNIT est en attente de ce signal Continue avant de charger chaque instruction. Il y a donc un rendez-vous entre le SREVENT Continue et le canal dual rail I_type_ctrl. Ce rendez-vous est implémenté avec des portes de Muller (section 6.1.2.1). Ainsi il ne peut y avoir de chargement d’une nouvelle instruction tant que le signal Continue n’est pas envoyé. Ce signal Continue peut être généré soit par les évènements new_inst_ev, step_ev, run_ev ou new_irq_num_ev (figure 5.8). Le cœur est donc naturellement stoppé. Suivant les évènements qui arrivent de l’extérieur ou de l’intérieur, celui-ci va se mettre dans un certain mode et sera sensible à des évènements différents (voir machine d’états contenue dans le décodeur figure 5.9).

La machine d’état du décodeur (figure 5.9) est constituée de deux états : un état dans lequel il est en attente d’une interruption (WAIT_IT) pour pouvoir rentrer dans le second

Architecture de la plateforme de réveil 83

Figure5.8 – Principe de fonctionnement du debug dans le WUC

état d’exécution (WAIT_INST). Dans l’état WAIT_IT la machine d’état configure le bit WAITdu registre d’état du WUC WUCSR (figure 5.10) dans l’état WAIT. Cet état est alors sensible aux évènements new_irq_num_ev, step_ev, run_ev, break_ev ou stop_ev. Lorsque l’évènement new_irq_num_ev se lève, le bit WAIT du registre WUCSR est mis à l’état NOT_WAITING, envoie un signal Continue à la PC UNIT et change l’état de la machine d’état à WAIT_INST. L’adresse contenue dans le vecteur d’interruption est chargée par la PC_UNIT et la première instruction est chargée. Un évènement new_inst_ev est alors généré par le pré-décodeur du DECODER à la réception de l’instruction. Dans l’état WAIT_INSTde la machine d’états, cela va vérifier si le cœur est en mode STOP ou RUN grâce à une variable interne et envoie le signal Continue si le processeur est dans un mode RUNou se met en attente des signaux step_ev ou run_ev si le cœur est dans le mode STOP. A tout moment les signaux step_ev, run_ev et stop_ev peuvent être envoyés grâce à une écriture dans le registre CMDR (figure 5.10). La variable interne de la machine d’états est alors mise à jour avec les signaux run_ev, break_ev et stop_ev.

Lorsque le cœur est en mode STOP, qu’une nouvelle instruction est arrivée et qu’un évènement run_ev ou step_ev est généré, alors le signal Continue est envoyé à la PC UNIT. Lorsque le pré-décodeur détecte l’instruction ENDIT, il génère aussi l’évènement EndIT_ev pour que la machine d’état retourne à l’état WAIT_IT.

Dans le cas d’un Software Breakpoint posé dans le code, le pré-décodeur détecte l’ins- truction BREAK et envoie un signal break_ev à la machine d’états qui change alors le mode du processeur au mode STOP. Le pré-décodeur envoie alors l’évènement new_inst_ev et le type d’instruction à la PC UNIT spécifiant de recharger la même instruction. La machine d’états est alors à ce moment en attente des évènements run_ev et step_ev venant de l’uti- lisateur. Celui-ci doit d’abord remplacer dans la mémoire de programme à l’adresse où est écrit le BREAK l’instruction originelle puis doit écrire dans le registre de contrôle CMDR RUN ou STOP pour exécuter la vraie instruction. Ainsi grâce à cette machine d’états, on

Figure5.9 – Machine d’état du décodeur

peut être capable de mettre le processeur soit en mode STOP ou RUN, regarder le numéro de l’IT qui est exécutée, voir si le processeur est en attente ou non d’interruptions, et faire du pas à pas sur l’exécution du code. Il est possible de voir aussi le statut des bits N (Ne-

gatif ), Z (Zero), C (Carry), V (Overflow), et de changer l’offset du vecteur d’interruption

pour exécuter un autre code en mémoire correspondant à une même interruption.

Figure5.10 – Registre du WUC pour le support de debug, son état et sa configuration

Maintenant que les spécifications du système ont été déterminées, la microarchitecture des différents modules va pouvoir être présentée.

Chapitre 6

Microarchitecture de la plateforme

de réveil

En se basant sur les spécifications du chapitre 5 et sur la méthode de conception asynchrone exposée dans ce chapitre, section 6.1, la microarchitecture de la plateforme de réveil va être présentée dans le détail. Ce chapitre va présenter la microarchitecture de chacun des blocs de l’architecture de la plateforme de réveil de la figure 5.4 et les différents processus qui les composent pour respecter le jeu d’instructions. En effet il a fallu décomposer chaque bloc en des processus élémentaires faisant apparaitre les dépendances entre les différentes ressources et l’échange de données entre les blocs fonctionnels.

Dans un premier temps la méthode de conception asynchrone va être présentée, puis l’architecture de la mémoire ainsi que son interface asynchrone-synchrone seront expo- sées. Nous détaillerons ensuite dans la section 6.3 les différentes unités d’exécution : le contrôleur d’interruption, le décodeur, l’unité PC, le banc de registres, le bus de commu- nication, l’unité load-store, l’unité arithmétique et logique, l’unité de branchement et de déplacement et enfin l’unité de support aux fonctions. Nous finirons par une description de l’environnement logiciel ainsi que l’environnement de conception et de simulation.