A LIRE EN CAS DE PROBLEMES
Avant tout, vous devez savoir qu'il n'y a pas d'exécutables binaire dans ce module. Tout est au format texte donc lisible. Nous vous enjoignons grandement à lire le Makefile et à le relier au schéma de conception présenté dans le tutoriel addaccu. Lisez les pages man de tout ce que vous pourrez trouvez. Si cela vous tente, lisez les scripts Perl et tentez de comprendre comment ils ont été faits. Tout à été codé avec un haut degré de commentaire de façon à ce que ce soit le plus lisible possible.Explications additionnelles sur le Makefile:
Un Makefile peut être extraordinairement complexe. Il fonctionne selon un ensemble de règles et dépendances. Il faut savoir que dans un Makefile, si rien n'est dit en ligne de commande, c'est la première règle qui est exécuté. Dans ce cas, c'est 'all' qui indique qu'il ne fait rien mais a comme dépendance $(CIBLE).cif, il s'agit du fichier cif final. Trouvez la règle $(CIBLE).cif et ses dépendances. Vous trouverez qu'il a besoin de $(CIBLE).drc et $(CIBLE).ap . Remontez ainsi toute la chaîne jusqu'aux fichiers initiaux qui sont normalement les 3 que vous avez fournis. Le format d'une règle est :Explications sur les scripts perl:REGLE : DEPENDANCESsuivi d'une ligne indiquant la manière de créer REGLE avec ses dépendances. Vous remarquerez que 'all' n'a pas cette ligne, ce n'est pas grave, cela indique juste qu'on ne créera jamis un fichier nommé all. L'intérêt du Makefile est qu'il n'exécutera les commandes associés à une règle que si le fichier indiqué par REGLE n'existe pas ou s'il est plus ancien que ses dépendances. Les dépendances de 'all' sont toujours vérifié, ainsi que ses dépendances, c'est-à-dire "$(CIBLE).cif", qui entraîne la vérification des dépendances de "$(CIBLE).ap" et "$(CIBLE).drc", qui entraîne..... etc.Le Makefile du module d'automatisation contient des test après l'exécution de bop, genlib scr et ring, avec des tests particulièrement poussés quand on obtient la netliste physique finale $(CIBLE).ap . Ces tests sont:
Les tests de simulation laissent, en espérant qu'ils soit utiles, les résultats de simulation sous le nom, par exemple, de "testgenlib.pat", visualisable par waview. De même, on peut relancer une simulation en tapant, par exemple : make testgenlib .
- testbop (simulation de la description VHDL optimisée)
- testscr (comparaison des netlistes logiques et physiques du noyau)
- testgenlib (simulation de la netliste logique de l'ASIC, cad du noyau associé à son anneau).
- testring (comparaison des netlistes logiques et physiques de l'ASIC)
- testretour (extraction d'une description VHDL de la netliste physique finale et simulation)
- testproof (utilisation du prouveur formel pour prouver l'identité de la description VHDL initiale et de celle extractée).
Perl veut dire Practical Extraction and Report Language, et ses possibilités ont été mises à rude épreuve pour plusieurs choses:De la documentation sur Perl est disponible à BU Sciences et elle est relativement bien faite à ce sujet.
- creerring: Il s'agit de l'outil de création du fichier c qui va être donné à genlib pour la création de l'anneau de l'ASIC. Il se base sur votre fichier VHDL. Il accepte les entités qui ont dans leurs ports des entrées-sorties du type bit ou bit_vector, ces derniers pouvant avoir n'importe quelles dimensions, dans le sens "TO" ou "DOWNTO"). Il prend en compte des fichiers VHDL sans ou avec ligne d'horloge(ligne clk). et crée dans le répertoire courant un fichier vide "noclk" si ce circuit n'a pas d'horloge.
- ajout_alim: Cet outil prend en entrée le résultat de la simulation sur le fichier VHDL initial et lui rajoute les alims et une ligne clk constamment à 1 si le fichier "noclk" existe. Asimut en aura besoin au moment de la simulation de la netliste logique de l'ASIC(noyau+anneau) puisque ces lignes sont apparues.
- prepareproof: comparaison formelle de la description VHDL extractée et de la description initiale. La description extractée contient les lignes d'alim. : il faut les rajouter dans la description initiale. De plus, proof demande que les noms de registre dans les deux descriptions soient parfaitement identiques. "prepareproof" permet de faire toutes ces manipulation (NB: sans toucher aux fichiers initiaux, il en crée des nouveaux qu'utiliseront yagle et proof).