Announcement: there is an English version of this forum on Hallo zusammen, ich habe bereits einige Erfahrungen mit FPGAs, allerdings noch nie mit PCIe oder LVDS gearbeitet. Für ein zukünftiges Projekt könnte ein FPGA (möglicherweise von Actel, Xilinx oder Altera) mit PCIe-Unterstützung zum Einsatz kommen. Daher habe ich ein paar Fragen an die Experten, die mit diesen Technologien vertraut sind. :) Das Ziel ist es, einen PC (Host) über PCIe mit einem FPGA zu verbinden. Dabei möchte ich mich vorerst nicht mit der spezifischen Anwendung oder dem Einsatzzweck befassen, sondern vielmehr mit den technischen Aspekten der FPGA-Integration. Hier ein paar Unklarheiten, die ich gerne klären würde: PCIe (Slave) IP-Cores: Welche Lizenzgebühren fallen in der Regel für die Nutzung von PCIe-Slave-IP-Cores an? Gibt es hierzu grobe Preisangaben? Host-Seite (Linux): Auf der Host-Seite muss natürlich ein Treiber existieren. Ich nehme an, dass hier eine Art Memory-Mapping erforderlich ist, um Register auf der FPGA-Seite zu lesen oder zu schreiben. Könnte mir jemand den allgemeinen Ablauf oder die typische Vorgehensweise erklären? Slave-Seite (FPGA): Benötigt man hier zwingend einen Soft-Core-Prozessor (z.B. MicroBlaze oder Nios II) samt Betriebssystem, um mit dem PCIe-Slave zu kommunizieren, oder ist es auch möglich, eine eigene Verilog-Beschreibung zu implementieren, die zum Beispiel ein Register-File abfragt und bestimmte Ereignisse direkt auslöst? Ich freue mich auf eure Antworten :)
Moin, Vor vielleicht 15 Jahren hab' ich sowas mal angefangen, damals auf einem Spartan6. Das wurde dann aber leider durch Scheffs gecanceled, war aber doch ne interessante Kiste. Hier, an was ich mich noch erinnere: * Der PCIe-Core hat iirc nix gekostet. * Auf der PC-Seite taucht das PCIe gedoens "memory-mapped" auf. Treiber ist halt dann das uebliche bei Linux. * Im FPGA braucht man keinen µController. Ich hatte damals was gebaut, was "einfach" DDR2(?)-RAM, was extern am Spartan6 hing, zum PC "durchreichte". Was am Anfang etwas genervt hatte: Wenn man das FPGA-Design via JTAG neu geladen hatte, dann erschien das erstmal nicht mehr auf der PC Seite - gab aber irgendeinen ziemlich simplen Kniff, wie man das fixen konnte - koennte irgendsowas von dem Kaliber echo 1>/sys/gedoens/.../ gewesen sein. Gruss WK
Dergute W. schrieb: > Wenn man das FPGA-Design via JTAG neu > geladen hatte, dann erschien das erstmal nicht mehr auf der PC Seite Dazu kommt noch: Wenn der Host-PC hochgefahren wird, startet recht zeitig die PCIe-Arbitrierung. Falls ein größeres FPGA zum Einsatz kommt - und bei PCIe will man i.d.R. ein größeres FPGA nutzen - kann es sein, das das FPGA zu diesem Zeitpunkt noch nicht fertig konfiguriert ist. Die Empfehlung der Kollegen lautete: einen passenden PCIe-Bridge-Chip zwischen FPGA und PCIe-Bus zu setzen. Ich würde mir auch die Referenzdesigns der FPGA-Hersteller näher anschauen.
Für das rechtzeitig zur Verfügung stehen des FPGAs gibts verschiedene Ansätze. Zum einen nutzt man einen möglichst schnellen Konfigurationsspeicher. Das kann z.B. auch bedeuten, daß man mittels CPLD oder Hilfs-FPGA aus mehreren QSPI-Flashes das FPGA im 32-Bit Select-Map-Mode mit der maximal möglichen Taktrate konfiguriert. Und dann gibt es noch die Möglichkeit der partiellen Konfiguration/Rekonfigutration. Da wird in sehr kurzer Zeit aus einem seriellen (z.B. QSPI) Flash erst nur der PCIe-Kern konfiguriert, der für die Bus-Enumeration grbraucht wird. Danach kommt dann der eigentliche große Bitstream, der per partieller Rekonfiguration den Rest des FPGAs konfiguriert und dafür jetzt entspannt Zeit hat.
:
Bearbeitet durch User
Ok, das sind ja nun Probleme an die ich garnicht gedacht habe. Beim Actel sind doch die FLashes im FPGA integriert. Läd dieser auch die Konfiguration schneller als das beim Xilinx/Altera mit externem EEPROM der fall ist?
Eho C. schrieb: > Hier ein paar Unklarheiten, die ich gerne klären würde: > > PCIe (Slave) IP-Cores: Welche Lizenzgebühren fallen in der Regel für > die Nutzung von PCIe-Slave-IP-Cores an? Gibt es hierzu grobe > Preisangaben? > Nein. Gibt alles von gratis bis richtig toll um 18k, je nach Speed und Architektur. Ohne Randbedingungen laesst sich das schwer sagen, aber man kann typischerweise mit der Gratisloesung/Refdesign anfangen. > Host-Seite (Linux): Auf der Host-Seite muss natürlich ein Treiber > existieren. Ich nehme an, dass hier eine Art Memory-Mapping erforderlich > ist, um Register auf der FPGA-Seite zu lesen oder zu schreiben. Könnte > mir jemand den allgemeinen Ablauf oder die typische Vorgehensweise > erklären? > Kommt darauf an, wie der Datenfluss vonstatten gehen soll. Einzelne Register-Configs geschehen klassisch per ioctl()-Mapping von Userspace auf die PCI-Adresse, man kann aber auch Kernel memory mappen und einen Block per DMA dann auf den PCI pusten. Wenn es sehr viele Register sind, machen die ioctl()-Wrapper allenfalls Arbeit, oder man setzt etwas Framework zum Generieren ein. Fuers Prototyping kann man auch alles auf einen "unsicheren" Daemon auslagern, der die Register ueber wenige generische ioctl() konfiguriert, wie es Wifi macht. > Slave-Seite (FPGA): Benötigt man hier zwingend einen > Soft-Core-Prozessor (z.B. MicroBlaze oder Nios II) samt Betriebssystem, > um mit dem PCIe-Slave zu kommunizieren, oder ist es auch möglich, eine > eigene Verilog-Beschreibung zu implementieren, die zum Beispiel ein > Register-File abfragt und bestimmte Ereignisse direkt auslöst? > Du brauchst nur einen ganz einfachen Bus-Decoder, den du bei vielen SoC-Buildern typischerweise (aus einer XML-Beschreibung) generierst und an deinen AHB/AXI/Wishbone Bus dranflanschst. Lattice hat z.B. fertige Referenzdesigns von PCIe nach Wishbone. Das ist also eher Push als Pull. Ein eingebetteter CPU-Core macht nur Sinn, wenn es komplexere ansynchrone Sachen sind, wie Bus-Wrapper von PCI auf TCP, wo eine entsprechende Statemachine nicht mehr simpel wäre.
Moin, Rick D. schrieb: > Dazu kommt noch: Wenn der Host-PC hochgefahren wird, startet recht > zeitig die PCIe-Arbitrierung. Ha - stimmt, da war auch was. Da bei mir das Dingens aber als Produkt eh nicht an einem PC haengen sollte, sondern am PCIe eines SoCs war bei mir recht frueh klar, dass ich da keine Probleme kriegen wuerde. Deshalb hatte ich's schnell ausgeblendet. Entsinne mich aber jetzt wieder, dass es damals auch schon FPGAs gab, die das irgendwie (schnelle Config des PCIe Parts nach Poweron,...) beruecksichtigen konnten/sollten. Rick D. schrieb: > Die Empfehlung der Kollegen lautete: einen passenden PCIe-Bridge-Chip > zwischen FPGA und PCIe-Bus zu setzen. Wie kann der das denn nennenswert verzoegern? Rick D. schrieb: > Ich würde mir auch die Referenzdesigns der FPGA-Hersteller näher > anschauen. Yup. Das hatte ich genauso gemacht. Muesste auf einem SP605 Evalboard gewesen sein. Die hatten da iirc ein angenehm simples Beispieldesign. Gruss WK
Eho C. schrieb: > Host-Seite (Linux): Auf der Host-Seite muss natürlich ein Treiber > existieren. Ich nehme an, dass hier eine Art Memory-Mapping erforderlich > ist, um Register auf der FPGA-Seite zu lesen oder zu schreiben. Könnte > mir jemand den allgemeinen Ablauf oder die typische Vorgehensweise > erklären? Ja wird über Memory Mapping gemacht. Für den Anfang ist es am einfachsten, wenn Du Dir dafür mal das uio Framework im Linux Kernel anschaust. Das ist dafür gemacht, herstellerspezifische Hardware einfach in den Linux Kernel einbinden zu können. (Und um auch Lizenzthematiken abzubilden) Der "Treiber" besteht dabei aus zwei Teilen: dem uio modul welches im wesentlich das Memory Mapping steuert und evetuell Interrupte behandelt und einem Treiber/Software etc. welche im Userspace läuft: https://www.kernel.org/doc/html/latest/driver-api/uio-howto.html Es gibt einen bereits fertigen "generischen" uio Treiber mit dem du im Prinzip alles in den userspace mappen kannst was du willst ohne den Kernel überhaupt anfassen zu müssen: https://www.kernel.org/doc/html/latest/driver-api/uio-howto.html#generic-pci-uio-driver Achja, und wundere dich nicht, Memory Mapped PCIe Lesezugriffe sind langsamer als Schreibzugriffe, macht sich insbesondere bei kleinen Blockgrößen bemerkbar. Für Durchsatz braucht man asynchrone DMA transfers.
>Nein. Gibt alles von gratis bis richtig toll um 18k, je nach Speed und >Architektur. Ohne Randbedingungen laesst sich das schwer sagen, aber man >kann typischerweise mit der Gratisloesung/Refdesign anfangen. Dann lege ich mal das constraint fest: PCIe Gen2 :)
Eho C. schrieb: > Dann lege ich mal das constraint fest: PCIe Gen2 :) Xilinx (AMD) 7-Series >= Artix-7, haben mindestens einen [1] PCIe Gen2 hard-IP, der IPI block dazu kommt mit Vivado und braucht keine spezielle Lizenz. [1] Virtex-7 gibts auch mit Gen3 statt Gen2
Eho C. schrieb: >>Nein. Gibt alles von gratis bis richtig toll um 18k, je nach Speed und >>Architektur. Ohne Randbedingungen laesst sich das schwer sagen, aber man >>kann typischerweise mit der Gratisloesung/Refdesign anfangen. > > Dann lege ich mal das constraint fest: PCIe Gen2 :) Raspberry PI 4/5/CM4 ? Dann solltest Du zum Entwickeln vielleicht eine andere Plattform nehmen. Das PCIe des Pi scheint so einige Quirks zu haben, auf die Du vielleicht nicht stoßen möchtest, wenn Du noch nicht selber weißt, ob Deine Seite absolut korrekt arbeitet. Also besser eine PC-Plattform oder ein NVidia Jetson oder so. Schau mal ins Blog vom Jeff Geerling. fchk
>> Dann lege ich mal das constraint fest: PCIe Gen2 :) > >Xilinx (AMD) 7-Series >= Artix-7, haben mindestens einen [1] PCIe Gen2 >hard-IP, der IPI block dazu kommt mit Vivado und braucht keine spezielle >Lizenz. > >[1] Virtex-7 gibts auch mit Gen3 statt Gen2 Also Virtex sprengt ein bisschen meine preisliche Vorstellung. Ich denke da schon eher an so einem Low-Cost FPGA mit 60€ maximal. Der Artix 7 schaut ja wirklich richtig gut dagegen. Mit Low-Cost FPGA´s hatte ich bereits auch zutun und ich denke für meine nächste Anwendung dürften die Low-Cost FPGA´s allemal reichen,.. nur der PCIe muss noch mit rein :) >Dann solltest Du zum Entwickeln vielleicht eine andere Plattform nehmen. >Das PCIe des Pi scheint so einige Quirks zu haben, auf die Du vielleicht >nicht stoßen möchtest, wenn Du noch nicht selber weißt, ob Deine Seite >absolut korrekt arbeitet. Also besser eine PC-Plattform oder ein NVidia >Jetson oder so. Danke für den Hinweis.. also zum Entwickleln doch lieber nen PC-Mainboard nehmen und dann wenn alles funzt auf dem Pi4/5 testen?
Eho C. schrieb: >>Dann solltest Du zum Entwickeln vielleicht eine andere Plattform nehmen. >>Das PCIe des Pi scheint so einige Quirks zu haben, auf die Du vielleicht >>nicht stoßen möchtest, wenn Du noch nicht selber weißt, ob Deine Seite >>absolut korrekt arbeitet. Also besser eine PC-Plattform oder ein NVidia >>Jetson oder so. > Danke für den Hinweis.. also zum Entwickleln doch lieber nen > PC-Mainboard nehmen und dann wenn alles funzt auf dem Pi4/5 testen? Ja, zuerst PC, dann Pi5/CM5, und dann Pi4/CM4. In dieser Reihenfolge. fchk
:
Bearbeitet durch User
Eho C. schrieb: > Also Virtex sprengt ein bisschen meine preisliche Vorstellung. Ich > denke da schon eher an so einem Low-Cost FPGA mit 60€ maximal. Der > Artix 7 schaut ja wirklich richtig gut dagegen. Der Artix ist klein aber fein. Evtl. ist noch der XDMA/QDMA von interesse (open source treiber) wenn du direkt memory mapped Zugriffe willst und nicht selbst TLPs verarbeiten. https://www.xilinx.com/products/intellectual-property/pcie-dma.html https://www.amd.com/content/dam/xilinx/support/documents/ip_documentation/xdma/v4_1/pg195-pcie-dma.pdf
Dergute W. schrieb: > Rick D. schrieb: >> Die Empfehlung der Kollegen lautete: einen passenden PCIe-Bridge-Chip >> zwischen FPGA und PCIe-Bus zu setzen. > Wie kann der das denn nennenswert verzoegern? Die Brücke soll nicht verzögern, sondern sich selber am Bus melden. Damit hat man auch gleich eine gültige Vendor-ID und muß sich nicht bei PCI-SIG anmelden.
Moin, Nachdem ich mein gesamtes PCIe Knowhow hier schon offengelegt habe ;-) hoffe ich auf Verstaendnis fuer meine Frage/n. Rick D. schrieb: > Die Brücke soll nicht verzögern, sondern sich selber am Bus melden. Sagt dann die Bruecke dem PC nur: Ich bin eine Bruecke, weiss aber nicht, wer "am andern Ufer" an mir dranhaengt? Irgendwann muss das doch der PC wissen, wie's hinter der Bruecke weitergeht, haett ich ja jetzt gedacht... Gruss WK
Roger S. schrieb: > Xilinx (AMD) 7-Series >= Artix-7, haben mindestens einen [1] PCIe Gen2 > hard-IP, der IPI block dazu kommt mit Vivado und braucht keine spezielle > Lizenz. Für den Artix 7 gibt es sogar 3 unterschiedliche IP-Blöcke für PCIe, je nach Verwendung der bridge, modi und des gewünschten AXI-Systems, z.b. Art des DMS-Zugriffs. Habe ich vor einiger Zeit en detail durchgekaut. Gleiches nochmal für den Artix Ultrascale.
Wenn ich mich recht entsinne, habe ich mit dem ECP5-Versa-Kit locker die 2.5Gb/s timings hinbekommen. Gen2 per se ist nicht wirklich das Problem, eher gehts da um effektive Datendurchsaetze und allfaelligen Scatter-Gather-DMA-Support fuer eher asynchrone Burst-Transfers. Linux erkennt auch die PCIe devices spaet noch, hotplugging laesst sich ebenso triggern (siehe auch oben Methode "weka"), also braucht man auch IMHO keine Bridge. Ist aber alles schon eine Weile her.
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.