Linux auf Cyclone V (mit HPS) -> IP-Core-Treiber?

Tach,

das mit Linux auf FPGA würde ich mir sehr gut überlegen, denn das ist 
eher ein akademischer Spass (oder proof of concept) als wirklich 
brauchbar, der Aufwand steht auch in keinem Verhältnis. Du musst in der 
Tat Treiber dafür schreiben und sicherstellen, dass auch der 
entsprechende Bus-Support von Altera bereitgestellt wird, sonst artet 
das ziemlich aus.
Wenn ihr also nicht gerade 10'000 davon im Jahr raushaut, würde ich mir 
gut überlegen, ob sich ein zusätzlicher kleiner ARM oder Blackfin 
(µcLinux-Geheimtip!) nicht gegenüber den Entwicklungskosten rechnet.

Er redet über Cyclone V SoC -- da ist ein Dual-Core ARM mit 800 MHz 
drin.
Habe selber ein DevKit auf dem Tisch -- Linux zum Laufen zu bringen und 
mit dem FPGA zu kommunizieren ist ganz easy :-)

Treiber für Ethernet/USB und anderen Kram ist von Hause aus da. Wenn man 
selber was implementieren möchte, dann müssen natürlich die Treiber 
selber geschrieben werden.
Kest

Erstmal danke an alle =)

@Fritzbude: Es geht allerdings um ca. 10k insgesamt =)

@Kest: Vom Developer Board hab ich schon gelesen, bin mir aber aufgrund 
von fehlendem Wissen unsicher, ob man die Treiber einfach nehmen kann. 
Würde doch nur mit der entsprechenden Hardware außenrum funktionieren... 
Wobei... Ethernet-Phy müsste ja fast immer gleich sein, von der 
Ansteuerung her, USB geht direkt drauf...
Ich brauch allerdings ne Displayansteuerung über LVDS mit verschiedenen 
Displayauflösungen. Dafür müsste ich noch was finden.

@Michael: Hm. Glaub das werd ich gleich mal machen. Fragen kost ja nix 
^^

Manche DevKits haben Erweiterungsstecker, an die könntest Du Deinen 
Display anschließen.
Um vom Linux aus da was auszugeben bräuchtest Du eine FPGA-Komponente, 
die LVDS/Display-Signale generieren kann und natürlich einen 
FrameBuffer, den Du vom Linux aus mit Daten beschreiben kannst.
Wie schwer es ist, die Treiber anzupassen kann ich nicht abschätzen. Bin 
selber dabei soetwas zum Laufen zu bekommen.
Kest

Bei uns geht es nicht darum, die Developerkits zu verwenden, sondern den 
Chip auf ein eigenes Board zu platzieren, falls das nicht klar geworden 
sein sollte. Das ändert auch die umliegende Peripherie, weswegen ich mir 
Sorgen mache, dass große Änderungen an den Treibern bzw. eigenes 
Treiberschreiben nötig wäre. Das wäre ein Ausschlusskriterium für den 
SoC, weil der Aufwand dann erheblich höher ist, als bei "normalen" 
ARM-Prozessoren (bei denen die nötigen Schnittstellen alle direkts 
vorhanden sind).

Fehlende Schnittstellen:
- SPI/I2C/USB/UART jeweils zwar vorhanden, aber leider zu wenige
- PCIe
- MIPI CSI
- LVDS
- SDHC leider auch nur einmal

Warum die Treiberentwicklung schwieriger sein sollte?
Die festen HPS-Schnittstellen werden genauso sein, wie bei anderen 
Prozessoren auch, jedoch stelle ich mir die variablen, über IP-Cores 
realisierten Schnittstellen schwerer vor in Linux zu implementierten 
(bzw. eben Treiber zu finden, an denen man nicht mehr viel ändern muss).

> SPI/I2C/USB/UART jeweils zwar vorhanden, aber leider zu wenige
und
> SDHC leider auch nur einmal
Das ist ja gerade das tolle an einem FPGA, davon kann man sich soviele 
machen wie man will bzw. wie Platz oder Pins da sind.

- LVDS
Hat jedes FPGA wohl mehr als nen normaler ARM

- PCIe
gehen auch soviele wie Platz da ist (natürlich braucht man nen IP Core) 
und ist natürlich vom FPGA abhängig. Die neuen haben sowas aber in 
Hardware Implementiert.

Du hast aber in einem Punkt recht, das muß erst mal alles 
zusammengeschustert werden, synthetisiert werden, getestet werden und 
dann auch noch konfiguriert werden. Aber in Sachen Treiber nimmt sich 
das wohl nichts.
Bei nen normalem ARM ist halt die Harware schon fertig, und wenn du noch 
was zusätzlich brauchst haste halt Pech gehabt. Bei nem FPGA machste dir 
das dann halt noch dazu.

Uwe schrieb:
> Bei nen normalem ARM ist halt die Harware schon fertig, und wenn du noch
> was zusätzlich brauchst haste halt Pech gehabt.

Ne dann baut man sich nen kleines FPGA an den externen Bus dran oder 
nimmt fertige Controller mit USB / SPI ;-)

> Aber in Sachen Treiber nimmt sich das wohl nichts.

Eh doch, die vom normalen ARM SoC sind fertig und vom Hersteller 
getestet, also anschalten+loslegen ;-)
Und auch gerade so Dinge wie Displays ansteuern, da sind die in den ARMs 
eingebauten Controller schon sehr leistungsfähig, das muss man im FPGA 
erstmal gescheit hinbekommen.

Ja, LVDS mag ein FPGA-SoC mehr haben, aber das ist auch nicht mein 
Problem. Mein Problem in dem Fall ist, dass es durch die 
Konfigurierbarkeit des FPGAs eben keine Festen Schnittstellen (im 
FPGA-Teil!) gibt, und somit wahrscheinlich auch keine fertigen Treiber 
(oder Treiber die man sehr schnell anpassen kann, ohne sau tief 
einzusteigen). Und gerade bei Grafik und PCIe ist ein Treiber selbst 
schreiben relativ aufwändig.

Klar, bei einem reinen ARM-Prozessor muss man auch Treiber haben, aber 
die gibt's eben schon komplett fertig vom Hersteller, weil er die einmal 
machen muss und fertig. Da weiß der Hersteller ja aber auch schon, was 
beim Entwickler später für Schnittstellen im Prozessor sind (weil eben 
fest).

Ich glaube mittlerweile, den Aufwand kann keiner so direkt einschätzen. 
Hab echt schon ewig gelesen, aber es ist sehr anwendungsabhängig. Sicher 
bin ich mir, dass die reinen Prozessoren "einfach" sind, da eben der 
Hersteller bereits Treiber anbietet. Beim FPGA-SoC mag es auch "einfach" 
sein, kann jedoch auch ziehmlich aufwendig werden, wenn man den Treiber 
eben doch komplett selbst schreiben muss, weil kein passender vorhanden 
ist. Und so wie ich das bisher überblicke, sind nur für wenige IP-Cores 
auch direkt Linux-Treiber vom jeweiligen Anbieter vorhanden.

Ich denke damit hat sich das Thema dann auch. Danke für eure Meinungen, 
ich werd das nochmal mit den Chefs abklären, was die so sagen. Hat mir 
aber sehr geholfen hier die verschiedenen Einschätzungen zu bekommen =)