Hallo, viele Hersteller von ARM - Mikroprozessoren bzw. bringen mit ihren CPU's bzw. Controllern bereits fertige Standard Schnittstellen mit. Da kenne ich z.B. SPI I2C MMC SDRAM Kamera-Schnittstelle .... Mit SPI lassen sich am einfachsten FPGA ankoppeln, allerdings ist die Datenrate mit 400 kHz (neuerdings u.U. auch 3.4 MHz erlaubt?) oft zu langsam um Daten zwischen CPU und FPGA auszutauschen. Aber zum Steuern des FPGA reicht es meistens. Nun meine Frage an die Könner hier: Welche gängige Schnittstelle kann man am besten zum schnellen (Bulk-) Datentransfer heranziehen? Ich nehme mal Bezug auf einen imx6 über dieses Datasheet: https://cache.freescale.com/files/32bit/doc/data_sheet/IMX6DQIEC.pdf Auf Seite 8: Da gäbe es z.B. Raw ONFI2.2 Nand-Flash, NOR-Flash PSRAM, camera/MIPI und eMMC,MMC für die es Unterstützung gibt. Doch für welche findet man Treiber für Linux und fertige IP für die FPGA - Seite? Natürlich am liebsten frei für den Hobbyist! Wie macht Ihr das? Evtl. wisst ihr auch Open Source Projekte wo Ähnliches schon realisiert wurde? Danke im Voraus! Gruß Thilo
Die Frequenz bei SPI ist nicht durch den Standard limitert. Wenn Dein Controller 100 MHz kann und die Leitungsführung gut ist, sollte der FPGA als Slave damit auch klarkommen. Damit kommt man auf 100 MBit/s abzüglich Protokoll-Overhead. Bei vielen Controllern hat man aber schon Mühe die SPI mit 20 MHz durchgängig zu bedienen. Das dürfte bei den neueren Cortexen mit DMA-Engine wieder etwas besser aussehen. Die Memoryschnittstellen zur FPGA-Kommunikation zu verwenden ist recht verlockend. Ich habe mal eine Arbeit durchführen lassen, da sind wir auf ca. 150 MBit/s mit einem älteren ARM-Controller gekommen. Der ganz große Nachteil in meinen Augen: man braucht einen Controller mit Memory-Interface (da fallen die kleinen Controller weg) und man braucht auf beiden Seiten recht viele Pins für die Kommunikation: 16-Bit für Daten, min. 16 Bit für Adressen und noch ein paar Steuerleitungen... Die Verwendung solcher Memoryschnittstellen zur FPGA-Kommunikation ist irgendwie doch eine Sonderlocke und nicht wirklich portabel (im Vergleich z.B. zu SPI). Thilo H. schrieb: > Wie macht Ihr das? Momentan steckt der Controller als Softcore im FPGA und da wo die Standardperipherie nicht ausreicht (Timer, GPIO, SPI) wird eigene Peripherie designt. Je nach Systemkonzept und benötigter Datenrate würde ich es wieder so machen oder SPI nehmen oder einen FPGA mit integriertem Hard-IP-Core verwenden. Duke
DIE Standard Schnittstelle gibts da nicht. Bei TI DSP kann man gut das EMIF oder UPP nehmen, ansonsten die jeweilige SRAM Schnittstelle. Oder SATA bei den großen Controllern und FPGA mit Transceiver.
Quad SPI oder 32bit Parallelinterface. Hauptsache im uC DMA-fähig.
Die Frage ist so schön offen gestellt. :) Moderne FPGAs haben gerne PCIe Transceiver mit drauf. Was Du allerdings für die IP-Cores hinlegst, musst Du selber mal schauen. Wenn Du alles selber machen möchtest/musst, gilt es abzuschätzen, welcher Bedarf wirklich vorhanden ist. Und dann wirst Du wohl bei SPI oder S(D)RAM-Interface rauskommen, weil die noch mit wenig Aufwand in VHDL runterzutippen sind.
Wir verwenden zwischen i.MX6 und Altera Arria V PCIe als Interface... Alternativ hätte der i.MX6 noch ein paralleles Speicherinterface (32-bit Daten + Adressen) namens EIM anzubieten.
Thilo H. schrieb: > Mit SPI lassen sich am einfachsten FPGA ankoppeln, allerdings ist die > Datenrate mit 400 kHz (neuerdings u.U. auch 3.4 MHz erlaubt?) oft zu > langsam um Daten zwischen CPU und FPGA auszutauschen. Aber zum Steuern > des FPGA reicht es meistens. Woher hast du das? Ich habe gerade einen Treiber fuer linuxcnc/machinekit und der Mesa 7i90 Karte fuer den Raspi2 geschrieben, und da fahr ich mit 8Mhz. Mit entsp. Kabeln geht noch mehr.
Ich fahre auch spi zwischen zwei STMs. Mit 8MHz und katastrophaler Verkabelung klappt das erstaunlicherweise 1A. Nicht ein einziges falsches Bit wird übertragen. Mit gscheiter Verkabelung geht da sicher noch mehr.
W. M. schrieb: > Woher hast du das? Ich denke, seine 400kHz kommen eher vom I2C. Da sind 100,400 und 1M definiert. Ich fahre I2C im Multiplex an 128 Schnittstellen mit jeweils 1MHz. Singulär zum Nachbar-FPGA sind es dann 256MHz (128 als DDR).
>>> Ich denke, seine 400kHz kommen eher vom I2C. Da hat er Recht. mh schrieb: > Wir verwenden zwischen i.MX6 und Altera Arria V PCIe als Interface... > Alternativ hätte der i.MX6 noch ein paralleles Speicherinterface (32-bit > Daten + Adressen) namens EIM anzubieten. PCIe wäre natürlich am interessantesten. Ich denke man benötigt auch weniger Pins als über SDRAM oder EIM. Aber gibt es dazu auch offene IP? Danke und Gruß, Thilo
:
Bearbeitet durch User
Thilo H. schrieb: > PCIe wäre natürlich am interessantesten. Ich denke man benötigt auch > weniger Pins als über SDRAM oder EIM. Aber gibt es dazu auch offene IP? Auf unterster Ebene ist das ja "nur" ein Transceiver, das ist immer kostenlos dabei. Auch PCIe ist bei Xilinx noch kostenlos, ein eventuell nötiger DMA Core nicht. Aber den braucht man ja bei der Anwendung vielleicht nicht.
Hat denn ein uC wie eine klassische CPU ein PCIe Interface?
Fragi schrieb: > Hat denn ein uC wie eine klassische CPU ein PCIe Interface? µCs haben das eher selten. Der imx6 des TO ist aber auch kein µC.
Wenn ich an einen STM32 denke, fällt mir der FSMC (Flexible Static Memory Controller) ein, mit dem man ein paralleles Speicherinterface abbilden kann. Aus Sicht des STM ist das auch DMA-fähig, der STM ist nämlich Master. Der FSMC-Slave im FPGA muss natürlich selbst implementiert werden. Hier ist ein Projekt, das einen STM32 und einen FPGA koppelt. https://github.com/dergraaf/loa/tree/master/fpga/modules/fsmcslave/hdl
Strongly T. schrieb: > Wenn ich an einen STM32 denke, fällt mir der FSMC (Flexible Static > Memory Controller) ein Bei den größeren STM32F4 und den F7 wäre Quad-SPI noch eine Pin-sparende Alternative. Der FSMC braucht ziemliche viele Pins.
Gerd E. schrieb: > Strongly T. schrieb: >> Wenn ich an einen STM32 denke, fällt mir der FSMC (Flexible Static >> Memory Controller) ein > > Bei den größeren STM32F4 und den F7 wäre Quad-SPI noch eine Pin-sparende > Alternative. Der FSMC braucht ziemliche viele Pins. Ist mit Sicherheit eine Option. Afair geht das bei den F7 je nach Last bis 108 MHz SDR und 80 MHz DDR. Edit: Die haben noch einen Dual-Modus. Zusammen mit DDR wären das 16 Bit pro Takt oder 1280 MBit/s... Ethernet, bei größeren "Controllern" auch GBit Ethernet, eine andere. Ebenso wie High-Speed USB.
:
Bearbeitet durch User
Arc N. schrieb: > Gerd E. schrieb: >> Strongly T. schrieb: >>> Wenn ich an einen STM32 denke, fällt mir der FSMC (Flexible Static >>> Memory Controller) ein >> >> Bei den größeren STM32F4 und den F7 wäre Quad-SPI noch eine Pin-sparende >> Alternative. Der FSMC braucht ziemliche viele Pins. > > Ist mit Sicherheit eine Option. Afair geht das bei den F7 je nach Last > bis 108 MHz SDR und 80 MHz DDR. > Edit: Die haben noch einen Dual-Modus. Zusammen mit DDR wären das 16 Bit > pro Takt oder 1280 MBit/s... > Ethernet, bei größeren "Controllern" auch GBit Ethernet, eine andere. > Ebenso wie High-Speed USB. USB ist sehr verbreitet und daher Vorteilhaft. Allerdings schreckt mich der große Protokoll-Overhead ab - es sei denn hier gibt es fertige (open) IPs und Linux Treiber. Die USB Controller (Cypress & Co) würden zwar funktionieren aber man hat dann wieder einen zusätzliche Baustelle und die FPGA <-> Cypress Schnittstelle muss ja dann immer noch implementiert werden. Andererseits - wenn man auf Cypress & Co verzichtet steht man wieder ohne Linux Treiber da. Das Thema hat eben viele Facetten..... :-( >>> Hallo, >>> Ich verwende SRIO. Das habe ich noch nicht gehört. Was ist das? zum STM32: Ich liebe den STM32 - aber ich halte den STM32 als Basis für eine Applikation welche einen FPGA nutzt für zu klein - es sei denn der dient als Controller zur Ankoppelung zur Kommunikation. Auch hier lasse ich mich eines Besseren belehren. Ich hatte eher die Klasse um diese Boards/Prozessoren hier im Auge: https://eewiki.net/display/linuxonarm/Home Beim Wandboard z.B. wirft man den Basisträger weg und steckt das Prozessor-Modul auf einen neuen (eigenen) Basisträger mit FPGA. Der Raspberry wäre auch nett, aber die Möglichkeiten zur Ankopplung sind sehr Überschaubar. Wenn man ein custom design in Betracht zieht hat man andere Hürden. Würde man die nötigen chips überhaupt bekommen? Wie ist es denn bei den FPGA Herstellern und dem USB-Thema? Bringen denn einige Hersteller bereits die USB-Ankopplung mit incl. Treiber? (Natürlich in der SPARTAN-Klasse) Dank für eure Beiträge. Grüße, Thilo
Statt ein Wandboard zu kaufen und die hälfte wegschmeißt kann man auch direkt bei einem der vielen SOM Herstellern nur das Prozessormodul kaufen... z.B: Phytec, Olimex, Congatec usw... Hier gibts die dann auch in verschiedenen Temps/Ausbaustufen und sogar verschiedene Prozessoren.... Braucht man nur noch ne Basisplatine mit fpga oder man lässt sich bei den Firmen eine machen nach Kundenvorgaben... Je nach Komplexität geht das bestimmt auch "günstig"..
Da den Link noch keiner in diesem Thread gepostet hat, tu ich's nochmal: https://danstrother.com/2010/12/04/fmc-lpc-to-sata-adapter-board/ Die Lösung finde ich immer noch optimal "KISS" und gleichzeitig elegant, da die SATA-Anbindung kaum was kostet. Allerdings braucht man ev. noch ein billiges MACHXO2(3) als Backend-Busbrücke, da leider zuwenige uC ein flexibles LVDS-Interface (für Input!) besitzen. Lasse mich bei letzterem allerdings gerne belehren.
Vielleicht wäre ja IDE mit 133 MHz x 32 bit interessant? Könnte dann als block device angesprochen werden.
Strubi schrieb: > da die SATA-Anbindung kaum was kostet. Allerdings braucht man ev. noch > ein billiges MACHXO2(3) als Backend-Busbrücke, da leider zuwenige uC ein > flexibles LVDS-Interface (für Input!) besitzen. Das hilft also nur, wenn das Problem nicht die Anbindung µC <-> FPGA an sich ist, sondern eine längere (Kabel-)Strecke überwunden werden muss. Wenn die beiden aber recht nah auf der selben Platine sitzen, kannst Du die Logik, die Du in den MachX02 steckst, auch gleich in den "richtigen" FPGA stecken und Dir SATA, LVDS etc. sparen.
Gerd E. schrieb: > Wenn die beiden aber recht nah auf der selben Platine sitzen, kannst Du > die Logik, die Du in den MachX02 steckst, auch gleich in den "richtigen" > FPGA stecken und Dir SATA, LVDS etc. sparen. So ist es. Eigentlich gibt es nur zwei Möglichkeiten, die Daten zu schieben: 1) Streaming mit einem im Wesentlichen stillen Empfänger, also vom uC zum FPGA und rückwärts - oder 2) Memory Mapped, wenn man wahlfrei zugreifen muss. Das schnellste ist da nach wie vor ein asynchrones Memory-Interface mit direkt angeschlossenem Register-RAM in ausreichender Breite und einem Interpreter drauf, der direkt Befehle anschubsten kann.
Moin, Weltbester FPGA-Pongo schrieb im Beitrag #4579068: > So ist es. Eigentlich gibt es nur zwei Möglichkeiten, die Daten zu > schieben: > > 1) Streaming mit einem im Wesentlichen stillen Empfänger, also vom uC > zum FPGA und rückwärts - oder > > 2) Memory Mapped, wenn man wahlfrei zugreifen muss. Das schnellste ist > da nach wie vor ein asynchrones Memory-Interface mit direkt > angeschlossenem Register-RAM in ausreichender Breite und einem > Interpreter drauf, der direkt Befehle anschubsten kann. An den parallelen Interfaces waren/sind mir die vielen Leitungen immer bisschen ein Dorn im Auge, auch, dass man sich bei mehreren Geräten am Bus viel Autschen im Layout einbrockt. Da muss nicht mal viel Strecke über ein Kabel gehen, schon kostet's nen Layer mehr. Da rechnet sich während der Entwicklung sogar ein extra FPGA. Natürlich nur bei kleinen Stückzahlen. Ansonsten fiele mir noch ein Hack über i2s (SPORT, etc.) ein, das ist so einigermassen standardisiert bei den meisten uC. Leicht zu implementieren, aber bringt nicht mords Bandbreite. Hat mal wer von euch SDIO (Slave) auf dem FPGA ausprobiert? Grüsse, - Strubi
Man das natürlich serialisieren indem man den Vektor einfach dreht und z.B. 16 Bit Daten puffert und nacheinander rausschiebt. Andererseits bekommt man gerade mit einem FPGA leitungsbedingte Verschiebungen in den Griff indem man die Delays justiert. Muss für viele Applikationen ohnehin geschehen, weil's aus den Chips schon nicht 100% rauskommt.
Strubi schrieb: > An den parallelen Interfaces waren/sind mir die vielen Leitungen immer > bisschen ein Dorn im Auge, Stimmt, aber wenn es seriell kommt, hat man immer den gesamten Block mit der Wortlänge abzuwarten, bis die Gegenstelle was dekodiert und ein Wort rekonstruiert hat, um reagieren zu können.
Wie sieht es mit dem Camera - Interface aus? Ein bidirektionales Interface wäre zwar schöner aber mir geht es darum mit Daten hoher Bandbreite entgegen zu nehmen. Sind Datenverlusste möglich? Gibt es dafür bereits open source VHDL code? Danke und Gruß Thilo
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.