hat jemand ein gutes Beispiel für ein log file? Ich will Busereignisse protokollieren. Wie Lese- und Schreibzugriffe. Davon ist die Adresse und und Bitbreite und noch der Wert usw. interessant. Diese Werte willte ich mir als Text-Tabelle vom Simulator ausgeben ausgeben lassen. Die Suche im Taktdiagramm dauert einfach zu lange. Wenn ich die Tabelle hätte, wüsste ich die Position an den ich im Taktdiagramm expliziter schauen muss. Der Weg geht über lib textio das ist mir klar. Falls jemand ein Beispiel für so eine File-Ausgabe hat, würde es mir weiterhelfen. Ich dachte an folgende Ausgabeform. time addr R/W Data_in Data_out bit_width Chipselect
Gast
#2785551
>Der Weg geht über lib textio das ist mir klar.
Und wo genau ist jetzt dein Problem?
Was hast du denn schon ausprobiert? Zeig doch mal.
Gast
#2785602
Hallo René, wie wäre es mit folgendem Ansatz: (VHDL-2008, getestet in Modelsim PE 10.1c)
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
Ausgabe: 333 ns 7 77 VG, SuperWilly
Gast
#2785616
Möchtest Du Zeilenumbrüche sehen, dann vielleicht so:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
VG, SuperWilly
Gast
#2785652
René D. schrieb: > Ich will Busereignisse protokollieren. > Wie Lese- und Schreibzugriffe. Davon ist die Adresse und und Bitbreite > und noch der Wert usw. interessant. Suchst Du vielleicht sowas?: http://repo.or.cz/w/zpu.git/blob/HEAD:/zpu/hdl/zpu4/src/trace.vhd Duke
> Und wo genau ist jetzt dein Problem? ich müsste mich auf die Lauer legen bis ein Ereignis, was ich loggen will, eintritt und das noch rekursiv für das nächst Ereignis. Dazu kann ich einen Prozess oder eine loop nehmen. Weil ich einen Tabellenkopf generieren will scheidet der Prozess aus. Die ganzen Ausgaben sind noch zu konvertieren und zu formatieren und Stringumwandlungen. Das ist nicht synthetisierbarer Code und damit habe ich lange nicht mehr gearbeit. Das ist so das grundübel. Ich habe nich auch gerade umgeschaut. Der Begriff "Testvector" ist hier das Wort in der Praxis. Dazu brache ich ein paar Anregungen, wie man effektiver Code testet. zurück du den oben genannten Stellen. Die Printf funktion fehlt leider in VHDL. die Funktion print aus der ZPU sieht sehr nach der Lösung für mein Problem aus. Hinter Print ist Funktion hinterlegt, die ich noch nicht kenne. Da muss ich nochmal graben. > print(l_file, "0x" & hstr(t2) & " 0x" & hstr(opcode) & " > 0x" & hstr(t) & " 0x" & hstr(memA) & " 0x" & hstr(memB) & " 0x" & > hstr(intSp) & " 0x" & hstr(std_logic_vector(counter)));
Gast
#2785843
René D. schrieb: > Weil ich einen Tabellenkopf generieren will scheidet der Prozess aus.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
René D. schrieb: > Hinter Print ist Funktion hinterlegt, die ich noch nicht > kenne. Da muss ich nochmal graben. siehe hier: http://repo.or.cz/w/zpu.git/blob/HEAD:/zpu/hdl/zpu4/src/txt_util.vhd Die txt_util ist sicher auch für andere Projekte ganz hilfreich. Duke
Gast
#2785915
>Der Begriff "Testvector" ist hier das Wort in der Praxis.
Ja? Du möchtest doch Daten loggen. Der Begriff Testvektor ist doch eher
im Stimulus-Zusammenhang zu sehen.
Gast
#2785923
>Weil ich einen Tabellenkopf generieren will scheidet der Prozess aus.
Wieso?
Ich kann doch in einem Prozess einmalig einen Tabellenkopf ausgeben und
mich gleichzeitig in einer while-Schleife befinden.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
> Ja? Du möchtest doch Daten loggen. Der Begriff Testvektor ist doch eher > im Stimulus-Zusammenhang zu sehen. Das habe ich auch schon bemerkt, dass der Testvector im Regelfall zum Stimulieren gelesen wird. Ich will so was eben zu kritischen Zeitpunkten ausgeben und brauche auch kein kontinuierliches Loggen. Zum stimulieren habe ich schon eine Testbench. Die Simulation muss ich auswerten und bin hier noch nicht optimal mit meinen Tools aufgestellt. Deshalb auch die Frage in den Raum.
ich habe noch einen schönen Beitrag zu dem Thema gefunden. www.actel.com/documents/TestVector_AN.pdf
Gast
#2788555
Naja, etwas altbacken, anno 2003. So generiert man doch keine Stimuli mehr ... "Bus Functional Model" lautet hier das Stichwort.
> "Bus Functional Model" lautet hier das Stichwort.
So richtig bin ich noch nicht im Bilde.
Bis jetzt habe ich als Vorstellung das Bus funtion Model ist ein
spezielle Testbench. Damit kann man einen Busteilnehmer einzeln
verifizieren.
Mehr konnte ich aus der Meldung ableiten.
Gast
#2791823
Was für Daten muss du denn stimulieren?
Stachele schrieb: > Was für Daten muss du denn stimulieren? Ursprung: ich habe einen eigenen Softcore mit dem ahb-lite bus. Die Fehler befinden sich in entweder in der compilierten Software, im Softcore oder in der Peripherie. CPU Fehler hatte ich jetzt lange nicht mehr. Sofern ist das ganz harte überwunden. Eine Baustelle ist meine AHB-lite Peripherie auch unabhängig vom Softcore zu testen. Hier könnte ich mir so etwas mit Bus function model vorstellen. Eine andere Baustelle sind Tests für den Softcore, der sich aber ab und zu ändert. Hier nehme ich als Stimulation ein Hexfile.
Gast
#2792245
>Eine Baustelle ist meine AHB-lite Peripherie auch unabhängig vom >Softcore zu testen. Lohnt sich denn der Aufwand die Peripherie separat zu simulieren? Ich meine, wird sie denn jemals ohne Softcore zum Einsatz kommen oder ist die Simulation der Softcores zu langsam?
> Lohnt sich denn der Aufwand die Peripherie separat zu simulieren? Ich > meine, wird sie denn jemals ohne Softcore zum Einsatz kommen oder ist > die Simulation der Softcores zu langsam? Mit GHDL geht das schon vernünftig. anderer Aspekt: Wenn jemand weitere Peripherie schreibt. Dann hat er nicht die Ahnung mit den internen Signalen des Softcore. Deshalb würde ich noch eine einfachere Simulation für die Peripherie als Schiedrichter haben wollen. Wo ich mich nicht an den internen Signalen entlanghangeln muss, sondern schneller die Fehler im Bus sehe. Nur als Beispiel: Ich hatte gerade den Fall. Ich bin immer von geraden Speicheradressen beim Buszugriff auf meine Peripherie ausgegagen, deshalb habe ich den Fall nicht in VHDL abgebildet. Jetzt greift der Compiler mit Bytezugriffen drauf und kommt dadurch an ungerade Adressen und der Softcore wartet auf das Signal, dass die Daten im Bus gültig sind.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.