Debug Hilfe benötigt bei Mixed Language Modul

Für's Erste, würde ich sagen alle Signale die in deinen Processes ohne 
Reset ihre Treiber haben, sollten bei der Deklaration Default Werte 
bekommen

z.B. im Process clked in der Datei FFT_Interface.vhd

Ich habe einige probeweise gepatched aber es sind zu viele ...

Machst du was für Xilinx, dass du kein globales Reset Konzept hast? Ich 
würde trotzdem wenigstens einen synchronen Reset einführen.

Alexx schrieb:
> Ist ein globaler Reset so wichtig?
das kommt anscheinend darauf an, wen du fragst. Ich sage definitiv ja. 
Auch wenn Xilinx z.B. etwas anders propagieren möchte, du siehst hier 
was passiert mit einem OEM Simulator. ISim nehme ich gar nicht her. Es 
ist kein Standard, es sei denn ich entwickele ausschliesslich für X. Ein 
Design und vor allem ein Testbench braucht nun Mal einen definierten 
Startpunkt.

> Hattest du dieses Simulationsergebnis schon von anfang an? In meiner
> Simmulation bleibt der State bei WAITIFFT hängen! So bin ich erstmal auf
> den Fehler gekommen dass das ausgangssignal der FFT garnicht übernommen
> wird!

Yupp, alles schnell die Reihe nach durch Aldec Riviera gejagt und für 
ca. 150 us laufen lassen. (Keine Compile-/Elaborier-Fehler bei Vlog 2005 
bzw. vhdl 2008, also gratuliere)

Manuelle habe ich zunächst nur Command in der Testbench Datei einen 
Startwert gegeben.
   signal SigDataCommand : std_logic_vector (15 downto 0) := (others => 
'0');

Alexx schrieb:
> aber es ändert sich leider nichts

In der Tat, es schaut ein Bisschen verzwickter aus.
Ich habe Riviera mit folgendem Aufruf gestartet:
vsim -dbg fft_mnet_lib.Interface_TB -t 100ps +access +r -initregs 0;log 
-rec sim:/*;run 150 us

(Modelsim wird ein ähnlicher Aufruf haben.)

Damit muessten alle nicht intialisierte Verilog Regs einen Startwert 
bekommen. Die 'X'en sind trotzdem noch da. Auf dem ersten Blick scheinen 
sie aus den nicht initialisierten Memories zu kommen, -initregs wirkt 
nicht auf Memories.
Wahrscheinlich brauchst du z.B. eine Initialisierungs State Maschine, 
die alle Ausgänge maskiert bis die Memories geladen sind. Ich bin zwar 
nicht so weit durchgestiegen, dass ich alles verstehe was du machst, 
aber ich vermute, dass vorangegangene Werte in die Memories geschrieben 
werden um Delay Taps zu implementieren (oder so was ähnliches).

Jedenfalls ein 'X' Kern scheint der process in Zeile 4034 von FFT.v zu 
sein.

Alexx schrieb:
> Die Frage die sich mir nun stellt ist: Wie ist das in der hardware? Sind
> hier nur simmulationstools überfordert oder ist es tatsächlich ein
> Problem?
>

Überfordert sicher nicht. Es ist halt ein anderer Ansatz. Die 
Simulatoren arbeiten nach den Verilog bzw. VHDL Spezifikationen und da 
ist z.B. auch geregelt wie die Initialwerte zum Zeitpunkt T0 zu stehen 
haben.

In der Praxis gibt es natürlich kein 'X' oder 'U'. Was es aber geben 
kann sind obskure Konstellationen von speichernden Elementen, die mal 
harmlos, mal ein unangenehmer Knacks in einer Audioübertragung und mal 
ein FSM Hänger sind. Eine robuste Logik muss in der Lage sein nach einem 
'unangenehmen Zustand' selbst zu erholen oder eben braucht sie einen 
sauberen Reset.

> Den die DFT funktioniert eigentlich mit der mitgelieferten Testbench
> (wie gesagt, die ist nicht selbstgeschrieben, kommt von
> http://www.spiral.net/hardware/dftgen.html).

Jetzt habe ich mal interessenshalber den Verilog Testbench angeworfen, 
es kostet ja nur einen Ausruf. Im Testbench wird am Anfang sauber 
initialisiert, ich denke nach dem Wegnehemen des Resets braucht deine 
Logik eine 'Start Maschine', die alle X[15:0] Eingänge für z.B. 32 
Zyklen auf '0' treibt. Danach kann das Leben losgehen. Ich meine gesehen 
zu haben, dass die interne Mems eine 5-bit Adressvektor haben.

Wenn du den folgenden Abschnitt des Testbenches (fft.v) anschaust, 
schaut es so aus, dass zuerst bekannte Werte angelegt werden und dann 
auf ein aktives nextL gewartet wird bevor der eigentliche Test startet.

   222     initial begin
   223        // set initial values
   224        in[0] <= 0;
   225        in[1] <= 0;
   226        in[2] <= 0;
   227        in[3] <= 0;
   228        in[4] <= 0;
   229        in[5] <= 0;
   230        in[6] <= 0;
   231        in[7] <= 0;
   232        in[8] <= 0;
   233        in[9] <= 0;
   234        in[10] <= 0;
   235        in[11] <= 0;
   236        in[12] <= 0;
   237        in[13] <= 0;
   238        in[14] <= 0;
   239        in[15] <= 0;
   240        nextL <= 0;
   241        reset <= 0;
   242
   243        @(posedge clk);
   244        reset <= 1;
   245        @(posedge clk);
   246        reset <= 0;
   247        @(posedge clk);
   248        @(posedge clk);
   249        // Wait until nextL_out goes high, then wait one clock 
cycle and begin receiving data
   250        @(posedge nextL_out);
   251        @(posedge clk); #1;
   252        $display("--- begin output wire 1---");

Da du gemeint hast, dass deine Verilog Kenntnisse nicht ganz auf der 
Höhe sind, die "initial" Prozesse sind nichts anders als ein process, 
das nur einmal läuft und automatisch bei T0 gestartet wird.