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.
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...
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>
>> 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.
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.
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
