Forum: FPGA, VHDL & Co. Cyclone oder Spartan an Ethernet


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 FPGA (Gast)


Lesenswert?

Hallo zusammen

Ich gedenke eine I/O erweiterung zu bauen für 2 unabhängige 
Einsatzmöglichkeiten:

1. FPGA-FPGA link über LWL zb mittels FTLX8574D3BCL benötigt hierbei 
werden einige gbps.

2. FPGA-Datenbank (auf PC über Ethernet (FTLX8574D3BCL)) link. Hierbei 
sollte eine signalliste auf dem FPGA mit der DB auf dem PC 
Synchronisiert werden. LWL GBE, benötigt werden ca 200mbps.

Angedacht habe ich Cyclone oder Spartan, aber evtl. würde insbesondere 
für Punkt 2 ein SOC benötigt. Weiter die Frage nach der IP für dieses 
vorhaben. Bietet dies ein Hersteller frei zur Verfügung?

Was würdet ihr für dieses Vorhaben empfehlen?

von Martin S. (strubi)


Lesenswert?

Moin,

Wenn nur das Streaming schnell sein muss und nicht zig kleine Anfragen 
bewaeltigt werden muessen, tut's ein Minimalansatz mit UDP-Stack, ein 
Spartan6-LX9 mit RISC-V SoC reicht gerade noch so knapp, besser klappts 
mit einer ZPU-Architektur.
Ansonsten kannst du auch mit Linux und hard-core(ARM) SoC draufhauen, 
aber auch bei den entsprechenden Komplexitaeten ins Stolpern kommmen.
Nicht zu vergessen: Auch Lattice Semi (plus third parties) haben 
wunderschoene Streaming-Referenzdesigns fuer ihre ECP5 Plattformen.
Schlussendlich gilt fuer alle: Kostenlos sind die IP nirgendwo, das 
Knowhow auch nicht. Das wichtigste ist ein effizienter DMA-Core, sonst 
bringt das alles nix (und du duempelst auf uIP/lwip-Performance rum).

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


Lesenswert?

In der Xilinx Welt koennte je nach Aufgabe auch der Artix was sein, das 
haengt halt stark von der Rechenpower ab. Schau dir mal das AC701 
Evalboard an, das hat eigentlich genau das drauf was du suchst und zu 
allem Beispiel Designs:

https://www.xilinx.com/products/boards-and-kits/ek-a7-ac701-g.html#hardware

Die MGTs gehen bis 6.6 Gbps, ist die Frage ob dir das reicht? Falls 
nicht muss es die naechst groessere Familie sein, das sind dann die 
Kintex.

Der Artix 7 200T ist schon ein ziemlich maechtiger FPGA, evtl. kommst du 
auch schon mit einem wesentlich kleinerem FPGA zurecht, z.B. ein 50T. 
Zum evaluieren ist das allerdings auch kein Fehler erstmal mit dem 
dicken FPGA anzufangen, dein Design soweit fertig zu machen und dann 
entsprechend den richtigen Chip auszuwaehlen.

von Weltbester FPGA-Pongo (Gast)


Lesenswert?

Hast du das ETH auf dem AC701 mal zum Laufen bekommen?

von Gustl B. (gustl_b)


Lesenswert?

Und warum FPGA? Das sind Aufgaben die eine CPU gut machen kann, ich sehe 
keinen Grund für Parallelität oder rekonfigurierbare Logik.

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


Lesenswert?

Weltbester FPGA-Pongo schrieb im Beitrag #6435735:
> Hast du das ETH auf dem AC701 mal zum Laufen bekommen?

Ging das an mich? Falls ja, muss ich mit Nein antworten, allerdings nur 
weil ich es nie ausprobiert habe und nicht mehr im Besitz eines AC701 
bin. :-(

Gustl B. schrieb:
> Und warum FPGA? Das sind Aufgaben die eine CPU gut machen kann, ich sehe
> keinen Grund für Parallelität oder rekonfigurierbare Logik.

Nope, FPGAs scheinen erstmal genau das Mittel der Wahl zu sein. FPGAs 
sind geradezu zum schaufeln grosser Datenmengen gemacht. Und ueber 
welche CPU hat den Anbindung fuer seinen Fiberlink?

von Sigi (Gast)


Lesenswert?

Punkt 1 und Lösung via CPU schliessen sich ja wohl
bei der Datenmenge total aus.
Frage dazu: Moderne (und teure) FPGAs haben ja
dedizierte Cores mit entsprechend schnellen
Schnittstellen nach aussen. Gibt es für kleinere
FPGAs auch Phys zum Zwischenschalten zwischen
FPGA-Pins und Fiberlink-Controller, so ab 10Gbps?

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


Lesenswert?

Sigi schrieb:
> Gibt es für kleinere
> FPGAs auch Phys zum Zwischenschalten zwischen
> FPGA-Pins und Fiberlink-Controller, so ab 10Gbps?

Das ist schwierig. Zumindest in der Xilinx Welt fangen MGTs ueber 10 
Gbps erst bei den Kintex an. Die wuerde ich aber schon nicht mehr zu den 
kleineren FPGAs zaehlen.

Die Alternative waehrend dann externe SerDes Bausteine, so dass man auf 
MGTs komplett verzichten kann.

von Gustl B. (gustl_b)


Lesenswert?

FPGA schrieb im Beitrag #6435398:
> Ich gedenke eine I/O erweiterung zu bauen für 2 unabhängige
> Einsatzmöglichkeiten:

Es ist völlig unklar für welches Gerät diese Erweiterungen seien sollen.
Nur um Daten von A nach B zu schaufeln braucht man keinen FPGA. Da kann 
man auch Standardhardware nehmen. Z. B. Netzwerkkarten für PCIe. Gibt es 
fertig und auch mit hohen Datenraten.

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


Lesenswert?

Gustl B. schrieb:
>
> Es ist völlig unklar für welches Gerät diese Erweiterungen seien sollen.
> Nur um Daten von A nach B zu schaufeln braucht man keinen FPGA. Da kann
> man auch Standardhardware nehmen. Z. B. Netzwerkkarten für PCIe. Gibt es
> fertig und auch mit hohen Datenraten.

Diese Quatsch Diskussion hatten wir vor ein paar Wochen schonmal. Es 
sind genug Infos vorhanden um eine fachkundige Antwort zu geben. Und 
wenn man dem nicht maechtig ist, darf man sich auch einfach nur 
enthalten. ;-)

von Gustl B. (-gb-)


Lesenswert?

Tobias B. schrieb:
> Es sind genug Infos vorhanden um eine fachkundige Antwort zu geben.

Sehe ich nicht so.

Um was geht es denn? Sollen viele Daten zwischen zwei noch unbekannten 
Geräten ausgetauscht werden? Dann wäre interessant welche Geräte das 
sind. Heutzutage haben sehr viele PCIe oder FMC und für beides gibt es 
fertige Hardware.

Sollen Daten zwischen zwei FPGAs ausgetauscht werden weil die Daten aus 
noch unbekannten Gründen in FPGAs anfallen/vorliegen? Dann wäre 
interessant ob die FPGA Hardware schon fertig ist oder nicht. Denn
1. gibt es genug FPGA Boards mit (q)sfp+ drauf (Terasic hat viele)
2. Könnte man je nach Anwendung den Umweg über einen Rechner gehen. Also 
Daten vom FPGA über DMA in den Rechner und dann wieder über normale 
Netzwerkhardware raus zum zweiten Rechner. Es wurden keine Anforderungen 
an die Latenz genannt.

Mir ist weiterhin unklar warum da FPGA drinnen sein muss.
Die Entwicklung eigener Hardware mit sfp+ und FPGA wird deutlich teurer 
wie Hardware von der Stange.

Sigi schrieb:
> Punkt 1 und Lösung via CPU schliessen sich ja wohl
> bei der Datenmenge total aus.

Tobias B. schrieb:
> Und ueber
> welche CPU hat den Anbindung fuer seinen Fiberlink?

Quasi jeder moderne PC mit PCIe. Da kauft man sich eine Netzwerkkarte 
und hat die 10 GBit/s (auch 40 GBit/s gibt es zu kaufen). Und selbst ein 
ganzer PC der das kann ist günstiger wie eine Neuentwicklung. Klar, 
braucht mehr Strom. Aber auch dazu steht nix in den Anforderungen.

Tobias B. schrieb:
> darf man sich auch einfach nur enthalten. ;-)

Das konnte ich noch nie, bin gerne ein seltsamer unangepasster 
Aussenseiter.

: Bearbeitet durch User
von Sigi (Gast)


Lesenswert?

Gustl B. schrieb:
> Quasi jeder moderne PC mit PCIe. Da kauft man sich eine Netzwerkkarte
> und hat die 10 GBit/s (auch 40 GBit/s gibt es zu kaufen).

Ein PC ist aber nicht nur die CPU, das Wesentliche ist
beim PC der PCIe-Bus, der als DMA-Kanal genutzt wird.
Die CPU spielt hier nur die dirigierende Komponente.

Es gibt sogar schon PCIe-Karten mit 4* 40 GB/s, dank
PCIe und DDR4 kein Problem. Probleme treten aber dann
auf, wenn die Daten auch noch in "Realzeit" bearbeitet
werden müssen, da ist selbst ein schneller PC zu
langsam. Wurde aber hier in Foren schon oft genug
beschrieben.

von Gustl B. (-gb-)


Lesenswert?

Sigi schrieb:
> Ein PC ist aber nicht nur die CPU

Hatte ich auch nicht behauptet. War auch nicht gefordert.

Sigi schrieb:
> in "Realzeit" bearbeitet
> werden müssen, da ist selbst ein schneller PC zu
> langsam. Wurde aber hier in Foren schon oft genug
> beschrieben.

Realzeit wurde nicht gefordert. Mag auch sein, dass es wirklich FPGAs 
braucht, aber nur um Daten von A nach B zu schaufeln gibt es fertige 
Lösungen. Selbst mit FPGA gibt es fertige Lösungen. Das ist alles 
deutlich günstiger wie eine Eigenentwicklung.

von FPGA (Gast)


Lesenswert?

Danke für die vielen Antworten

Nun zu Aufgabenstellung 1:
Es geht um IO Erweiterung, also einen HauptFPGA hat einige seiner IOs 
ausgelagert. Aus EMV Gründen -> LWL
Latenz kritisch. bis zu 150 Signale, um jitter gering zu halten mit 
relativ hoher Updategeschwindigkeit >20MHz ==> einige GBit/s

Aufgabenstellung 2:
Nun der HauptFPGA soll mit dem PC kommunizieren. Wie ist eigentlich 
egal. Sollte jedoch LWL sein. Von mir aus auch PCI-E über LWL oder USB 
über LWL oder was auch immer. Leider ist ETH das einzige was ich kenne, 
das LWL ist und bis in den GBaud Bereich geht. Daher die ETH Idee.

FPGA Board ist noch nicht evaluiert. Das ganze ist Netzbetrieben -> 
Stromverbrauch nicht spezifiziert. Im Blick ist aktuell der Cyclone 10 
GX

von FPGA (Gast)


Lesenswert?

Noch vergessen: Aufgabenstellung 2 ist nicht latenz kritisch, einige 
100mbit/s genügen ebenfalls.

von Gustl B. (-gb-)


Lesenswert?

FPGA schrieb im Beitrag #6444908:
> FPGA Board ist noch nicht evaluiert.

OK, welche Hardware gibt es doch schon und ist fest gesetzt, darf also 
nicht ausgetauscht werden?

FPGA schrieb im Beitrag #6444908:
> der HauptFPGA

Gibt es den schon mit Platine? Hat der schon den LWL Anschluss oder 
welche Anschlüsse hat die Platine für Erweiterungen?

von FPGA (Gast)


Lesenswert?

Gustl B. schrieb:
> OK, welche Hardware gibt es doch schon und ist fest gesetzt, darf also
> nicht ausgetauscht werden?

HW Gibts aktuell noch keine.

Ein paar Details worums im grossen geht:
Eine Steuerung mit total ca. 600 (low speed) LWL I/O, welche zwingend im 
FPGA verarbeitet werden müssen. Daneben existieren noch etliche PLC I/O 
sowie entsprechend von anderen Herstellern Netzwerkgebundene Daten, 
welche von einem PC bearbeitet werden. Diese sind nicht delaykritisch, 
die Daten müssen jedoch dem FPGA zur verfügung stehen. Desshalb wird 
eine Kommunikation FPGA-PC benötigt.

Da eine einzige Platine mit 600 LWL I/O sinnbefreit wäre(!) und die LWLs 
nur relativ low speed sind, ist eine IO Erweiterung geplant. Diese 
verschiedenen Board, sollten bestenfalls über ein identisches Layout 
verfügen. Die gesamte logik würde dann einfachheitshalber im HauptFPGA 
sein, und die anderen Platinen sind nur erweiterungs I/O.

Anyway lange story kurz: es geht um die LWL Schnittstellen FPGA-PC sowie 
FPGA-FPGA mit den bereits beschriebenen Eigenschaften

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


Lesenswert?

Kannst du vielleicht noch die maximale Datenrate pro LWL spezifizieren? 
Zwischen 1 und 10 Gbps (und so interpretiere ich jetzt mal "mehrere") 
liegen in der Regel die harten Grenzen, vor allem bei den kleinen FPGAs.

Und ich nehme mal an, dass auch gilt: Je mehr LWL pro FPGA angeschlossen 
werden koennen, desto besser?

von Gustl B. (gustl_b)


Lesenswert?

FPGA schrieb im Beitrag #6445278:
> ca. 600 (low speed) LWL I/O

FPGA schrieb im Beitrag #6445278:
> LWLs nur relativ low speed

Was denn konkret?

FPGA schrieb im Beitrag #6445278:
> etliche PLC I/O

Sehr unkonkret.

FPGA schrieb im Beitrag #6445278:
> entsprechend von anderen Herstellern Netzwerkgebundene Daten, welche von
> einem PC bearbeitet werden. Diese sind nicht delaykritisch, die Daten
> müssen jedoch dem FPGA zur verfügung stehen.

Welche Datenrate? Wieder sehr unkonkret.

FPGA schrieb im Beitrag #6445278:
> es geht um die LWL Schnittstellen FPGA-PC sowie FPGA-FPGA mit den
> bereits beschriebenen Eigenschaften

Verstehe ich nicht warum.

Du könntest ein FPGA Board nehmen mit PCIe, dickem FPGA und ordentlich 
Erweiterungsmöglichkeiten. Das steckst du in den PC. Damit kannst du 
problemlos Daten zwischen PC und FPGA austauschen.
Und dann schließt du an dieses FPGA Board noch mehrere IO Platinen für 
die vielen LWLs an. Aber die kannst du auch elektrisch mit dem FPGA 
Board verbinden, es gibt FMC. Je nach Datenrate der LWLs reichen 
vielleicht schon die FPGA IOs direkt aus über mehrere FMCs. Der FMC HPC 
kann 400 IOs.
Sonst gibt es IO Expander oder man könnte kleine FPGAs auf die IO Karten 
setzen die dann seriell mit dem HauptFPGA reden.

Und wenn die IOs eines FPGAs nicht reichen, dann kannst du in einen PC 
auch mehrere FPGA Steckkarten stecken. Da bekommst du locker deine 600+ 
IOs. Die können schnell miteinander reden, ins RAM vom Rechner 
schreiben, ...

Aber du kannst auch eine externe Platine nehmen mit schnellem LWL zum PC 
und vielen IOs für die langsamen LWLs. Im PC dann eine LWL Netzwerkkarte 
von der Stange.

von FPGA (Gast)


Lesenswert?

Gustl B. schrieb:
> Was denn konkret?

FPGA schrieb im Beitrag #6444908:
> Latenz kritisch. bis zu 150 Signale, um jitter gering zu halten mit
> relativ hoher Updategeschwindigkeit >20MHz ==> einige GBit/s

Wie bereits beschrieben. min 20MHz sampling rate, 150 LWL pro Board als 
Startgrösse.

Gustl B. schrieb:
> Sehr unkonkret.

Die PLC Daten sind hier auch grösstenteils orthogonal zu dieser 
Diskussion.

Gustl B. schrieb:
> Damit kannst du
> problemlos Daten zwischen PC und FPGA austauschen.

Ok, super, danke, so gehts eigentlich auch. Und würde die PC-FPGA 
Problematik komplett lösen. Kannst du bitte kurz die problemlose:

- Treiber mit DMA für Windows/Linux
- IP Core welcher die Daten in einem vom usercode zugreifbaren BRAM 
abspeichert (z.b. mit 512 64 bit Sendeadressen und 512 64 bit 
Empfangsadressen welche, der IPcore/Treiber ständig mit dem PC Ram 
abgleichen)

der Algemeinheit verfügbar machen?

Eigentlich ist es angedacht, das FPGA Board ausserhalb des PCs zu 
platzieren. Wie sieht es bezüglich des PCI-E und aus dem Rechner 
rausführen. Existieren Signalbufferkabel? Gar LWL konverterter?

von FPGA (Gast)


Lesenswert?

Tobias B. schrieb:
> Kannst du vielleicht noch die maximale Datenrate pro LWL spezifizieren?
> Zwischen 1 und 10 Gbps (und so interpretiere ich jetzt mal "mehrere")
> liegen in der Regel die harten Grenzen, vor allem bei den kleinen FPGAs.

bis zu 150 Signale, um jitter gering zu halten mit relativ hoher 
Updategeschwindigkeit >20MHz ==> einige GBit/s
in dem bsp. wärens min 3GBit/s. Anyway wenns mehr als 20MHz drinn liegen 
ist dies auch super.


Tobias B. schrieb:
> Und ich nehme mal an, dass auch gilt: Je mehr LWL pro FPGA angeschlossen
> werden koennen, desto besser?

Nicht unbedingt, da das Board dann auch entsprechend gross würde, einge 
geschickte balance zwischen Grösse/Anzahl boards wird angestrebt. Mit 
150 LWL pro Board ist eher das obere Anzahl LWL limit bezogen der 
Sinnvolligkeit erreicht.

von Gustl B. (-gb-)


Lesenswert?

FPGA schrieb im Beitrag #6445935:
> Und würde die PC-FPGA
> Problematik komplett lösen. Kannst du bitte kurz die problemlose:
>
> - Treiber mit DMA für Windows/Linux
> - IP Core welcher die Daten in einem vom usercode zugreifbaren BRAM
> abspeichert (z.b. mit 512 64 bit Sendeadressen und 512 64 bit
> Empfangsadressen welche, der IPcore/Treiber ständig mit dem PC Ram
> abgleichen)
>
> der Algemeinheit verfügbar machen?

Warum ich? Sowas gibt es von den FPGA(Board) Herstellern.
Such doch einfach mal bei Google, ich habe hier in sehr kurzer Zeit 
schon mal https://www.xilinx.com/support/answers/65444.html gefunden.

FPGA schrieb im Beitrag #6445935:
> Wie sieht es bezüglich des PCI-E und aus dem Rechner
> rausführen. Existieren Signalbufferkabel? Gar LWL konverterter?

Gibt es ebenfalls. Und zwar von Thunderbolt3 über 
https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=67&No=1143 
bis zu 
https://www.telexsus.com/products/lecroy/pcie-external-cable-30-to-pcie-slot-adapter 
.

FPGA schrieb im Beitrag #6445935:
> Wie bereits beschrieben. min 20MHz sampling rate, 150 LWL pro Board als
> Startgrösse.

Gut, muss die komplette Datenmenge "nur" in das HauptFPGA oder auch in 
den PC? Also welche Datenrate muss zwischen FPGA und PC erreicht werden?

20 MHz ist für einen FPGA IO eher gemütlich. Nur die Anzahl der IOs die 
du brauchst zwingt dich vermutlich zu Zusatzhardware, diesen IO Karten 
mit eigenem FPGA. Ist aber machbar. Mehrere IO Karten und die übertragen 
die Daten auf wenigen IOs schnell zum HauptFPGA. Muss kein LWL sein, 
kann aber.

von Christoph Z. (christophz)


Lesenswert?

FPGA schrieb im Beitrag #6435398:
> 1. FPGA-FPGA link über LWL zb mittels FTLX8574D3BCL benötigt hierbei
> werden einige gbps.

FPGA schrieb im Beitrag #6445935:
> FPGA schrieb im Beitrag #6444908:
>> Latenz kritisch. bis zu 150 Signale, um jitter gering zu halten mit
>> relativ hoher Updategeschwindigkeit >20MHz ==> einige GBit/s
>
> Wie bereits beschrieben. min 20MHz sampling rate, 150 LWL pro Board als
> Startgrösse.

Ach so, darum hast du ein 10 Gbit/s SFP+ Modul (FTLX8574D3BCL) als 
Ansatz.
Dieses benötigt auch >10 Gbit/s Transceiver im FPGA. Also zum Beispiel 
bei Xilinx Kintex-7 oder neuer.

Entsprechend solltest du / eure Firma auch fit sein mit High-Speed 
Leiterplatten und entsprechender Messtechnik (> 40 GHz).

Ich würd mal ganz genau über die >20 MHz Updategeschwindigkeit 
nachdenken. Das ist sehr hoch und in den meisten Umgebungen unnötig, 
weil es muss in kurzer Zeit auf etwas reagiert werden, aber dieses etwas 
kommt nicht mit 20 MHz vorbei. Durch Synchronisation der Systeme lässt 
sich der Jitter drücken ohne so hohe Updateraten.

von FPGA (Gast)


Lesenswert?

Christoph Z. schrieb:
> Ach so, darum hast du ein 10 Gbit/s SFP+ Modul (FTLX8574D3BCL) als
> Ansatz.
> Dieses benötigt auch >10 Gbit/s Transceiver im FPGA.

Wieso? Die AC Kopplung des SFP+ Modules sollte doch bis auf wenige MHz 
oder gar kHz runtergehen. Daher sollten doch auch unter 1Gbit/s bei 
diesem Modul unproblematisch sein?

Christoph Z. schrieb:
> Ich würd mal ganz genau über die >20 MHz Updategeschwindigkeit
> nachdenken. Das ist sehr hoch und in den meisten Umgebungen unnötig,
> weil es muss in kurzer Zeit auf etwas reagiert werden, aber dieses etwas
> kommt nicht mit 20 MHz vorbei. Durch Synchronisation der Systeme lässt
> sich der Jitter drücken ohne so hohe Updateraten.

Ja existieren sicherlich Tricks, anyway der Ansatz: am Einfachsten man 
hat generell die benötigte Updategeschwindigkeit dann kommen weitere 
Probleme/Themen nicht mal zum Vorschein. Aber Danke für den Hinweis.

Gustl B. schrieb:
> Gut, muss die komplette Datenmenge "nur" in das HauptFPGA oder auch in
> den PC?

Nur in das HauptFPGA. Wie gesagt alle anderen über LWL verbundenen 
Boards dienen nur der I/O Erweiterung.

Gustl B. schrieb:
> Gibt es ebenfalls. Und zwar von Thunderbolt3 über
> 
https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=67&No=1143
> bis zu
> 
https://www.telexsus.com/products/lecroy/pcie-external-cable-30-to-pcie-slot-adapter
> .

Hmm.. Diese sind zwar Kabelanbindung an PCI-E aber nicht LWL. Dennoch 
interessant.

Gustl B. schrieb:
> Warum ich? Sowas gibt es von den FPGA(Board) Herstellern.
> Such doch einfach mal bei Google, ich habe hier in sehr kurzer Zeit
> schon mal https://www.xilinx.com/support/answers/65444.html gefunden.

Nun eben nicht, oder zumindest nicht beim Cyclone 10 GX das einfach 
funktioniert. Habe bei Intel mal die das PCI-E Design runtergeladen, 
dieses nutz lediglich einen IP Block mit Avalon Stream output.
Sicherlich wird dieser irgendwie funktionieren; anyway für mein 
grundlegende und allgemeine Aufgabenstellung:

PC Treiber mit DMA <---> FPGA dual port BRAM

synchronisation kaum verwendbar.

Nun es wird lediglich eine einfache (die einfachste art der 
Kommunikation die mir in den Sinn kommt) Signallistenbasierte 
kommunikation benötigt.

von Gustl B. (-gb-)


Lesenswert?

FPGA schrieb im Beitrag #6452388:
> Nur in das HauptFPGA. Wie gesagt alle anderen über LWL verbundenen
> Boards dienen nur der I/O Erweiterung.

Ich verstehe ja, dass du viele IOs benötigst und da Erweiterungsplatinen 
planst. Aber warum soll die Verbindung zwischen Erweiterungsplatine und 
HauptFPGA Platine über LWL laufen und nicht elektrisch?

FPGA schrieb im Beitrag #6452388:
> Hmm.. Diese sind zwar Kabelanbindung an PCI-E aber nicht LWL. Dennoch
> interessant.

Genauso hier, warum sollen PC und HauptFPGA über LWL verbunden werden? 
Man könnte die Platine mit HauptFPGA doch auch mit PCIe ausstatten und 
in den PC reinstecken.

FPGA schrieb im Beitrag #6452388:
> PC Treiber mit DMA <---> FPGA dual port BRAM

Ich habe noch nie PCIe mit FPGA gemacht, aber diese Aufgabenstellung 
sieht mir so aus als wäre die durchaus nicht unüblich und bereits ein 
gelöstes Problem.
Mit welcher Datenrate müssen denn HauptFPGA und PC kommunizieren? Es 
gibt ja auch normales Ethernet, USB3, ...

von FPGA (Gast)


Lesenswert?

Gustl B. schrieb:
> Ich verstehe ja, dass du viele IOs benötigst und da Erweiterungsplatinen
> planst. Aber warum soll die Verbindung zwischen Erweiterungsplatine und
> HauptFPGA Platine über LWL laufen und nicht elektrisch?

EMV

Gustl B. schrieb:
> Genauso hier, warum sollen PC und HauptFPGA über LWL verbunden werden?
> Man könnte die Platine mit HauptFPGA doch auch mit PCIe ausstatten und
> in den PC reinstecken.

Dies ist weniger kritisch da diese gleich nebeneinander aufgebaut werden 
können. Von dem her ja: muss nicht zwingend LWL. (Anyway da wir generell 
eine EMV Panik haben, ist auch hier LWL bevorzugt).

Gustl B. schrieb:
> Ich habe noch nie PCIe mit FPGA gemacht, aber diese Aufgabenstellung
> sieht mir so aus als wäre die durchaus nicht unüblich und bereits ein
> gelöstes Problem.

Genau meine Vorstellung; das PC-FPGA Kommunikationsthema sollte ein 
gelöstes Problem sein, und jede minute in dieses Problem investiert ist 
eigentlich verschwendete Zeit.

Wenige 100mbit/s genügen. ETH hätte sogar einen LWL standard, PCI-E ist 
auch ok. Eigentlich egal wie, einfach eine einfache Lösung ab der 
Stange.

Also: ETH oder PCI-E für dummies. Ein Bsp. das geht, und fertig - 
nächstes Problem. Es ist absolut Schade das die Lösung für dieses 
gelöste Standartproblem, nicht einfach zur verfügung steht. Und einem 
die Hersteller irgendwelche 1000+ Seitige Dokumentationen von 
irgendwelchen IPcores an den Kopf werfen wollen...

von Gustl B. (-gb-)


Lesenswert?

FPGA schrieb im Beitrag #6452424:
> EMV

OK, das kann ich verstehen.

FPGA schrieb im Beitrag #6452424:
> Wenige 100mbit/s genügen. ETH hätte sogar einen LWL standard, PCI-E ist
> auch ok. Eigentlich egal wie, einfach eine einfache Lösung ab der
> Stange.

Dann kannst du auch USB nehmen mit so einem FIFO Interface wie sie der 
FT2232H (USB2), FT600 (USB3) oder FX3 (USB3)bieten. Ist vielleicht 
einfacher wie Ethernet. Zumindest zum FT600 kann ich sagen dass man da 
mit sehr wenig Hardwarebeschreibung schnell Daten zum PC bekommt.

Es gibt auch Boards mit FPGA und USB3 wie dieses:
https://opalkelly.com/products/xem7360/
Das hat auch einigermaßen viele IOs für Erweiterungskarten. Das hier 
https://opalkelly.com/products/xem8350/ ist sogar noch dicker.

FPGA schrieb im Beitrag #6452424:
> Es ist absolut Schade das die Lösung für dieses
> gelöste Standartproblem, nicht einfach zur verfügung steht.

Naja, das gibt es schon, einfach weil das eben schon Leute verwenden.

https://opencores.org/projects/virtex7_pcie_dma
https://github.com/alexforencich/verilog-pcie

von FPGA (Gast)


Lesenswert?

Gustl B. schrieb:
> FT2232H (USB2),

Ja würde gehen und auch von der performance her genügen. Hmm USB hat 
eigentlich 3 Eigenschaften, wesshalb ichs eher gegenüber ETH und PCI-E 
zurückstellen würde:

1. Kein DMA (USB hat gute Gründe dafür kein DMA zu haben (sicherheit 
bez. unvertrauter HW etc.)) Anyway für diesen Anwendungsfall hat DMA 
offensichtlich Vorteile.
2. USB war/ist nicht für Industrie gedacht/vermarktet; subjektiv habe 
ich den Eindruck, dass die USB Akzeptanz in der Industrie nicht 
besonders hoch ist.
3. EMV anfällig

Gustl B. schrieb:
> Naja, das gibt es schon, einfach weil das eben schon Leute verwenden.
>
> https://opencores.org/projects/virtex7_pcie_dma
> https://github.com/alexforencich/verilog-pcie

Hmmpf... Danke... nun erscheint auch eher umfangreich, habs nur kurz 
überfolgen. Anyway vermisse eine Anleitung in der Art: 1. nehme diese 
files und 2. klicke hier und hier, und 3. instaliere diesen Treiber (für 
win/linux) und 4. nutze dieses Topfile sowie dieses C Source file als 
demo/test und fertig...

von Gustl B. (gustl_b)


Lesenswert?

FPGA schrieb im Beitrag #6452890:
> Hmm USB hat eigentlich 3 Eigenschaften, wesshalb ichs eher gegenüber ETH
> und PCI-E zurückstellen würde:

Hm, wenn dir USB2 sogar von der Geschwindigkeit reicht, dann ist das 
auch ohne DMA schnell genug.
Ich sehe bei den Lösungen mit USB wie diesen FTDI ICs, dass das einfach 
ist. Das ist wenig HDL und wenig C Code und schon funktioniert das. Kein 
aufwändiges Protokoll und man braucht auch keine teure IP oder Lizenzen 
von Herstellern.

Ich finde eine PCIe Lösung elegante weil das dann alles in einem PC 
wäre. Aber sonst bei den Datenraten kannst du auch normales Gigabit 
Ethernet nehmen.

FPGA schrieb im Beitrag #6452890:
> Anyway vermisse eine Anleitung in der Art:

Habe ich jetzt auch nicht gesehen, ich vermute aber, dass sowas in den 
Downloads drinnen ist. Bei Terasic kannst du dir zu jedem Board Zeug 
runterladen. Und da sollte sowas mit dabei sein.

von OM7 (Gast)


Lesenswert?

FPGA schrieb im Beitrag #6452388:
> Christoph Z. schrieb:
>> Ach so, darum hast du ein 10 Gbit/s SFP+ Modul (FTLX8574D3BCL) als
>> Ansatz.
>> Dieses benötigt auch >10 Gbit/s Transceiver im FPGA.
>
> Wieso? Die AC Kopplung des SFP+ Modules sollte doch bis auf wenige MHz
> oder gar kHz runtergehen. Daher sollten doch auch unter 1Gbit/s bei
> diesem Modul unproblematisch sein?

"Supports 9.95 to 10.5 Gb/s bitrates*"

Bei anderen Modulen werden auch 1Gb/s oder 4Gb/s(FC) garantiert.

von FPGA (Gast)


Lesenswert?

OM7 schrieb:
> "Supports 9.95 to 10.5 Gb/s bitrates*"
>
> Bei anderen Modulen werden auch 1Gb/s oder 4Gb/s(FC) garantiert.

Ooops, Danke!

von FPGA (Gast)


Lesenswert?

Gustl B. schrieb:
> Ich finde eine PCIe Lösung elegante weil das dann alles in einem PC
> wäre. Aber sonst bei den Datenraten kannst du auch normales Gigabit
> Ethernet nehmen

Nun GBE (LWL) ist mir eigentlich fast am liebsten. Wenn mäglich am 
besten noch ohne PHY etc. Also direkt FPGA-LWL Modul.

Existieren für GBE entsprechende (einfache) BSP?

von FPGA (Gast)


Lesenswert?

OT: Ist mir gerade aufgefallen, dass der 10CX105 12 Transceiver hat mit 
12.5 gbaud. Diese können anscheinend direkt XGMII ausgeben. Und das mit 
einem FPGA für 100 Eur! Nun da diese direkt zu den SFP+ Modulen 
verbunden werden können, könnte damit ein 12Port 10G Switch gebaut 
werden. Zum Bruchteil des Marktpreises.

von Gustl B. (-gb-)


Lesenswert?

FPGA schrieb im Beitrag #6453594:
> Nun da diese direkt zu den SFP+ Modulen
> verbunden werden können, könnte damit ein 12Port 10G Switch gebaut
> werden. Zum Bruchteil des Marktpreises.

Für < 500 €? Mit Platine, anderen Bauteilen, Gehäuse, Entwicklung, 
Zertifizierung, Support, Handbuch, Software, ...? Sportlich.

von FPGA (Gast)


Lesenswert?

http://www.xillybus.com/ scheint eine IP zu haben welche angeblich genau 
eine einfache Anbindung des FPGAs mit dem Rechner ermöglicht. Nun es 
beunruhigt mich, dass Sie für eine solche standard Anwendung zwischen 
25-85k USD haben möchten.

Anscheinend wird dieses basic Problem einfach von den grossen 
Herstellern ignoriert, dass irgendwelche nischenanbieter IP anbieten 
müssen...

Nun zu meiner recherche bez. Cyclone 10 GX: Intel bietet irgendwelche 
generatoren die PCI-E- Avalon machen.

Dann gibts irgendwelche generatoren bez Avalon anbindung und 1000ende 
Seiten Avalon Doku. Von Bsp wie ich aus dem Avalon zeugs einige FiFo 
oder MM lesen zu meiner Logik verbinden kann ist auch nix vorhanden. PC 
seitig fehlt auch alles... Intel scheint die Kunden komplett im Regen zu 
lassen..

von Markus (Gast)


Lesenswert?

Vor Jahren habe ich mal auf der Embedded World Conference einige 
Vorträge über eine Lösung zu sowas gehört, kann mich aber an den Namen 
nicht erinnern. Eins war eine Art PCI über TCP (war von Fraunhofer, 
glaube ich), das andere ein RPC von einer Schweizer Firma. Sollte open 
source gewesen sein. Müßte ich aber suchen.

von C. A. Rotwang (Gast)


Lesenswert?

FPGA schrieb im Beitrag #6435398:
> Angedacht habe ich Cyclone oder Spartan, aber evtl. würde insbesondere
> für Punkt

Hard oder Soft-IP?

Es gibt FPGA's mit fest eingebauten MAC und/oder PCIe Core, das sind 
wohl beim Spartan-6 die T-Typen und die Kintex-7.

Einfach mal in die Übersichtstabellen nach "Embedded Hard IP" oder 
"Integrated IP" schauen:

https://www.xilinx.com/support/documentation/selection-guides/7-series-product-selection-guide.pdf

https://www.intel.co.uk/content/dam/www/programmable/us/en/pdfs/literature/br/br-soc-fpga.pdf 
S.9

von Gustl B. (-gb-)


Lesenswert?

C. A. Rotwang schrieb:
> oder PCIe Core

Ja das weiß er schon, was er sucht ist eine einfache Lösung wie man dann 
auch Daten über z. B. PCIe zwischen FPGA und PC - wenn möglich mit DMA 
ins PC RAM - austauscht.

von FPGA (Gast)


Lesenswert?

Gustl B. schrieb:
> Ja das weiß er schon, was er sucht ist eine einfache Lösung wie man dann
> auch Daten über z. B. PCIe zwischen FPGA und PC - wenn möglich mit DMA
> ins PC RAM - austauscht.

Genau, einfach und bevorzugt frei verfügbare IP. Ich finde die Karikatur 
auf: 
http://www.xillybus.com/tutorials/pci-express-tlp-pcie-primer-tutorial-guide-1 
ziemlich passend. "We always end up spending lots of work on data 
transfer". Nun dies beschreibt exakt meine Vorstellung, es gibt genug 
arbeit an eigener Logik, daher keine Zeit Verschwenden an basics und das 
Rad nicht jedesmal neu erfinden.
Cyclone 10 GX hat entsprechende Hard IP. Und ebenfalls gratis IP 
generatoren für PCI-e - Avalon und ebenfalls eigener Logik - Avalon.
Nun ich kenne mich damit nicht aus, evtl. ist es auch ganz einfach und 
könnte mit wenigen cklicks realisiert werden. Nur schwimme ich, und die 
Informationsstrukturierung/Kommunikation der Hersteller diesbezüglich 
ist frustrierend.
Wenn sich jemand damit auskennt, kann er mir und der algemeinheit bitte 
kurz ein Projekt erstellen mit dem PCI-e- Avalon core, sowie mit Avalon 
zu eigener Logik (genügt Fifo mit clk, data, wr_en, full/empty; noch 
besser Bram Memory mapped)

von Jonas (Gast)


Lesenswert?

Vielleicht mal als Referenzwert: Wir nutzen für Echtzeitregelungssysteme 
derzeit 10 GbE mit DPDK (Data Plane Development Kit) oder XDP (eXtreme 
Data Path +eBPF, Linux). Die Latenz von Host-Rechner bis zum Kabel ist 
bei kleinen Paketen  (~120 B) 5 us und bei Jumbo Frames (~8 KiB) 13 us. 
Von den möglichen 10 Gb/s nutzen wir im Schnitt ca. 6 Gb/s. Der Jitter 
vom Paket-Anfang ist ca. 0.01 us Standardabweichung.
Demnächst steigen wir auf 100 GbE um, um die Serialisierungszeit der 
Jumbo Frames zu reduzieren (0.7 us statt 7 us; macht bei ein paar 
switches schon was aus; switch selbst braucht ~0.9 us). COTS HW: NICs 
von Intel oder Mellanox, Server von Dell mit AMD EPYC (ggf. mehrere) und 
PCIe3 oder PCIe4.

Trotzdem kann es einige Gründe geben, die für eine FPGA-Verwendung 
sprechen. Beispielsweise komplizierte Messwerterfassung/ADCs/..., 
Strombedarf und Abwärme,  Latenz << 1 us, Jitter, ...
Wir haben hier einige Geräte, die mit dem FPGA die Messwerte nach 10 GbE 
Ethernet übersetzen. Aber die weitere latenzkritische 
Auswertung/Regelung findet dann über einen oder mehrere fetten Server 
mit DPDK bzw. XDP statt, von wo die Steuerbefehle dann an die Aktoren 
gehen.

von Gustl B. (-gb-)


Lesenswert?

Vielleicht mal ne dumme Laienfrage:

Viele FPGAs haben ja PCIe eingebaut. PCs haben ebenfalls PCIe. Das kann 
man jetzt schön elektrisch verbinden.
Gibt es eine Möglichkeit das PCIe zwischen FPGA und PC auch optisch zu 
machen? Ich stelle mir das so vor:

FPGA <-> Adapter <-> LWL <-> Adapter <-> PCIe-Steckplatz im PC.
Wobei Adapter nur etwas "einfaches" ist vom Prinzip her wie ein QSFP, 
aber kein extra FPGA.

Was ich gesehen habe ist

FPGA <-> 10 GbE <-> LWL <-> 10 GbE <-> FPGA/NIC <-> PCIe-Steckplatz im 
PC.

und ich verstehe nicht wirklich wieso man da den Umweg über Ethernet und 
einen zweiten FPGA/NIC geht. Das sollte doch möglich sein ein PCIe mit 
mehreren Lanes auf unterschiedliche Farben in einer Faser zu packen und 
zwar ohne dicken Zusatzchip. Gibt es dafür Lösungen?

von Tim (Gast)


Lesenswert?

Gustl B. schrieb:
> und ich verstehe nicht wirklich wieso man da den Umweg über Ethernet und
> einen zweiten FPGA/NIC geht.

1. (mögl.) Grund: Ethernet ist dezentral. PCIe hat eine Host-Slave 
Architektur.

2. Grund: Die Datenrate bei PCIe sinkt mit der Entfernung

Ansonsten gibt es Anbieter für LWL-PCIe. Für 2m ganz nett.

von Duke Scarring (Gast)


Lesenswert?

Gustl B. schrieb:
> Gibt es eine Möglichkeit das PCIe zwischen FPGA und PC auch optisch zu
> machen?
Ja. Ich habe hier ein System, wo ein PCIe-Switch über 20m optisches 
Kabel am PC (PCIe-Karte) angebunden ist. Am (externen) Switch hängen 
dann die FPGAs.

Duke

von Gustl B. (-gb-)


Lesenswert?

Duke Scarring schrieb:
> am PC (PCIe-Karte) angebunden ist

Kannst du sagen was das für eine Karte ist? Was ist da drauf?

von Duke Scarring (Gast)


Lesenswert?

Gustl B. schrieb:
> Kannst du sagen was das für eine Karte ist?
Die Karte nennt sich NPCIe-Uplink-O-x8.
Einzeln gibt es die Karte offensichtlich nicht, nur optional im 
Zusammenhang mit einem NAT-MCH-PHYS80.

> Was ist da drauf?
Im Wesentlichen 2x QSFP und ein PCI Express Switch von
PLX/Avago/Broadcom:
https://www.broadcom.com/products/pcie-switches-bridges/pcie-switches

Duke

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]
  • [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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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