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?
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?
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:
@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.
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.