On va réaliser très simplement une simulation avec Modelsim. En réalité, puisque le but de cette simulation est de détecter (afin éventuellement le corriger) un défaut dans le modèle de PIC, il faut essayer de se mettre dans la situation de celui qui doit trouver ce défaut. Il va alors naviguer entre les différents fichiers VHDL, essayer de comprendre leur structure, constater qu’il y a bien peu de commentaires dans les sources, bref être obligé de perdre du temps alors qu’il souhaitait en gagner en utilisant un composant prêt à l’emploi.

Bien entendu, ici , on va aller beaucoup plus vite puisque la solution est connue.

Rappel: Pour la simulation, la pluspart des temporisations on été réduites au maximum

Le fichier qui va se trouver au sommet,  test_pic.vhd  ne comporte que l’instanciation du projet pic, une commande de « reset » et une horloge.

•  On crée un nouveau projet modelsim « pic » avec comme répertoire ./sim
• On éxecute la macro ./bench/compile.do pour compiler l’ensemble des fichiers
• On éxecute la macro ./bench/simu.do pour afficher les signaux utiles
• On fait: Run 20 us

Analyse

Le programme de chenillard PIC se déroule depuis le reset.  La premiere chose qu’on peut facilement observer est le pourquoi du saut de deux en deux d’affichage des diodes. En 2220 ns par exemple, on constate que le signal port_b passe de FE à FC puis immédaitement à FD. Le décalage « vrai » ne dure qu’une période d’horloge ce qui explique qu’on ne le voyait pas en réalité. En fait le premier décalage est suivi immédiatement d’un deuxiéme, ce qui n’est pas normal.

On va maintenant inspecter le processeur. Pour cela , il faut être capable de faire la relation entre les données binaires que l’on voit et le programme d’application. D’où le grand intérêt d’avoir pût construire un déssassembleur rudimentaire sous la forme de signaux virtuels dans modelsim. Le signal « instruction_opcode » offre ainsi la possibilité de se repérer dans l’exécution du programme en ayant sous les yeux le fichier listing  .\prog\chen_sim.lst qui nous donne les adresses  ainsi que le mnémonique de chaque instruction. En particulier, le programme d’interruption commence en 004 et se termine en 0012.  Les signaux rom_addr et rom_data correspondent à ces mêmes informations.

La figure ci-dessous illustre ces résultats.

On constate qu’après une demande d’interruption (signal int) , le pointeur de pile stackptr s’incrémente deux fois tandis que l’adresse de retour (0061) est normalement empilées mais aussi 0004 ( ERREUR !) qui est l’adreesse de début du programme d’interruption. De telle sorte qu’arrivé en fin d’interruption, est dépilée 0004 et le programme repart pour une deuxième exécution. CQFD.

 Conclusion

Le signal int traine deux périodes d’horloge au lieu d’une. On se contentera de rajouter une « rustine » pour remédier à cela, une variable détectant la première période.  Le fichier .\rtl\new_ppx_pcs.vhd en remplacement du fichier ppx_pcs.vhd conduit à un fonctionnement correct.

Le code modifié:

PROCESS (Reset_n, Clk)
VARIABLE toggle : boolean;    — modif P.N
BEGIN
IF Reset_n = ’0′ THEN
PC_i <= (OTHERS => ’1′);
IF TopBoot THEN
PC_i(0) <= ’0′;
END IF;
StackPtr <= (OTHERS => ’0′);
toggle := true;  — modif P.N
ELSIF Clk’event AND Clk = ’1′ THEN
PC_i <= NPC_i;
IF Push = ’1′ THEN
StackPtr <= StackPtr + 1;
END IF;
IF Pop = ’1′ THEN
StackPtr <= StackPtr – 1;
END IF;
IF Int = ’1′ AND toggle THEN — modif P.N
StackPtr <= StackPtr + 1;
toggle := false;  — modif P.N
ELSIF int = ’0′ THEN
toggle := true;  — modif P.N
END IF;
END IF;
END PROCESS;