logfile aus VHDL Simulation

[René D. (Firma: www.dossmatik.de) (dose)]

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

[Kratzele (Gast)]

>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.

[SuperWilly (Gast)]

Hallo René,

wie wäre es mit folgendem Ansatz: (VHDL-2008, getestet in Modelsim PE 
10.1c)

library ieee;
use ieee.std_logic_1164.all;

library std;
use std.textio.all;


entity output_format is
end entity;

architecture test of output_format is
signal out_vec : std_logic_vector(3 downto 0) := x"7";
signal count : integer := 77;

begin

process
   variable s : string(1 to 5) := "     ";
begin
  wait for 333 ns;

  write( output, to_string(now, ns) &s&
                 to_hstring(out_vec) &s&
                 to_string(count)   );
wait;
end process;

end test;

Ausgabe:
333 ns       7       77



VG, SuperWilly

[SuperWilly (Gast)]

Möchtest Du Zeilenumbrüche sehen, dann vielleicht so:

p2: process  
begin
  wait for 444 ns;

  write( output, to_string(now, ns)     &LF&
                 to_hstring(out_vec)    &LF&
                 to_string(count)  );
wait;
end process;

VG, SuperWilly

[Duke Scarring (Gast)]

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

[René D. (Firma: www.dossmatik.de) (dose)]

> 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)));

[Duke Scarring (Gast)]

René D. schrieb:
> Weil ich einen Tabellenkopf generieren will scheidet der Prozess aus.

-- Pseudocode
  ...
  variable tabellenkopf : boolean := true;
  ...
  if tabellenkopf then
     print "Tabellenkopf";
     tabellenkopf := true;
  end if;
  
  print "restliche, permanente Ausgaben";
  ...

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

[Stachele (Gast)]

>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.

[SuperWilly (Gast)]

>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.

process
variable once : boolean := true;
begin
   while (not simulation_end) loop
     
        for k in 0 to 7 loop                    -- z.B. 8 Log-Ereignisse 
              
            wait until (log_event = '1');

            if once then
               write(output, "Deine Kopf-Meldung");
               once := false;
            else
               write(output, "Deine sonstigen Meldungen");
            end if; 

        end loop;

   end loop;

   report "Logging beendet" severity note;
wait;
end process;

[René D. (Firma: www.dossmatik.de) (dose)]

> 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.

[René D. (Firma: www.dossmatik.de) (dose)]

ich habe noch einen schönen Beitrag zu dem Thema gefunden.


www.actel.com/documents/TestVector_AN.pdf

[Stachele (Gast)]

Naja, etwas altbacken, anno 2003. So generiert man doch keine Stimuli 
mehr ...

"Bus Functional Model" lautet hier das Stichwort.

[René D. (Firma: www.dossmatik.de) (dose)]

> "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.

[Stachele (Gast)]

Was für Daten muss du denn stimulieren?

[René D. (Firma: www.dossmatik.de) (dose)]

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.

[Stachele (Gast)]

>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?

[René D. (Firma: www.dossmatik.de) (dose)]

> 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.