Hallo zusammen! Ich bin neu hier im Forum, daher erstmal ein freundliches Hallo an alle! Es ist schon Jahre her, dass ich das letzte Mal was mit einem FPGA gemacht habe – das war noch im Studium und da haben wir eine kleine 8-bit CPU in VHDL implementiert. Das ist allerdings schon etwas her, daher bin ich momentan nicht so drin im Thema. Ich möchte etwas mit einem FPGA realisieren, da ich die bestmögliche Geschwindigkeit brauche (geringst möglichste Latenz), um über Ethernet einen REST-API-Call zu verschicken. Daher auch die Idee mit dem FPGA. Nun ist es ja so, dass ein REST-API-Call im Kern ja nichts anderes ist als ein HTTPS-Request, d.h. ich brauche schon mal HTTP und SSL/TLS im ISO-OSI-Stack. Dazu kommt dann das darunter liegene TCP und IP, dazu noch die Netzwerkschicht mit ETHERNET. Das alles in Hardware selbst zu entwicklen, erscheint mir ein unfassbarer Aufwand zu sein. Ich wäre daher dankbar, wenn mir mal jemand sagen könnte, wie man so etwas am besten in einem FPGA realisiert. Gibt es dafür fertige "Bausteine" in VHDL, um zumindest auf der SSL-Ebene im ISO-OSI-Stack aufzusetzen? Noch besser wäre natürlich, wenn ich direkt den HTTP-Layer ansteuern könnte. Den HTTP-Request zusammen zu bauen ist nicht wirklich schwer. Ich bedanke mich bereits im Voraus für eure Antworten. Es wäre schön ein paar Einsteigspunkte für die weitere Recherche zu haben. Schöne Grüße
Entweder du hinterlegst das datanpaket im ROM und streamst es seriell raus oder du nimmst einen SoC-FPGA mit full blown operating system: Für letzteres schau dir mal das ZCU102 evaluation kit an: https://www.xilinx.com/products/boards-and-kits/ek-u1-zcu102-g.html
Falls es ne Spur kleiner sein soll, geht auch ein reiner FPGA in dem man eine SoftCPU ala Microblaze packt. Mittels Lightweight IP sollte man dann die REST Calls absetzen koennen.
Wenn er im FPGA eine CPU oder ein SoC verwendet, wo ist dann der Geschwindigkeitsvorteil gegenüber einer CPU/SoC ohne FPGA?
Eine REST-API mit FPGA als Master mit allen Stacks in HW zu entwickeln macht absolut keinen Sinn. Echtzeit-Performance ist schon mal nicht gegeben. Reicht also ein SoC (CPU, Ethernet, DMA) und ein Murks-Stack a la LWIP (da ist allerdings scatter/gather 'ad absurdum'). Wenn nur Parameter zwischen vernetzten Geräten kommuniziert werden müssen, gibt es deutlich kompaktere und performantere Ansätze bei dem die RPC-Transaktionen über einen Linux-Proxy nach REST/modbus/usw. getunnelt werden.
-gb- schrieb: > Wenn er im FPGA eine CPU oder ein SoC verwendet, wo ist dann der > Geschwindigkeitsvorteil gegenüber einer CPU/SoC ohne FPGA? Ds haengt von der Problemstellung ab. Wenn sie/er harte Echtzeit Bedingungen fuer den REST Call hat, dann hat sie/er ein Problem (zumal die Gegenstelle entsprechend genauso in Echtzeit die Calls empfangen und verarbeiten muss). Wenn sie/er das Echtzeit Problem auf alles was vor dem REST Call passiert verlagern kann, dann hat sie/er hier die gaengisten Loesungsansaetze vorgestellt bekommen. Was sie/er daraus macht ist dann sein Bier. Vielleicht mag sie/er ja mehr Details berichten, dann kann man vll. Alternativen empfehlen. ;-)
Tobias B. schrieb: > Ds haengt von der Problemstellung ab. Wenn sie/er harte Echtzeit > Bedingungen fuer den REST Call hat, dann hat sie/er ein Problem (zumal Wie oben schon geschrieben, ist das Nonsense bei einer TCP-Verbindung. Da bringt eine FPGA-Implementierung keinen Vorteil gegenüber einem Standard SoC, eher im Gegenteil.
Stoepselhund schrieb: > Wie oben schon geschrieben, ist das Nonsense bei einer TCP-Verbindung. > Da bringt eine FPGA-Implementierung keinen Vorteil gegenüber einem > Standard SoC, eher im Gegenteil. Da stimme ich dir auch 100% zu.
"Echtzeit" und "REST-API-Call" sind schon zwei Worte, die sich sinnvoll nur zusammen mit einer Negation in einem Satz unterbringen lassen. "FPGA" passt da überhaupt nicht dazu.
Hallo zusammen. Erstmal danke für die Antworten und die Ideen. Vielleicht würde es helfen, die Rahmenbedingungen besser zu beschreiben. Ich muss einen REST-API-Call an eine entfernte API machen, die nur über das Internet erreichbar ist. Der API-Call muss so schnell wie möglich abgesetzt werden und das Datenpaket so schnell wie möglich über das Internet verschickt werden. Mit Echtzeit hat das in meinen Augen weniger zu tun, sondern einfach mit schneller Reaktionszeit bzw. wenig Latenz in "meinen" Netzwerkkomponenten. Mir ist klar, dass ein großer Anteil, wenn nicht gar der größte Anteil, am Netzwerk selbst liegt. D.h. wie das Paket geroutet wird, wie momentan die Netzwerklast ist etc... Den externen Teil kann ich aber nur bedingt beeinflussen. Was ich beinflussen kann: wie schnell das Paket bzw. der API-Call von mir rausgeschickt wird. Mit anderen Worten habe ich also folgendes als Rahmenbedingung: eine RJ45-Ethernet-Schnittstelle um die Anbindung ans Internet zu haben. Und die Ansteuerung einer REST-API, die über das Internet erreichbar ist. Diese beiden Sachen sind also fix und ich stelle mir jetzt die Frage, wie ich das am besten lösen kann, damit in der Zeit nach unten komme. Meine erste Idee ging dahingehend, dass ich mir das Ethernet-Paket(e) Schicht für Schicht im OSI-Modell "statisch" zusammen baue (Inhalt ist dynamisch) und diesen Ethernet-Frame bzw. diese Frames dann auf die RJ45-Schnittstelle lege. Das geht aber nicht, da im Protokollstapel SSL/TLS mit drin ist und daher erstmal ein SessionKey ausgehandelt werden muss. Ebenso muss eine Sitzung/Handshake im TCP-Layer stattfinden. Also ohne Implementierung dieser Schichten wird es nicht gehen.
Die Geschwindigkeit wird der so oder so von der Gegenstelle begrenzt. Daher kannst du problemlos den API Call via Software Stack aufbauen. Selbst wenn du das direkt via FPGA absetzen koenntest, wuerdest du nur marginal Zeit einsparen. Die Zeitskalen auf denen sich so ein Call bewegt liegt im Millisekunden Bereich (tendenziell eher zweistellig wie einstellig, abhaengig von der Netzwerk Infrastruktur). Die Call Prozedure in den FPGA zu verlagern spart dir vll ein paar Mikrosekunden Zeit ein, liegt also im Promille bis Subpromille Bereich. Ich kann mir bei bestem Willen nicht vorstellen, dass das eine sinnvolle Optimierung ist. Daher meien Empfehlung: Zynq oder Microblaze nehmen und den API Call in Software packen.
Tobias B. schrieb: > Daher meien Empfehlung: Zynq oder Microblaze nehmen und > den API Call in Software packen. Tlaquepaque O. schrieb: > Ich möchte etwas mit einem FPGA realisieren, da ich die bestmögliche > Geschwindigkeit brauche (geringst möglichste Latenz), um über Ethernet > einen REST-API-Call zu verschicken. Daher auch die Idee mit dem FPGA. Wenn er das FPGA sowieso NUR deshalb verwenden würde, dann kann er aber auch einen SoC ohne FPGA nehmen.
Ist das ein Hobbyprojekt oder kommerziell? Falls kommerziell, Geld in die Hand nehmen. Für die Netzwerklayer bis hin zu TLS gibt es fertige Implementierungen zu kaufen oder auch kostenlos, wobei ich auf die Schnelle keine Open-Source-Implementierung für TLS gefunden habe. Solche kompletten Implementierungen inklusive Anwendungslogik im FPGA wird z.B. in der Finanzindustrie für High-Frequency-Trading eingesetzt. Ist deine Gegenstelle fix oder kann das eine x-beliebige sein? Im ersten Fall kannst du dich auf ein Schlüsselaustauschverfahren, einen Hashalgorithmus, ein Verschlüsselungsverfahren usw. beschränken. Andernfalls musst du den kompletten TLS 1.3 Standard implementieren was die Arbeit vervielfacht.
Nochmal von vorne (wie oben auch in anderer Form):
Vergleiche die Latenzzeiten/Jitter (die durchaus etwas mit Realtime zu
tun haben) von Auftreten des Ereignisses bis Ausgang des Paketes ('DMA
DONE') mit den klassischen TCP-Latenzen (siehe auch ping und
traceroute). Auch wenn du die Session (per Software) früh aushandelst
und einen Hardware-SSL-Layer hättest, bringt dir das FPGA hier absolut
gar nix an Vorteil. Zum Vergleich: Echtzeit-Linux schafft eine
garantierte Latenz von Inzidenz bis Triggerung eines UDP-Pakets per DMA
im Bereich von 50 us (grosszügig!). Der hier in der entsprechenden
Lösung eingesetzte DSP hat mit 600 MHz deutlich mehr Performance als ein
FPGA-SoC-CPU-Core.
Zudem gibt's bei TCP ein grundsätzliches Problem: Hast du einen Hänger
(bis 30s zum Timeout) kriegst du weitere Ereignis-Pakete gar nicht erst
abgesetzt und musst puffern oder die Verbindung aktiv terminieren um das
nächste Ereignis abzuschicken. TCP garantiert dir keine Latenzen, die
https-REST-API ist unter dem Aspekt 'low latency' somit broken by
design.
Also: Schau dir mal das klassische TCP-Pingpong-Schema an und es wird
klarer. Sollte das eine industrielle Lösung werden: Vergiss es. Falls
akademisch: Knock yourself out...
Blechbieger schrieb: > Solche kompletten Implementierungen inklusive Anwendungslogik im FPGA > wird z.B. in der Finanzindustrie für High-Frequency-Trading eingesetzt. Diejenigen, die ich kenne, nutzen RTP (also UDP). Da dann allerdings in der Tat per FPGA, mit einer 100MBit-Leitung gehen da schon > 1000 Transaktionen pro Sekunde, wenn mal ein paar fehlen, spielt das keine Rolle. Die Aufbereitung für die Display-Widgets der Bank laufen allerdings im Browser in der Tat per REST-API, werden aber zentral von einem Server bedient, der die Daten per Highspeed-Paketfilter aggregiert. Sind dann aber spezielle Netzwerkkarten..
Stoepselhund schrieb: > Diejenigen, die ich kenne, nutzen RTP (also UDP). Danke, das Detail wusste ich nicht.
Tlaquepaque O. schrieb: > Diese beiden Sachen sind also fix und ich stelle mir jetzt die Frage, > wie ich das am besten lösen kann, damit in der Zeit nach unten komme. Näher an die Gegenstelle ziehen, damit zwischen dir und der Gegenstelle weniger Internet liegt. War in den Anfängen auch so ein beliebter Trick bei den High-Frequency Trading Menschen. Mittlerweile haben sie die Kabel zu denen verlängert, damit alle gleich lang sind und es wird regelmässig umgepatched, damit niemand Weint, er sei kein Milliardär, weil die anderen bessere/kürzere Kabel hatten (habe gerade keine Quelle dazu, aber das war mal in irgend so einer Dokumentation aus Manhatten...).
Christoph Z. schrieb: > War in den Anfängen auch so ein beliebter Trick bei den High-Frequency > Trading Menschen. Mittlerweile haben sie die Kabel zu denen verlängert, > damit alle gleich lang sind und es wird regelmässig umgepatched, damit > niemand Weint, er sei kein Milliardär, weil die anderen bessere/kürzere > Kabel hatten (habe gerade keine Quelle dazu, aber das war mal in irgend > so einer Dokumentation aus Manhatten...). Das war aber nicht zufaellig Knight Capital die da rumgemosert haben? ;-)
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.