Xilinx FFT IP-CORE wie ansteuern?

Hohewart schrieb:

> Die FFT wurde bisher im Stream-Mode benutzt und mit jedem Takt ein Datum
> eingeschoben. Nach etwas Delay kam dann das Ergebnis lückenlos heraus.
>
> Das ist jetzt nicht mehr so, nehme ich an.

Worauf gründet sich Deine Annahme? Axi gibt es auch als Streamfähiges 
Interface.

https://www.kampis-elektroecke.de/2020/04/axi-stream-interface/
https://www.xilinx.com/content/dam/xilinx/support/documentation/ip_documentation/axis_interconnect/v1_1/pg035_axis_interconnect.pdf

> Ich würde ungern irgendwelche FIFOs benutzen von denen ich nicht sicher
> sagen kann, dass sie funktionieren, weil sie groß genug sind. Wenn keine
> Aussage zu treffen ist, kann ich formell nicht nachweisen, dass es immer
> klappt.

Man kann eine Aussage über die Größe eine Fifo durch simulation 
derselben ableiten.Und man kann/muß ohnehin eine Fehlerbehandlung (bspw. 
Fifo-restart) vorsehen wenn die Datenkonsistenz nicht gewährleistet ist, 
beispielsweise an den full/empty flags erkennbar.
Oder man schaut im map/Synthese-log nach, was an FIFO-Makros eingebaut 
wurde, vielleicht hilft das tcl-command 'report_utilization'.

Fpgakuechle K. schrieb:
> Worauf gründet sich Deine Annahme? Axi gibt es auch als Streamfähiges
> Interface.

Aber auch das hat doch ein handshaking mit Berücksichtigung des 
Ready-signals des Slaves und der FFT-Core ist ein solcher. Das Streaming 
habe ich auch vorliegen, meine ich:

1

COMPONENT xfft_nrz_screen

2

  PORT (

3

    aclk : IN STD_LOGIC;

4

    s_axis_config_tdata     : IN STD_LOGIC_VECTOR(7 DOWNTO 0);

5

    s_axis_config_tvalid    : IN STD_LOGIC;

6

    s_axis_config_tready    : OUT STD_LOGIC;

7

    s_axis_data_tdata       : IN STD_LOGIC_VECTOR(31 DOWNTO 0);

8

    s_axis_data_tvalid      : IN STD_LOGIC;

9

    s_axis_data_tready      : OUT STD_LOGIC;

10

    s_axis_data_tlast       : IN STD_LOGIC;

11

    m_axis_data_tdata       : OUT STD_LOGIC_VECTOR(63 DOWNTO 0);

12

    m_axis_data_tvalid      : OUT STD_LOGIC;

13

    m_axis_data_tready      : IN STD_LOGIC;

14

    m_axis_data_tlast       : OUT STD_LOGIC;

15

    event_frame_started : OUT STD_LOGIC;

16

    event_tlast_unexpected : OUT STD_LOGIC;

17

    event_tlast_missing : OUT STD_LOGIC;

18

    event_status_channel_halt : OUT STD_LOGIC;

19

    event_data_in_channel_halt : OUT STD_LOGIC;

20

    event_data_out_channel_halt : OUT STD_LOGIC

21

  );

22

END COMPONENT;

Daten waren als 16 Bit IN und 27 Bit OUT definiert, sind nun irgendwie 
in dem AXI32/64 verpackt worden, nehme ich an. Ich gehe davon aus, dass 
die Bandbreite berücksichtigt wurde. Auch so ein schlecht handhabbarer 
Faktor.

Fpgakuechle K. schrieb:
> Man kann eine Aussage über die Größe eine Fifo durch simulation
> derselben ableiten.
Hängt aber von dem Verhalten des Models ab und ob man jeweils dadurch 
eine sichere Aussage erhält, sehe ich nicht als belastbar, da von den 
Randbedingungen abhängig.

> Und man kann/muß ohnehin eine Fehlerbehandlung (bspw.
> Fifo-restart) vorsehen wenn die Datenkonsistenz nicht gewährleistet ist,
Das kommt auch noch dazu.

Eventuell noch dies als Ergänzung: Die FFT wurde absichtlich zum 
damaligen Zeitpunkt in den FPGA verlegt, weil der das schnell und 
effektiv gemacht hat, statt es kleinteilig auf dem angeschlossenen ARM 
zu rechnen. Eine Prozessorarchitektur wird es auch im zukünftigen System 
wieder in ähnlicher Weise geben. Ich frage mich aber ob es nicht 
zweckmäßiger ist, angesichts des Aufwandes die FFT doch in einer der CPU 
timeslots zu machen und mehrere Kerne einzusetzen. Diesmal werden es 
I7-industrial Plattformen.

Oder kennt jemand zufällig eine native Implementierung in Verilog oder 
VHDL, welche ohne ein Prozessorinterface und dafür kontinuierlich ohne 
overhead arbeitet?

Das alte System arbeitet so, dass eine Strecke von mehreren hunderten 
Datenblöcken zu 768 Daten (mit Zerofeed) kontinuierlich in mehreren 
FFT-lanes berechnet werden und die Ergbnisse in einen Speicher kommen, 
aus dem sich die CPUs bedienen. Das würde ich gerne beibehalten. Die 
Alternative wäre, alles hochzuladen und die FFTs dann offline zu machen, 
oder es im FPGA zu puffern und dann so langsam zu machen, dass es der 
FPGA kann, was reichlich unpraktisch wäre.

Hohewart schrieb:

> Oder kennt jemand zufällig eine native Implementierung in Verilog oder
> VHDL, welche ohne ein Prozessorinterface und dafür kontinuierlich ohne
> overhead arbeitet?

Wenn einem der Zufall Nichts zur Kenntnis bringt, kann man sich einen 
FFT-Core auch wunschgemäß von einem Dritten schreiben lassen. 
Beispielsweise als Abschlussarbeit von einem Stunden oder von einem 
Freiberufler. Bei den klaren Randbedingungen würde ich ich für einen 
Profi wenige Wochen Arbeit ansetzen.

Hohewart schrieb:
> Kann es sein,
> dass es die FFT-IP von Xilinx nur noch als AXI-Version gibt?
Die meisten Cores gibt es nur noch mit AXI-Interface. Xilinx treibt 
damit die Politik der konfigurierbaren SoCs voran und die darin verbaute 
programmierbare Logik ist in beliebigem Umfang vorhanden. Da macht es 
nichts, wenn etwas mehr davon verbraucht wird. Der Kunde zahlt es.

Mit der Taktfrequenz ist es ähnlich: Was AXI mehr an Logik verbraucht, 
führt zu etwas reduziertem timing budget, wird aber durch besser 
werdende FPGAs weitgehend ausgeglichen.

Tobias B. schrieb:
> Das Ready Signal
> setzt du einfach fix auf '1' und gut ist.
Setzt das nicht der Core? Oder meinst du das des 
FFT-Ergebnis-Empfängers? Das sagt ja nur, dass der AXI-Slave bedient 
werden darf und impliziert noch nicht, dass das durch den Master auch 
passiert. Der Master (in dem Fall der FFT-Core) muss auch Daten haben. 
Gibt er das Ready dann einfach nach vorne durch und schaltet auch 
Durchzug?

Tobias B. schrieb:
> Wenn der Core im Pipelined Streaming bedient wird, dann
> kommen die Daten mit einem valid lueckenlos raus, sofern du die Daten
> auch lueckenlos reinschiebst. Was in entsprechendem Mode erlaubt ist.

Dann ist das eine Besonderheit dieses Cores, nehme ich an. Allgemein 
gibt es das ja nicht. Jetzt stellt sich nur noch eine Frage:
Wann fängt man an, lückenlos zu schreiben? Ich würde raten, wenn das 
Ready des Cores high geht?  Irgendwie muss ja gesteuert werden, wann man 
Einzuschreiben hat und es muss auch die Latenz des Cores in Betracht 
gezogen  werden. Ich habe schon länger nichts mehr mit FFTs gemacht, 
aber aus der Erinnerung würde ich schätzen, dass das erste Datum so etwa 
nach einer Taktzahl heraus kam, die der Länge der FFT entsprach (bei 
Verwendung von ordered sequencing). Also Takt 0...127 Daten rein, 
128...255 zweites Paket und bei 160 kommt das Ergebnis des ersten Pakets 
raus.

Ist das eigentlich immer noch so, dass die FFT zweimal, also mit den 
Spiegelfrequenzen herauskommt?

Jürgen S. schrieb:
> Generell gilt natürlich: Solange eine CPU eine Aufgabe packt, ist es
> immer besser für den Strombedarf und sehr oft auch günstiger im
> Endpreis, weil der stärkere DSP, den man statistisch braucht, weniger
> Aufpreis kostet, als der größere FPGA.
Und nicht zu vergessen: Die Entwicklungszeit und das Debugging für einen 
Algorithmus, der in einer CPU abgearbeitet wird, ist um eine 
Größenordnung geringer. Außerdem findet man viel eher einen Softwerker, 
als einen FPGA-Werker :-)

Duke