[vhdl_group2] Re: [vhdl_group2] Re: Testsystem f. trunk2
- From: Johannes Boch <johannes.boch@xxxxxxxx>
- To: <vhdl_group2@xxxxxxxxxxxxx>
- Date: Mon, 16 Feb 2009 10:10:33 +0100
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 />
--
Other related posts:
