Ich möchte ein älteres Schaltungsdesign auf Basis eines Spartan (ISE Projekt) auf einen Kintex umstellen und Vivado verwenden. Kann es sein, dass es die FFT-IP von Xilinx nur noch als AXI-Version gibt? Oder lässt sich das irgendwie umgehen? Und wie schließe ich die IP funktionell an? Abgesehen, dass ich mit dem Config-Anschluss nichts anfangen kann, weil ich das nicht brauche, ist mir nicht klar, was der AXI-Bus dort soll. 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. Wenn angenommen der Core einmal eine Weile nicht ready sein sollte, müsste ich den Datenstrom unterbrechen. Das kann ich aber nicht, weil er von einem Sample-ADC kommt, der mit maximaler Geschwindigkeit >333MHz anliefert. Muss ich einen Puffer-FIFO vorschalten? Wie groß muss der sein? Das Datenblatt sagt leider nichts dazu. Kann ich wenigstens annehmen, dass die Daten lückenlos wie bisher heraus gelangen, oder sind dort auch Pausen zu erwarten? 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. Außerdem ergibt sich ein Problem mit der Taktgeschwindigkeit: Angenommen das Ready ist zu 10% und markiert längere Rechenpausen, dann muss der FIFO und die FFT dahinter mit vlt. 10% mehr Tempo arbeiten, was mir unnötig die Taktfrequenzanforderung des FPGA nach oben treibt. Es ginge dann schon in Richtung 370MHz und das Design ist für 350 sicherheitsspezifiziert.
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.
> > Oder kennt jemand zufällig eine native Implementierung in Verilog oder > VHDL, welche ohne ein Prozessorinterface und dafür kontinuierlich ohne > overhead arbeitet? > Jenachdem kann eine Sliding-DFT auch zum Erfolg fuehren, da kommt man schon mal vom Pingpong-Buffering weg. Koennte man vermutlich sogar mit dem HLS-Geraffel erschlagen. Das Verhalten ist natuerlich entsprechend anders und man muss sein Windowing neudefinieren. Einen bitteren Apfel muss man auf jeden Fall mit Vivado essen.
Hohewart schrieb: > Abgesehen, dass ich mit dem Config-Anschluss nichts anfangen kann, weil > ich das nicht brauche, ist mir nicht klar, was der AXI-Bus dort soll. > 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 kann der Core immer noch. Siehe "Pipelined Streaming I/O with no Cyclic Prefix Insertion" im Datenblatt zum FFT Core. Das Ready Signal setzt du einfach fix auf '1' und gut ist. Am besten einmal durchsimulieren. ;-)
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?
Messtechniker schrieb: > 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? Genau, auf der Master Seite des Cores machs du den Ready Port einfach fix auf 1. 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. Bei den ganzen AXI Stream Cores gibt es oft durch entsprechende Konfiguration die Moeglichkeit auf den AXIS Handshake zu verzichten. Einfach mal simulieren, die Testbench mit irgendwelchen Dummy Daten ist ja super schnell aufgesetzt.
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?
Messtechniker schrieb: > Dann ist das eine Besonderheit dieses Cores, nehme ich an. Naja, ob ein Core das kann steht im Datenblatt. Der CORDIC kann das z.B. auch. Messtechniker schrieb: > 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? Genau. Du holst den Core aus dem Reset (wie das bei vielen IPs ueblich ist) und dann geht direkt das Ready mit hoch. Ich wuerde einfach mal das Datenblatt lesen, ich hab da jetzt auch nicht tiefer reingeschaut. Beim CORDIC kann ich 100%ig sagen, dass er das Pipelining unterstuetzt und bei dem FFT Core liesst es sich auch, als koenne er das. Warum sollte das auch anderst sein? Am Ende steckt da genau das Gleiche drinnen wie die alte Variante ohne AXIS, nur dass man eben einen Handshake aussenrum gebaut hat. ;-)
Tobias B. schrieb: > nur dass man eben einen > Handshake aussenrum gebaut hat. ;-) ... und AXI-FIFOs die Block-RAM-Resourcen verbrauchen und aufgrund der vielfältigen Möglichkeiten des handshakings und des AXI-Betriebes auch wirklich BRAM sind und nicht auf interne FIFOs zugrückgreifen können, ohne etwas drum herum zu bauen und damit langsamer werden, was die maximale Taktfrequenz senkt. In Einzelfällen führt eine statisch 1 auf den Ready-Signalen noch dazu, dass Kombinatorik eingespart wird, aber ich habe schon Vergleiche angestellt und die AXI-fähigen Cores sind allesamt größer, und langsamer, was Flächenverbauch angeht. Das Anfordern eines BRAMs scheint mir besonders unschön, weil dann der Router dort hin in routen muss, während er generische Logik (und FFT wäre ein Beispiel dafür) durchaus in die FPGA-Fläche vorort verteilen kann. Da kommt man oft schlechter bei raus. Man kann das auch oft beobachten, wenn man auf diese Weise den AXI beschaltet, bauen lässt, faktisch ein AXI-freies Design bekommt oder bekommen sollte und es dann mit dem Ergebnis der Schaltung vergleicht, die man bekommt, wenn man den CORE auf natives Interface geschaltet hatte (soweit das noch geht). Für FFT benutze ich inzwischen eine handgeschriebene Version. Die kann zwar nicht alle Optionen, die man im XI-Core konfigurieren kann, ist aber schneller, als der schnellste XI und dabei kleiner und er ist kleiner, als der kleinste XI und dabei noch schneller. Er baut nur ewig! Ich habe den Verdacht dass die neueren Vivadotools sich nicht nur einfach das native IF sparen, sondern auch vorgefertigte Platzierungsoptionen mitbringen, die eine schnelle Synthese und Implementierung ermöglichen und dann "gröber" bleiben und weniger optimierbar sind - was auch immer da im Hintergrund eine Rolle spielt.
Hohewart schrieb: > 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. In aller Regel sind die FPGAs um Welten schneller, als CPUs - auch bei FFT. Ich hatte bisher nur zwei Fälle, in denen solche Berechnungen (einmal eine korrelierende FFT und einmal eine DFT) absichtlich in CPUs / DSPs gemacht wurden: Die waren jeweils gerade noch schnell genug, um es innerhalb der gesteckten Echtzeitanforderungen zu schaffen, haben aber sehr viel weniger Strom benötigt. Beide Systeme waren Battery-Powered. In einem Fall konnte ich in der Nachbetrachtung zeigen, dass die FFT im FPGA besser gewesen wäre und man lieber hätte etwas anders in die DSPs verschieben sollen. Da muss man eben die richtige Implementierung nehmen und vergleichen und aufpassen, wo man noch die meiste Luft hat, etwas in vorhandene HW reinzustecken. 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.
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
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.