Vérification du processeur logiciel


18

Je suis actuellement en train de concevoir un CPU simple en VHDL en utilisant Xilinx ISE et ISIM. La partie conception se déroule remarquablement bien, mais je n'arrive pas à trouver un moyen de faire une vérification de manière cohérente.

En ce moment, j'ai un banc de test VHDL que je mets à jour pour tester la fonction sur laquelle je travaille à un moment particulier. Ceci est très ponctuel, et cela ne m'aide pas à détecter les régressions et ne peut pas être utilisé pour vérifier la conformité avec l'ensemble de spécifications / instructions.

J'ai pensé à développer une suite de tests complète, mais le problème est que l'état potentiel d'une partie à usage général en tant que CPU est énorme par rapport aux composants moins génériques.

Je recherche une méthode qui me permette de réaliser la conception et les tests de manière plus contrôlée. Une sorte de "matériel TDD" si vous voulez. Une telle chose existe-t-elle? Peut-il s'appliquer relativement facilement à des pièces à usage général telles qu'un processeur?

Réponses:


16

Toute la question de la vérification du CPU est super grande et difficile. Il y a des gens qui font carrière à partir de ça. Je vais juste vous donner un aperçu ...

  1. Écrivez un programme en langage assembleur qui teste chaque instruction et chaque petit détail de chaque instruction. Par exemple, lorsque vous testez l'instruction ADD, vous pouvez la tester avec des nombres à la fois positifs, négatifs et un de chaque (deux fois). Vous testeriez alors le drapeau de retenue, le drapeau zéro, etc. D'autres caractéristiques spéciales du CPU (comme la prédiction de branche, etc.) auraient leur propre partie spéciale de ce test.

  2. Écrivez, en utilisant C / C ++ ou quelque chose, un modèle de votre CPU. Ceci est votre CPU virtuel. C'est aussi votre "CPU doré", ce qui signifie que c'est le CPU auquel tout le reste est comparé. Idéalement, la personne qui a écrit le VHDL n'est PAS la même personne qui écrit le modèle C / C ++.

  3. Écrivez / créez un système où vous pouvez exécuter côte à côte le modèle C / C ++ et le modèle VHDL et comparer les résultats cycle par cycle. Exécutez votre programme d'assemblage à partir de l'étape 1 et assurez-vous que les deux modèles correspondent.

  4. Exécutez vos deux modèles selon des "instructions" aléatoires. Fondamentalement, remplissez "ram" avec des données aléatoires et exécutez ces données aléatoires comme s'il s'agissait de vraies instructions. Exécutez les mêmes données aléatoires sur les modèles VHDL et C / C ++ et comparez les résultats. Ce modèle C / C ++ s'exécuterait sur certains postes de travail et / ou serveurs (pas sur le nouveau CPU lui-même).

  5. Configurez une machine ou plusieurs machines pour répéter l'étape 4 pour toujours. Même si votre CPU est "terminé" et est en production depuis un an ou plus, vous exécuterez toujours ce test.

  6. Répétez ces étapes chaque fois qu'il y a plus de choses à simuler. Par exemple, vous l'exécuterez sur le VHDL post-route avec un timing lorsqu'il sera disponible.

Il n'y a aucune garantie que la comparaison des versions VHDL et C / C ++ interceptera chaque bug - mais il n'y a vraiment pas de meilleure façon. Et tester le CPU sur des instructions aléatoires prend du temps, mais c'est aussi très utile. La seule vraie alternative à cela est d'embaucher beaucoup de gens pour simplement écrire du code toute la journée pour tester différentes parties du CPU - et les plus grandes entreprises le font, mais elles font aussi les données aléatoires.

Pour une seule personne écrivant du code VHDL, il suffit généralement de l'étape # 1. Mais si vous allez vendre le CPU, au moins certaines des autres étapes devraient être effectuées (et vraiment, vous devriez toutes les faire).


Excellente réponse, merci! Cela a beaucoup de sens. Le "Golden CPU" est en effet la pièce manquante du puzzle qui vous permet de faire une vérification cycle par cycle lors des tests. Comme il s'agit principalement d'un projet de jouet, je pense que je vais me conformer à la première phrase du dernier paragraphe et ne faire que l'étape # 1. Mais savoir ce que je dois faire est inestimable.
drxzcl

Vous pouvez également avoir un modèle C ++ doré, mais non précis sur le cycle, ce qui lui permet d'être beaucoup plus simple et donc plus susceptible d'être correct - utile pour tester la fonctionnalité ALU par exemple ("2 + 2 = 4 et certains indicateurs, je peu importe quand "plutôt que" 2 + 2 = 4 après un tick et les drapeaux après 2 ticks ")
Martin Thompson

En outre, exécutez la couverture de code (pour vérifier que vous vous êtes exercé) et la couverture de test (pour vérifier que tous les tests ont été testés pour les échecs et les échecs)
Martin Thompson

Suivi: En utilisant la procédure de la "première étape", j'ai réussi à trouver beaucoup de défauts ... dans mon assembleur: P Le noyau lui-même semble être relativement correct.
drxzcl
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.