Xilinx FFT-Core liefert nur sporadisch Daten

[Michael W. (Gast)]

Ich habe einen screenshot angehängt, der zeigt, wie ich die FFT 
ansteuere:

Es gibt einen Start, der xn_index zählt hoch und ich schiebe 
kontinuierlich Daten rein. Zunächst Nullen, später dann die 
reinfließenden Daten. Mal davon abgesehen, dass das funktionell noch 
nicht so dolle aussehen sollte, hätte ich wenigstens valide Daten 
erwartet.

Fur real und imag out kommen aber nur einzelne Daten, ansonsten ist es X 
= rot, wie in der letzten Zeile ersichtlich. Es sind jeweils alle Bits 
der Ausgänge auf X.

Ich hatte schon mehrfach FFTs im Gebrauch und so einen Effekt noch nicht 
gesehen.

Woran könnte das liegen?

fftcore : fft2048
  PORT MAP (
    clk        => fft_clock,
    start      => fft_start_d2,
    xn_re      => fft_real_in,
    xn_im      => fft_imag_in,
    fwd_inv    => '0',
    fwd_inv_we => '0',
    rfd        => open,
    xn_index   => open,
    busy       => open,
    edone      => open,
    done       => open,
    dv         => open,
    xk_index   => fft_addr_out,
    xk_re      => fft_real_out,
    xk_im      => fft_imag_out
  );

[Michael W. (Gast)]

Es ist eine pipelined streaming FFT.

Wie man sieht, sind während der Phasen des Ladens bei xn_index aktiv 
auch immer Daten da. Ich habe es geprüft, es werden keine Unknonws 
eingeschoben oder so.

DataValid und xk_index, also die Ausgangsphase passen aber, d.h. die FFF 
läuft wie gewohnt ab.

Liegt es daran, dass ich stoppe und nicht permanent streame? Dann 
müssten falsche Daten reinkommen, aber eigentlich dennoch formell 
gültige Werte raus, oder?

[Patrick B. (p51d)]

Irgend etwas stimmt bei deiner Beschaltung überhaupt nicht. Wenn ich den 
Screenshot richtig lese, dann gibt der Core Daten aus, befor du 
überhaupt welche an den Eingang legst.
Ich hatte eine Pipelined Streaming FFT im System Generator umgesetzt, 
und da war eine Latenz von ~200 Takten zwischen Eingang und Ausgang. 
Also irgendo ist da noch ein Fehler.

Wie hast du den IP Core erzeugt? Es sieht für mich aus, als ob auch ein 
paar Ein- Ausgänge fehlen würden... (Btw. der core gibt die Daten 
normalerweise in Bit-Reversed Order aus). Wenn ich im Vivado einen FFT 
Core aus dem IP Katalog erstelle, kommt im Minimum (Pipelined, ohne 
sonstige Änderungen) das heraus:

your_instance_name : xfft_0
  PORT MAP (
    aclk => aclk,
    s_axis_config_tdata => s_axis_config_tdata,
    s_axis_config_tvalid => s_axis_config_tvalid,
    s_axis_config_tready => s_axis_config_tready,
    s_axis_data_tdata => s_axis_data_tdata,
    s_axis_data_tvalid => s_axis_data_tvalid,
    s_axis_data_tready => s_axis_data_tready,
    s_axis_data_tlast => s_axis_data_tlast,
    m_axis_data_tdata => m_axis_data_tdata,
    m_axis_data_tvalid => m_axis_data_tvalid,
    m_axis_data_tready => m_axis_data_tready,
    m_axis_data_tlast => m_axis_data_tlast,
    event_frame_started => event_frame_started,
    event_tlast_unexpected => event_tlast_unexpected,
    event_tlast_missing => event_tlast_missing,
    event_status_channel_halt => event_status_channel_halt,
    event_data_in_channel_halt => event_data_in_channel_halt,
    event_data_out_channel_halt => event_data_out_channel_halt
  );

[J. S. (engineer)]

@Patrick: Was Du Dir da hast erzeugen lassen, ist ein AXI-Interface. Die 
Ports die oben gepostet wurden, sehen eher aus, wie das normale 
Interface.

Was mir auffällt: So wie es da steht, mit der "0" für fwd_inv ist es 
meines Wissens nach die IFFT, die da läuft. Da würde es reichen, wenn 
ein einziger Frequenzparameter unbekannt ist, weil dann kein einziges 
Sample zielsicher erzeugt werden kann. Irgendwo kommt doch was 
Undefiniertes hinein.

Beim streaming ist es glaube ich auch so, daß mit doppelter Pufferung am 
Eingang gearbeitet wird. Die Daten, die rauskommen, haben also gfs zwei 
Zyklen Latenz. Die Transformation der Daten, die am Eingang liegen und 
auch im Bild zu sehen sind, kommen also erst weiter hinten, was hier 
nicht mehr abgebildet ist. Ist es da auch noch rot?

Und: Der Core ist gfs nicht parametriert, weil das enable für die 
Änderung der Richtung auch "0" ist.

[Michael W. (Gast)]

Die Konversionsrichtung wird im VHDL im Betrieb umgeschaltet, das müsste 
an der richtigen Stelle auch gehen.  Weiter hinten in der Simulation 
(nach mehreren Minuten!) sind die roten Signale irgendwann weg! Keine 
Ahnung, woher die Fehler vorher kommen.

Eine Sache ist noch seltsam: ISE beschwert sich, daß der FFT-Core 
Hinweise auf den SPARTAN3DSP enthält, die er in SPARTAN6 hat ändern 
müssen.

NgdBuild - The value of SIM_DEVICE on instance
   'prefix/fft1/blk0000036b/blk00000391' of type RAMB16BWER has been
   changed from 'SPARTAN3ADSP' to 'SPARTAN6' to correct post-ngdbuild and timing
   simulation for this primitive.  In order for functional simulation to be
   correct, the value of SIM_DEVICE should be changed in this same manner in the
   source netlist or constraint file.

Ich habe das im *.xco getan und nach einem neuen Erzeugen des Cores, war 
es wieder drin. (???)

[K. L. (Gast)]

Das ist irgendwas ganz am Anfang im aller ersten Takt nicht 
initialisiert und wird in den Core reingeschleppt!