Forum: FPGA, VHDL & Co. REST-API-Call mit einem FPGA


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Tlaquepaque O. (tlaquepaque_o)


Bewertung
0 lesenswert
nicht lesenswert
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

von C. A. Rotwang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von -gb- (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wenn er im FPGA eine CPU oder ein SoC verwendet, wo ist dann der 
Geschwindigkeitsvorteil gegenüber einer CPU/SoC ohne FPGA?

von Emil (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Tlaquepaque O. schrieb:
> geringst möglichste Latenz ....... Ethernet

Finde den Widerspruch.

von Stoepselhund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
-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. ;-)

von Stoepselhund (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
"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.

von D00fi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Einfach mal bei Arista anfragen. Aber genug $$$ bereithalten!

von Tlaquepaque O. (tlaquepaque_o)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Blechbieger (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Stoepselhund (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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...

von Stoepselhund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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..

von Blechbieger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stoepselhund schrieb:
> Diejenigen, die ich kenne, nutzen RTP (also UDP).

Danke, das Detail wusste ich nicht.

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
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...).

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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? 
;-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.