Hallo, ich suche nach einem günstigen FPGA mit PCIe (Das e ist wichtig. Das System hat kein PCI). Der FPGA soll zur Digitalen Datenverarbeitung genutzt werden und ein paar Schnittstellen über ADC, DAC etc nach außen bringen. Mein Wunsch wäre es, wenn der FPGA... 1. ... in einem "lötbaren" Gehäuse, sprich TQFP, wäre. QFN ginge zur Not auch. Nur BGA wird kritisch. 2. ... relativ günstig wäre. 3. ... von Altera wäre (SW bereits installiert). Der dritte Punkt wäre cool. Habe allerdings keinen FPGA bei Altera gefunden, der PCIe beherrscht und im Rahmen meiner Möglichkeiten liegt. Da ich vor einiger Zeit leider ein günstiges Dev-Board auf ebay verpasst habe, wollte ich das Board selber machen mit allen Komponenten die dazu gehören. Im Sinn habe ich eine 4 lagige Platine, gefertigt in Fernost (pcbway oder andere Verdächtige). Ich möchte eigentlich einen FPGA, der wie ein Cyclone IV mit 6000LEs ist, aber PCIe beherrscht. Leider habe ich nur große FPGAs gefunden, die PCIe beherschen. Diese sind sowohl was die Bauform angeht unbrauchbar als auch preislich. Zudem würde ich einen >25000LEs Cyclone V (Beispiel) mit meinem Design sowieso nicht füllen. Zumindest habe ich das nicht vor. Voll bekommt man die Dinger immer... Alternativ wäre auch eine 2 Chip Lösung akzeptabel. Also eine Art PCIe PHY, sodass man mit einem TQFP100 Popel-FPGA an den Bus kommt. Kennt da jemand eine Möglichkeit? Die dritte Lösung, die mir eingefallen ist, wäre ein PCIe auf PCI Bridge-IC. PCI ist ein "langsamer" Bus, den man im FPGA hinbekommen sollte. Leider habe ich nur sehr wenige und völlig überteuerte Angebote von solchen ICs gefunden. Hat jemand Lösungsvorschläge? Oder ist der Wunsch PCIe und "bezahlbar für Student" außer Frage? Bin auch für andere Vorschläge offen. Die Hauptsache ist es, einen FPGA an den PCIe zu bekommen und eigene Hardware (schätzungsweise 20 Signale kleiner 10 MHz) anzuschließen. Vielen Dank EDIT: Es geht mir nicht darum große Datenraten zu nutzen. Eine PCIe Lane ist völlig ausreichend. Die Datenmenge wird höchstens bei 1 Mbit/s liegen. Vielmehr geht es darum, den Rechner als "unendlichen großen" Speicher und Rechenknecht zu verwenden. Linux-Treiber und Software stellen kein Problem dar.
Bei Deiner etwas sonderbaren SPEC fehlt noch die Kapazität des Busses. Wie schnell und wieviel Lanes? PCIe wirst Du in der Regel nur mit den GigabitPorts hinbekommen und die sind (auch bei Altera) in den kleinen Chips nicht verbaut. Allerdings meine Ich, dass es einen Cyclone IV gibt, der die Ports hat. Dazu braucht es aber IMHO die Vollversion von Quartus, da die C4s nur in der NICHT-GBT mit der Wbversion unterstützt werden. Wie wäre es denn mit einem MIX? Der Artix von Xilinx kann das serienmässig. Nimmst Du einen 50er und einen Cyclone III. Das wäre wohl das billigste. Musst aber Vivado installieren. Das scheint wohl ein Kriterium zu sein. Kannst natrlich auch nur mit Vivado arbeiten und das Cyclone-Geraffel noch mit im Artix machen. Xliinx versteht ja auch VDHL. Noch ...
> FPGA > TQFP > PCIe Gibt es AFAIK nicht (bei keinem Hersteller). Es ist PCIe völlig egal wie doll Du es auslasten möchtest, datt rennt immer mit 2.5 oder mehr Gbit/s. Warum nicht einfach USB?
Weltbester FPGA-Pongo schrieb im Beitrag #4921896: > Kannst natrlich auch nur mit Vivado arbeiten und das Cyclone-Geraffel > noch mit im Artix machen. Xliinx versteht ja auch VDHL. Noch ... Generell bin ich offen für einen Xilinx Chip. Kann man diesen mit der kostenlosen Entwicklungsumgebung "programmieren"? Weltbester FPGA-Pongo schrieb im Beitrag #4921896: > Der Artix von Xilinx kann das > serienmässig. Ist das ein echtes Können? Ist der IO Standard kompatibel mit PCIe oder ist das ein Mißbrauch eines anderen Standards?
Zoltan schrieb: > Warum nicht einfach USB? Wenn du mir eine Lösung findest einen DMA Transfer über USB einzuleiten :/ Ebenso ist USB im FPGA auch keine spaßige Sache. ich erinnere mich noch an die schlaflosen Nächte mit nem STM32...
Okay. Eine schnelle Suche bei Digikey hat ergeben, dass es die Artix FPGAs auch nur im BGA Gehäuse gibt. Somit fallen diese ebenfalls raus. Ich hoffe jemand hat noch eine Idee, wie man FPGA+HW an PCIe bekommt für bezahlbares Geld. USB möchte ich nur im allergrößten Notfall verwenden. PCIe wäre mir lieber, da, mit IP core recht einfach. Treiber sind auch einfach. USb wäre auch möglich. Leider ist dies im FPGA mit erheblichem Mehraufwand verbunden. Softwaremäßig sollte das iwie gehen. Nur schade, dass der DMA Transfer im Rechner wegfällt.
Für PCIe, günstiger als das hier geht zur Zeit nicht, denke ich: http://www.latticesemi.com/Products/FPGAandCPLD/ECP5ECP5GPromotion.aspx Gibts z.B. bei Mouser Es weicht zwar stark von deiner Spec ab, (BGA, nicht Altera ...) aber es ist halt günstig. Über einen Steckfeld (2x 40 Pin) kannst du deine 1 MHz Signalquellen anschliessen.
Was ist mit dem Dragon von Knjn? https://www.knjn.com/eu/ShopBoards_PCI.html 400€ kostet der Spaß. Keine Ahnung ob/wie geeignet der ist. Signifikant billiger wird's mit einem eigenen Design wahrscheinlich nicht, spätestens wenn du deine Zeit einberechnest.
Gibt es nicht irgendwo PCI nach PCIe Brücken/Hubs? PLX baut doch so Zeug ... Sonst würde ich auch einen USB Stein ranflanschen, kann USB3 wirklich kein DMA? Oder nimm ein BGA-FPGA aber schon auf einem kleinen Modul dass Du dann auf die PCIe Karte draufsteckst.
Wie wäre es mit Firewire? Gibt's als PCIe-Karte, kann DMA, scheint aber im FPGA viel Aufwand zu sein. Wie wäre es mit SATA? Wie wäre es mit Ethernet?
:
Bearbeitet durch User
Charles G. schrieb: > Für PCIe, günstiger als das hier geht zur Zeit nicht, denke ich: > http://www.latticesemi.com/Products/FPGAandCPLD/EC... > > Gibts z.B. bei Mouser > > Es weicht zwar stark von deiner Spec ab, (BGA, nicht Altera ...) aber es > ist halt günstig. Über einen Steckfeld (2x 40 Pin) kannst du deine 1 MHz > Signalquellen anschliessen. Das Board kann ich auch empfehlen. Nur vielleicht für den Studenten etwas knackig, viele ECP5-Primitiven sind auch nicht als VHDL-Simulationsmodelle vorhanden, das kann irritieren. Und die Diamond-Toolchain macht lustige Sachen, da ist man vielleicht mit der ISE und nem grösseren Spartan6 besser dran, aber mir fällt die britische Firma mit dem PCIe-Spartan6-Steckboard nicht mehr ein...
Gustl B. schrieb: > kann USB3 wirklich > kein DMA? Doch kann es. Das ist ja komplett anders als USB 2.0.
Zoltan schrieb: >> kann USB3 wirklich >> kein DMA? > > Doch kann es. > Das ist ja komplett anders als USB 2.0. Nur leider ist kein USB 3.X vorhanden. S. R. schrieb: > Wie wäre es mit SATA? Etwas anderes als Speicherbefehle (SCSI etc...) über SATA bzw diese dafür zu missbrauchen scheint mir etwas kritisch. Da stellt sich nunmal auch die Frage: SATA: 3/6 Gbps seriell Bus. Braucht man nen FPGA mit SERDES => Groß, teuer, unlötbar im Hobbybereich. Und selbst wenn. Die meisten FPGAs werden keinen IO Standard besitzen, der SATA kompatibel ist. S. R. schrieb: > Wie wäre es mit Ethernet? Das hab ich mir auch schon überlegt. Die Datenrate wäre in Ordung, Ethernet PHYs sind billig bzw. nicht billig, aber bezahlbar. Zudem ist Ethernet noch ziemlich primitiv und nimmt nicht viel Platz weg, solange man nur MAC fährt. Ich werde mir das überlegen. Wobei ich da eventuelle Probleme sehe, einen Kerneltreiber für das über Ethernet angeschlossene Gerät zu schreiben... Muss mal überlegen, ob das als User-Software sinnvoller bzw. überhaupt machbar ist. Strubi schrieb: > Und die > Diamond-Toolchain macht lustige Sachen Das kannst du laut sagen. Mit Lattice, genauer Diamond, stehe ich auf Kriegsfuß. <offtopic> Meine Leidensgeschichte begann mit der Installation auf Linux. Ein RPM zu entpacken auf einem System, dass keinen rpm Paketmanager hat ist n bisschen doof mit den ganzen Pre- und Post-install-Skripten. Nachdem Diamond installiert war, weigert es sich natürlich zu funktionieren. Die überprüfen beim Start der sysnthese die Linux-Kernelversion. Meine war unsupported => Läuft nicht. Erstmal skripte patchen und das if umbasteln... Nachdem die SW dann lief habe ich ein Ethernet Design synthetisiert. Hat auf dem FPGA (LFXP2-5E) nichts gemacht... Simulation ging. Da das Design aber schon häufiger einige Bugs hatte, habe ich gedebuggt wie wild. Nachdem ich nichts finden konnte und etliche Stunden und Kaffeetassen später, kam ich auf die Idee mal nen Altera Chip zu nehmen. Ergebnis: Geht. => Also Lattice angeschrieben und gefragt, warum ihre Synthese bei einem 500 Zeilen VHDL Design mit n paar standart State-Machines die Grätsche macht. Die wollten dann eine Timingsimulation. => Gemacht. Ergebnis: Tut nicht. Screenshots von normaler Simulation und Timing-Sim hingeschickt. Ergebnis sinngemäß: "YOLO. Ist uns egal. Du bist eh nur Student..." Aufgrund dieser Erfahrung meide ich Lattice momentan, obwohl ich ihre Chips immer sehr schön fand. </offtopic>
Schau dir mal auf devboards das DB4CGX15 Kit an. Das ist mit Cyclone IV und durchaus bezahlbar.
> > S. R. schrieb: >> Wie wäre es mit Ethernet? > > Das hab ich mir auch schon überlegt. Die Datenrate wäre in Ordung, > Ethernet PHYs sind billig bzw. nicht billig, aber bezahlbar. Zudem ist > Ethernet noch ziemlich primitiv und nimmt nicht viel Platz weg, solange > man nur MAC fährt. Ich werde mir das überlegen. Wobei ich da eventuelle > Probleme sehe, einen Kerneltreiber für das über Ethernet angeschlossene > Gerät zu schreiben... Muss mal überlegen, ob das als User-Software > sinnvoller bzw. überhaupt machbar ist. > Warum Kerneltreiber? Brauchst du proprietäres/Echtzeit? Das geht nur mit wüsten Hacks und Direktzugriff auf die Packet Queue. Hier hat doch gerade jemand den Hamster-UDP-Stack mit Labview verknotet.. > Strubi schrieb: >> Und die >> Diamond-Toolchain macht lustige Sachen > > Das kannst du laut sagen. Mit Lattice, genauer Diamond, stehe ich auf > Kriegsfuß. Sie haben halt seit Jahren gehörige Bugs in ihrem TCL-Gefrickel unter Linux und weigern sich, die zu beheben, deswegen funktioniert das Bauen nur wirklich rund um die Uhr, wenn man die .exe's per Makefile/shell aufruft. Das einzig nette an der Toolchain ist die IMHO sehr gut designte Synopsys-SW. Ansonsten lässt sich Diamond per alien schon ohne Krücken unter Ubuntu installieren, aber spinnt halt regelmässig mit Pfadnamen rum, das ist einem Endkunden kaum zuzumuten. Trotz der schönen Chips musste ich leider auch öfters diesbezüglich aus ganz pragmatischen Gründen aufs grosse X zurückfallen.
PCIe geht schon mit Spartan6, schau dich doch mal nach als obsolet ausgemusterte bitcoin mining boards um. http://208.73.201.56/item/Avalon-ngzhang-FPGA-Lancelot-XC6SLX150-SHA256-miner-Collectibles-USB-asic-miner-Bitcoin-miner-450-Mh-s/32613306739.html?spm=2114.40010708.4.5.k6Bmvc Es gibt auch offizielle PCI-e FPGA-Evalboards: https://www.xilinx.com/products/boards-and-kits/ek-k7-kc705-g.html https://www.xilinx.com/products/boards-and-kits/ek-a7-ac701-g.html https://www.xilinx.com/products/boards-and-kits/ek-s6-sp605-g.html
Vieleicht wäre ja auch der Umweg über ein PCMCIA bzw. Cardbus über PCIe Karte eine Möglichkeit.
M. H. schrieb: > Alternativ wäre auch eine 2 Chip Lösung akzeptabel. Also eine Art PCIe > PHY, sodass man mit einem TQFP100 Popel-FPGA an den Bus kommt. Kennt da > jemand eine Möglichkeit? Da gab' es mal Lösungen für den Spartan-3... > Die dritte Lösung, die mir eingefallen ist, wäre ein PCIe auf PCI > Bridge-IC. PCI ist ein "langsamer" Bus, den man im FPGA hinbekommen > sollte. Leider habe ich nur sehr wenige und völlig überteuerte Angebote > von solchen ICs gefunden. Der XIO2001 (http://www.ti.com/product/XIO2001) ist nicht teuer und es gibt ihn tatsächlich im TQFP-Gehäuse.
M. H. schrieb: > Der FPGA soll zur Digitalen Datenverarbeitung genutzt werden und ein > paar Schnittstellen über ADC, DAC etc nach außen bringen. S. R. schrieb: > Wie wäre es mit Firewire? Das ist doch tot. > Wie wäre es mit SATA? Wäre eine Möglichkeit, passt aber m.E. nicht ganz so gut zu den Anforderungen. > Wie wäre es mit Ethernet? Das wäre mein Favorit. Da braucht man keine PCIe-Hersteller ID und keinen Kerneltreiber. In diesem Fall scheint letzteres ja kein Problem zu sein. Der Code kann ja als Bibliothek im Userland laufen. Bernhard T. schrieb: > Vieleicht wäre ja auch der Umweg über ein PCMCIA bzw. Cardbus über PCIe > Karte eine Möglichkeit. Genauso obsolet wie Firewire. Gustl B. schrieb: > Gibt es nicht irgendwo PCI nach PCIe Brücken/Hubs? PLX baut doch so Zeug So einen Umweg würde ich nicht gehen. PCI ist eben auch schon so gut wie tot. Bitwurschtler schrieb: > PCIe geht schon mit Spartan6, schau dich doch mal nach als obsolet > ausgemusterte bitcoin mining boards um. Das Bitcoinboard kann eher kein PCIe. Dafür braucht man m.E. die Spartans mit den Gigabit-Transceivern. Das günstigste von Xilinx ist das SP605 für 500 Tacken. Mir wäre das zuviel für's Hobbybudget. Die anderen Anbieter (KNJN und Lattice) wurden schon genannt. Für das KNJN-Dragonboard gibt es immerhin so eine Art Tutorial: http://www.fpga4fun.com/PCI-Express.html Bei Trenz findet man auch nix wirklich in günstig: https://shop.trenz-electronic.de/de/search?sSearch=pcie Duke
Duke Scarring schrieb: > Gustl B. schrieb: >> Gibt es nicht irgendwo PCI nach PCIe Brücken/Hubs? PLX baut doch so Zeug > So einen Umweg würde ich nicht gehen. PCI ist eben auch schon so gut wie > tot. Das schon. Aber Softwaretechnisch verhält es sich, zumindest bei Linux, identisch zu PCIe. Deshalb ja die Idee, die schnelle PCIe Lane auf den langsamen Bus umzubasteln. Das ist teilweise Heute auch noch üblich. Viele Mainboards besitzen irgendwo eine PCIe auf PCI Bridge für LAN, Audio und so weiter. Duke Scarring schrieb: > Das wäre mein Favorit. Da braucht man keine PCIe-Hersteller ID und > keinen Kerneltreiber. In diesem Fall scheint letzteres ja kein Problem > zu sein. > Der Code kann ja als Bibliothek im Userland laufen. Das ist mittlerweile der Plan, da die PCIe Sache doch etwas aus dem ruder läuft. Das Problem ist, es kommt auf sehr geringe Latenzen an. Das werde ich in einer ruhigen Minute testen. Hatte mit dem Netzwerkstack von Linux schonmal meine Probleme. Damals mit CAN...
M. H. schrieb: > Zoltan schrieb: >> Warum nicht einfach USB? > > Wenn du mir eine Lösung findest einen DMA Transfer über USB einzuleiten > :/ Warum muss das DMA vom FPGA direkt in den Rechner gehen können? Ist das ganze so latenzkritisch daß Du kaum puffern kannst? > Ebenso ist USB im FPGA auch keine spaßige Sache. ich erinnere mich noch > an die schlaflosen Nächte mit nem STM32... Du musst das USB ja nicht komplett selber machen, dafür gibt es fertige ICs. Folgende 2 Linien würde ich empfehlen mal anzuschauen: FTDI http://www.ftdichip.com/Products/ICs/FT2232H.html - USB HS http://www.ftdichip.com/Products/ICs/FT600.html - USB 3 SS Cypress http://www.cypress.com/products/ez-usb-sx2 - USB 2 HS http://www.cypress.com/products/ez-usb-fx2lp - USB 2 HS http://www.cypress.com/products/ez-usb-fx3-superspeed-usb-30-peripheral-controller Die FTDIs haben dabei immer die Funktion komplett festgelegt und Du musst im FPGA Glue-Hardware schreiben die an deren Interface andockt und auch etwas puffert. Bei Cypress gibt es welche (FX2 und FX3) die einen eigenen Prozessor (8051 bzw. ARM) drauf haben den Du programmieren kannst. Das vereinfacht evtl. die Schnittstelle zum FPGA, Du musst aber natürlich ein Teil mehr programmieren, debuggen,... USB hat den großen Vorteil daß es eine extrem weit verbreitete Peripherieschnittstelle ist und bisher immer Rückwärtskompatibel war. Eine 19 Jahre alte Maus kannst Du auch heute noch anschließen und sie wird sofort erkannt und funktioniert. Da stehen die Chancen also gut daß Dein Gerät auch in 10 Jahren noch an einen dann aktuellen PC angeschlossen werden kann. Wenn man sich die Geschichte mit ISA/PCI/AGP/PCIe anschaut, könnte PCIe bis dahin verschwunden oder zumindest selten geworden sein. SATA wird es in der heutigen Form in 10 Jahren sicher nicht mehr geben. Nur mit Ethernet wirst Du vermutlich ähnlich zukunftssicher sein wie mit USB.
Nimm ein Altera De0 Nano SoC. Gibts für <100€ und hast alles was du brauchst... Kannst die Daten mim FPGA holen im SoC zwischenspeichern bzw. packen oder sonstiges und per USB oder GBit Ethernet rausjagen.
No Y. schrieb: > Nimm ein Altera De0 Nano SoC. > Gibts für <100€ und hast alles was du brauchst... > Kannst die Daten mim FPGA holen im SoC zwischenspeichern bzw. packen > oder sonstiges und per USB oder GBit Ethernet rausjagen. Ist bereits vorhanden. Das Problem ist nur, dass der FPGA an den Rechner angeschlossen werden soll und nicht ein extra gerät gebaut werden soll, dass dann wiederum über Ethernet/USB kommuniziert. Sollte ich das ganze über Ethernet machen, ist der SoC auch unnötig. Eine 100Mbit oder 1Gbit MAC geht gut in VHDL.
M. H. schrieb: > Das Problem ist nur, dass der FPGA an den Rechner > angeschlossen werden soll und nicht ein extra gerät gebaut werden soll, > dass dann wiederum über Ethernet/USB kommuniziert. Das Problem ist also, daß das alles im Gehäuse des PCs drin sein soll und nicht als extra Kiste außerhalb des PCs rumstehen soll? Einige USB-Schnittstellen sind normalerweise auch als Pin-Header am Mainboard für den Zugriff von Innen verfügbar. An die könntest Du rangehen und den Rest der Hardware z.B. auf eine Platine packen, die zwar den Formfaktor einer PCIe-Karte hat, aber einfach keinen PCIe-Anschluss verwendet.
Was ist, wenn du solch ein Modul nutzt? https://shop.trenz-electronic.de/de/TE0714-02-50-2IC6-Artix-Micromodul-A50-mit-Xilinx-XC7A50T-2CSG325I-und-spezieller-Konfiguration?path=Trenz_Electronic/TE0714/Reference_Design
Hab noch ein Board gefunden: https://www.enterpoint.co.uk/products/artix-7-development-boards/raggedstone-5 Gibt auch ein älteres mit Altera Steinchen: https://www.enterpoint.co.uk/products/cyclone-iv-development-boards/raggedstone3
:
Bearbeitet durch User
Mir ist eben eine Werbung ins Postfach geflattert:
Mars XU3: Zynq® UltraScale+™ Kraftzwerg
108 User-I/Os, PCIe, Gigabit Ethernet, USB 3.0
Scheint es aber noch nicht zu geben ("In Development") und in den PC
kann man das Board so auch noch nicht reinstecken...
Duke
Weltbester FPGA-Pongo schrieb im Beitrag #4921896: > Xliinx versteht ja auch VDHL. Noch ... Gibt es Pläne, dass Xilinx bald kein VHDL mehr versteht??? Grüße Jan
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.