schon klar, dass das meiste davon schon existiert.. die einzelnen funktionen müssen nur nachbearbeitet werden, um mit den neuen variablentypen zu funktionieren. die tracefunktionen können wir leider nicht mehr nutzen... das mit dem perlscript wird jetzt ein bischen kompliziert glaub ich. ich denke nicht, dass wir die das alte testsystem direkt konvertieren können, da wir zum testen lediglich zugriff auf den bus haben und nicht auf interne variablen. hast du eigentlich die bilder für die übersicht des rtl modeles? damit wirds ein bischen einfacher, dass system zu verstehen.
Lg Christoph Am 16.02.2009 um 21:54 schrieb Johannes F Dorfner:
Äh,fast alles davon existiert doch schon. Ich habe doch schon ein komplettes Testsystem geschrieben, das in trunk seinen Dienst tut. Das mit der Toolchain (also Kompilieren von menschenlesbaren Assemblerprogrammen zu Speicherbildern) funktioniert zwar leider nicht, da die erzeugten Instruktionen aus irgendeinem Grund ein anderes Format aufweisen (andere Verteilung der Bits). Aber auch manuell kann ich mittlerweile einigermaßen gut die Testprogramme schreiben. 4 davon liegen, zusammen mit einem Perl-Skript zur automatischen Ausführung (runtests.pl) im Unterordner tests/ von trunk. (Anbei nochmal mein letzter Stand vom trunk-Ordner wie in der E-Mail vom 10.02.. Die Dateien für das Laden und Schreiben von Speicherinhalten von/nach Datei liegt in pack_fileio.vhdl mit Kommentar.) Ich wollte bereits letztes Wochenende das System zu trunk2 konvertieren, habe aber noch nicht geschafft, die Abhängigkeiten und die Funktion dieses Ordners ganz zu verstehen. Es wäre leichter für mich, wenn alle für die neue Architektur benötigten Komponenten nach trunk2 kopiert werden würden.Viele Grüße, Johannes -------- Original Message -------- Subject: [vhdl_group2] Re: Testsystem f. trunk2 From: Christoph Eisner <chr.eisner@xxxxxx> To: vhdl_group2@xxxxxxxxxxxxx Date: 16.02.2009 21:22HalloAlso ich schlage mal folgendes vor: ich könnte am Donnerstag oder Freitag eine Testbench schreiben, die ein file in ein memory array (als speicherersatz in der Testbench) einliest, welches mit der hoffentlich funktionierenden Toolchain erzeugt worden ist. Das memory array müsste vom type array of bit_vector (31 downto 0) sein. funktionen fürs konvertieren von bit_vector nach integer gibts ja schon...Das einzige was wir dann noch brauchen, ist1. code am besten mit einem "Soll"-speicherabbild nach einem erfolgreichen durchlauf zum vergleich. Wir sollten uns hier noch was für die abbruchbedingung überlegen. Sonst läuft die CPU immer weiter. Am besten ich implementieren in den Instruction decoder noch den stopbefehl. 2. ein funktion, oder ein routine, die das soll speicherabbild mit dem tatsächlichen speicherabbild vergleicht und abweichungen in ein file schreibt. (am einfachsten ich erzeuge in der testbench einen "soll"- speicher und einen "ist"-speicher in form einer variablen vom obigen typ und die funktion vergleicht nur die beiden variablen)3. gibts eine testbench für den speicher?4. wir könnten auch für einen funktionstest des speichers mit der CPU zusammen den RAM mit einem kleinen default programm initialisieren (auch den Programmcounter und die register müssten dementsprechend initialisiert werden.) ist aber glaub ich sehr aufwendig.Was haltet ihr davon? Lg Christoph Am 16.02.2009 um 10:10 schrieb Johannes Boch:Hallo,zu 1) Trunk1 und trunk2 sind nicht unabhängig. Insbesondere Konstantendeklarationen und Funktionen aus den trunk-Packages werden im trunk2 benötigt. Auch der RAM-Baustein befindet sich im trunk (kann von mir aus auch in trunk2 verschoben werden).zu 2) Das mit den zwei Treibern am Bus ist natürlich nicht so gut. Ich denke, die Lösung mit dem modifiziertem RAM ist am besten. Das reset-signal wird dort sowieso nicht benutzt, d.h. hier würde sich eine Initialisierung bei steigender reset-Flanke anbieten. Synthetisierbar muss das Ganze eh' nicht sein.zu 3) Auch richtig: Am besten die Bussignale aus der System.vhdl herausführen und in der Testbench verifizieren.Gruß, Johannes Original Message: <br />Am 15.02.2009 um 19:07 schrieb Johannes F Dorfner: <br /><br />> Ich habe jetzt einige Zeit damit verbracht, den jetzigen Stand sowie <br />> Aufbau des trunk2-Ordners nachzuvollziehen, um das Testsystem<br />> korrekt einzubauen. Dazu einige Fragen: <br />> <br />> 1. Die beiden Ordner trunk und trunk2 sind schon komplett <br />> unabhängig? Das heißt: insbesondere trunk2 greift auf nichts<br />> innehalb von trunk zu, oder? (Ansonsten erledigen sich vielleicht<br />> einige der folgenden Fragen.<br />Die beiden Ordner sind eigentlich komplett unabhängig. Nur als RAM <br />werden wir den RAM Baustein vom Anfang benutzen (Also den vom trunk-<br />Ordner) <br /><br />> 1. Existiert für die Komponente RAM schon irgendwo eine Architektur? <br />> Ich habe in der letzten Version von trunk2 [1] keine gefunden. Ohne<br />> die kann ich natürlich nicht viel machen. <br />siehe oben <br /><br />> 2. Kann ich die Funktion access_bus aus pack_spinni dann auch in <br />> trunk2 verwenden? Momentan sehe ich zwar den Bus, aber noch nicht <br />ich denke nicht, dass wir die Funktion access_bus benutzen können. Wo <br />sollte die aufgerufen werden? Wenn wir ein Modul in der testbench <br />schreiben, dass wir an den Bus anschliessen und dort die Funktion<br />aufrufen hätten wir zwei Treiber am Bus. => nicht gut <br />So wie ich das sehe haben wir nur zwei Möglichkeiten:<br />1. Entweder wir manipulieren den RAM so, dass der sich von selbst mit <br />den Programmdaten initialisiert => evtl. ist dann der RAM nicht<br />synthetisierbar...<br /> dann wärs aber auch einfacher zum testen der CPU funktionen einfach <br />einen neuen test-RAM zu schreiben, der speziell dafür gebaut ist, also <br />die Programmdaten direkt aus einem file einliest und in ein file <br />zurückschreibt. mit einer configuration für die testbench könnte <br />automatisch der test-RAM anstelle des "echten" RAM eingebunden werden. <br />2. die CPU muss den Speicher mit load befehlen selbst laden... aber<br />woher die daten nehmen? <br /> <br /><br />> 3. Das Testsystem wird meines erachtens nach ein einmalig laufender <br />> Prozess innerhalb der Architektur von system.vhdl werden, wo im <br />> wesentlichen alle Testschritte genauso stehen wie jetzt in der<br />> Architektur arch_mlite.<br />ich würde das Testsystem eigentlich nicht in die architektur fest <br />implementieren, sondern eher die CPU in eine Testbench "reinbauen" und<br />so testen <br /> <br />> <br />><br />> 4. Der Instruction Decoder ist in meiner Version von trunk2 noch <br />> nicht implementiert (nur Entity die ist vorhanden). Gibt es den<br />> schon in fertig?<br />Der instruction decoder ist zum Teil fertig. Also ich schreibe den... <br />Das Problem ist zu entscheiden, welche Befehle wir haben wollen... <br />Will ja nicht alle implementieren. und je nach Testprogramm, würde ich<br />den Instruction decoder dann anpassen, wie es benötigt wird. <br />> <br />> <br />> <br />> Viele Grüße, <br />> Johannes <br />> <br />> --- <br />> <br />> [1] Gefunden im Anhang der Nachricht: <br />> Message-ID: <br />> Subject: [vhdl_group2] Re: rtl <br />> From: Christoph Eisner <br />> To: vhdl_group2@xxxxxxxxxxxxx <br />> Date: 09.02.2009 21:49 <br />> <br />> <br />Lg <br /> <br />Christoph Eisner <br /> <br />Am Müllnerberg 17 <br />83129 Höslwang <br /> <br />Tel.: 08055/969004 <br />Mobil: 0176/63398849 <br /> <br /> <br /> --Christoph Eisner Am Müllnerberg 17 83129 Höslwang Tel.: 08055/969004 Mobil: 0176/63398849<trunk.zip>
Christoph Eisner Am Müllnerberg 17 83129 Höslwang Tel.: 08055/969004 Mobil: 0176/63398849
