Hi, hat schon mal jemand mit einem Xilinx FFT hard core gearbeitet? Ich hab damit folgendes Problem: Egal was für Signale ich in die FFT hineingeben, das Ausgangssignal im Frequenzbereich ist immer verdreht. Hier ein Beispiel: Das Eingangssignal ist ein Sinus mit einer Frequenz von 2 Hz. Als Ausgang der FFT erwarte ich folgendes Signal: -> f(0)=0; f(1)=0; f(2)=1; f(3)=0; …; f(N-3)=0; f(N-2)=-1; f(N-1)=0; f(N)=0; Die FFT liefert allerdings folgendes Ausgangssignal: -> f(0)=0; f(1)=0; f(2)=-1; f(3)=0; …; f(N-3)=0; f(N-2)=1; f(N-1)=0; f(N)=0; Ich verstehe nicht wieso das Ausgangssignal verdreht ist. Hat jemand von euch eine Idee? Ist es möglich das Ausgangssignal zu verdrehen? Gruß, Kristian
Meistens wird das Ergebnis in einem RAM abgelget. Es verbietet Dir keiner, den rückwärts auszulesen. Duke
Klar verbietet es einem keiner den rückwärts auszulesen, aber was ist der Grund dafür? Will eine Autokorrelation mit einem FFT und invers FFT realisieren. Da nun der erste FFT die Daten verkehrt herum ausgibt muss ich die ganzen Daten zwischenspeichern. Kostet nur unnötig Resourcen.
Seit wann hat Xilinx nen FFT Hard Core? Die DSP Blöcke in den Virtex und im Spartan3A DSP sind mir bekannt aber ein FFT Hard Core!?!? Klär mich mal auf, vielleicht kann ich helfen.
Bei radix-2 FFT sind je die Daten normalerweise bit-reversed, nicht einfach verdreht. Schau doch mal im Datenblatt von dem core nach den du nutzt. Wenn du FFT/IFFT machst, kann es sinnvoll sein für die FFT einen Decimation In Frequency (DIF) und für die IFFT einen Decimation In Time (DIT) cores zu nutzen. Dann sind zwar die Daten im Frequenzbereich verdreht, aber Ein- und Ausgang von dem System sind in normaler Anordnung.
Da hatte ich mich vertan. Der Virtex hat natürlich keinen fft hard core sondern einen normalen soft core. Sorry! Das stimmt, die Daten sind bei radix-2 FFT bit-reversed, verursacht durch die Butterfly-Operationen. Hab in den core-Optionen "Natural order" ausgewählt, sodass die durch die Butterfly verursachte bit-reversierung aufgehoben wird. Bieten die Xilinx cores "Decimation in time" an? Hab da leider nichts auf Anhieb gefunden.
@Kris Maier: > Bieten die Xilinx cores "Decimation in time" an? Hab da leider nichts > auf Anhieb gefunden. Suchst Du vielleicht den "CIC Compiler"? (Core Generator -> Digital Signal Processing -> CIC Compiler) Duke
Laut Datenblatt http://www.xilinx.com/support/documentation/ip_documentation/xfft_ds260.pdf wird für die Burst I/O Architektur die Decimation in Time Variante genommen und für die Pipelined Architektur die Decimation in Frequency.
Ich habe den FFT Core 7 instanziert, bekomme aber komische Werte. Die Architektur scheint zu laufen, aber die Werte sind seltsam. Die Indizes kommen nicht linear heraus sondern starten so 0,256,512,768, später kommen dann die fehlenden. Das habe ich in der Doku so nicht gesehen. Ergo habe ich ein DP-RAM drangehängt und schreibe die Werte passend zu den Indizes in die Adressen. Dort kommen aber auch nur komische Werte raus. Später lese ich sie von der anderen Seite her aus. Ich habe mal einen stark ausgesteuerten Sinus auf die FFT draufgegeben, aber sehe nur Rauschen in den Werten. Hat jemand dazu eine Info? Ich denke, ich habe einige Parameter falsch eingestellt oder nutze die FFT falsch.
1 | component myFFT2048 |
2 | port ( |
3 | clk: IN std_logic; |
4 | start: IN std_logic; |
5 | xn_re: IN std_logic_VECTOR(15 downto 0); |
6 | xn_im: IN std_logic_VECTOR(15 downto 0); |
7 | fwd_inv: IN std_logic; |
8 | fwd_inv_we: IN std_logic; |
9 | scale_sch: IN std_logic_VECTOR(11 downto 0); |
10 | scale_sch_we: IN std_logic; |
11 | rfd: OUT std_logic; |
12 | xn_index: OUT std_logic_VECTOR(10 downto 0); |
13 | busy: OUT std_logic; |
14 | edone: OUT std_logic; |
15 | done: OUT std_logic; |
16 | dv: OUT std_logic; |
17 | xk_index: OUT std_logic_VECTOR(10 downto 0); |
18 | xk_re: OUT std_logic_VECTOR(15 downto 0); |
19 | xk_im: OUT std_logic_VECTOR(15 downto 0)); |
20 | end component; |
Wie müsste man die FFT parametrieren?
Georgi schrieb: > Ich habe den FFT Core 7 instanziert, ... > > Ich habe mal einen stark ausgesteuerten Sinus auf die FFT draufgegeben, > aber sehe nur Rauschen in den Werten. > Das ist vielleicht nicht so sinnvoll, denn wenn du nicht richtig skalierst wirst du einen Überlauf erhalten und dann sind die Ausgangswerte ungültig. Ein einfacher Test ist alle reellen Werte z.B. auf 1 zu setzen. Dann kommt erst mal nur der DC-Wert als Ausgang. Gut, zugegeben, dann hast du immer noch nicht Klarheit über die Indexierung, siehst aber erst mal grundsätzlich ob es überhaupt läuft. > Hat jemand dazu eine Info? > Ich kenne den Core nicht, allgemein würde ich mit einer kleineren Größe anfangen, eine die noch nachvollziehbar ist. Achte darauf das du auch die FFT und nicht die IFFT berechnest. Nehme erst mal ein kleines Signal das keinen Überlauf erzeugt und setze die Skalierung so das nicht skaliert wird. Gruß, Günter
Vielleicht noch Folgendes: Ich gebe den Sinus auf den Realteil der FFT, den Imag belege ich mit Null. Das Timing fahre ich so wie in der Application note und gelange zu Folgendem: Wenn ich ich die parametrierbare Tiefe der FFT auf "111...1" stelle, dann kommen nur ab und an Nadeln als -1 aus der FFT raus ansonsten 0 Wenn ich ich die parametrierbare Tiefe der FFT auf "10...0" stelle, also die Häfte, dann habe ich besagtes Rauschen. Simuliert wird mit ps, wie es Xilinx vorschlägt.
Ich meinte nicht die Tiefe, sondern das Scaling. Ist aber nun draussen. Trotzdem kein Ergebnis.
Angehängte Dateien:
Das kommt raus : 100kHz, bei einer 2048, jetzt lineare Ausgabe der Werte von 0...2047. Peaks sowohl im Re als auch Im bei 0 und 2027. Ich hätte eine einizge Linie im bereich der 100kHz Frequenz erwartet.
Angehängte Dateien:
und das kommt auf höhrere Frequenz heraus - wie interpretiere ich das nun?
Georgi schrieb: > Das kommt raus : 100kHz, bei einer 2048, jetzt lineare Ausgabe der Werte > von 0...2047. Peaks sowohl im Re als auch Im bei 0 und 2027. Ich hätte > eine einizge Linie im bereich der 100kHz Frequenz erwartet. Nee, das stimmt schon, wenn ich mich recht entsinne, du bekommst einen Peak bei n und bei N-n. Für Sinus ist der eine positive, der andere negative. Für Cosinus beide positiv.
Georgi schrieb: > und das kommt auf höhrere Frequenz heraus - wie interpretiere ich das > nun? Ich kenne nicht die Taktfrequenz im Verbindung mit dem Nutzsignal, aber kann das durch den Leckeffekt entstehen?
Ich weiss nicht so recht - die peaks mögen ja in Ordnung sein, ich interpretiere das so, dass dort alle restlichen unbehandelten Frequenzen kummulieren, aber ich hätte doch gerne mal einen einzigen ordentlichen peak inmitten meines Spektrums. Ich haue da einen einzigen Sinus aus einer Tabelle drauf, der im Wesentlichen als Grundsignal auftauchen muss. Nix iss...
Hallo, wie gibst Du die Daten am XN_RE-Input ein ? z.B. bei einem Sinus 0x00-0xff bei 8-Bit, wobei 0x00 die negative Amplitude und 0xff die positive Amplitude ist ? laut Datenblatt soll das im Zweierkomplement Format sein, das Byte müßte also als signed betrachtet werden, 8.Bit wäre das Vorzeichen Grüße, Micha
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.