Forum: FPGA, VHDL & Co. schnelles Schalten mit on-Chip-Lösungen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Mann Fred (Gast)


Lesenswert?

Ich poste die Frage hier, da sie eher zu FPGAs passt, als zu Controller, 
da sie sich auf den Zynq und artverwandte on-Chip-Systeme bezieht.

Ich möchte viele Ausgänge in sehr hoher Geschwindigkeit schalten und die 
Muster autark rotieren. Für Quermuster würden sich reine Schieberegister 
eigenen, für die Längsmuster allerdings brauche ich Speicher, der sich 
nicht mit Latches machen lässt. Benötigt werden 64 Ausgänge mit Daten 
für die intelligenten Schieberegister / Matrix-Zellen sowie weitere 
Steuerleitungen für die Kanäle.

Es braucht demnach eine Anordnung aus kleinen FPGAs mit internem RAM und 
vielen Ausgängen, die durch einen Master befüllt werden. Für das 
Rotieren würden die internen Block-Rams reichen, allerdings nicht für 
die Musterlänge. Dafür braucht es mindestens 4GB Speicher insgesamt. Da 
das Einschreiben in den Zwischenpausen erfolgen soll, müsste die RAMs 
schnell befüllt werden, was für alle Schalter eine Bandbreite von 1GB/s 
am RAM ergibt.

Ich bin nun für den Master auf die Zynq-Chips gekommen und fand Anbieter 
die Module haben, welche schon genug Speicher integriert haben. Ich 
kenne mich mit denen nicht aus, habe nur die Specs durchgelesen und 
stelle mir eine Frage:

Wie schnell kann das RAM tatsächlich gelesen werden? Die Bandbreiten die 
angegeben sind, werden durch das Zynq-System sicher nicht weiterzugeben 
sein. Ich frage mich vor allem, wie das funktioniert, wenn das RAM nur 
an dem Rechnerteil, nicht aber am FPGA-teil angeschlossen ist. Wie 
schnell bekommt man die Daten vom Prozessor auf die Logik um sie dann 
weiterzuverteilen?

In den User-Groups liest man von Interruppt-Zugriffen und DMA finde aber 
nirgends ein konkretes Beispiel mit realen Werten, die erzielt werden 
können.

von Gustl B. (gustl_b)


Lesenswert?

Mr. T. schrieb:
> Ich frage mich vor allem, wie das funktioniert, wenn das RAM nur an dem
> Rechnerteil, nicht aber am FPGA-teil angeschlossen ist.

Es gibt genug Module/Boards mit Zynq bei denen auch RAM am FPGA Teil 
angeschlossen ist.

von Stefan F. (stefanus)


Lesenswert?

Mr. T. schrieb:
> Es braucht demnach eine Anordnung aus kleinen FPGAs mit internem RAM und
> vielen Ausgängen, die durch einen Master befüllt werden.

Falsche Herangehensweise. Beschreibe verständlich und mit konkreten 
Zahlen (nicht "schnell"), was du machen willst. Nicht womit.

von Mann Fred (Gast)


Lesenswert?

Ich weis was ich bauen will und wie es funktionieren soll :-) Es geht in 
der Tat darum, ein ausgewähltes Modul zu verwenden, welches nur ein RAM 
angeschlossen hat und dieses eben an am "Computerteil", also der PS. Die 
Idee dahinter ist, dass der Controller, der an der PS benutzt wird, eine 
ausreichend hohe Bandbreite hat. Schaue ich mir die Specs an, sehe ich, 
dass die Verbindung zu der PL langsamer ist, weil dort FPGA-Zellen 
benutzt werden, die (meine Interpretation) offenbar weniger schnell 
arbeiten können. Das nächst passende Systemmodul das PL-Verbindung hat, 
bringt weiter noch den Nachteil mit, dass IOs verloren gehen. Es müsste 
das übernächste genutzt werden, was deutlich teurer und größer ist.

von Gustl B. (gustl_b)


Lesenswert?

Leider zu wenig Details. Welches Modul willst du verwenden? Wieso Zynq 
und nicht Spartan/Artix/... mit Microblace?
Die Anbindung zwischen PS und PL ist doch eher sehr schnell. Das ist 
zwar kein so irre hoher Takt, aber sehr breit. 128 Bit AXI oder so.

von Mann Fred (Gast)


Lesenswert?

Gustl B. schrieb:
> Spartan/Artix/... mit Microblace?
Spartan und Artix müssen mit RAMs versehen werden, wahrscheinlich müsste 
man etwas selbst konstruieren und dann bleibt das Problem der 
wegfallenden IOs. Das geht nur mit den großen Bausteinen.

> Die Anbindung zwischen PS und PL ist doch eher sehr schnell.
Wie schnell?

> Das ist zwar kein so irre hoher Takt, aber sehr breit.
> 128 Bit AXI oder so.
Der AXI liefert aber nur, was die interne Logik und die Brücke dorthin 
hergeben. So wie ich die Dokumentation verstehe, gibt es eine Brücke zu 
dem PS-System mit/per DMA-Controller. Die Dokumentation schweigt sich 
aber darüber aus, wie schnell das ist. Angenommen, das wären im 
Durchschnitt 100MHz, wären das 1,6GB/s, was reichen würde. Aber kommen 
so viele Daten?

Nehmen wir beispielsweise das "Bora-Som" oder "ALINX AC7Z020", beide mit 
einem Xilinx Zynq-7000 XC7Z020 FPGA. Die angeschlossenen RAMs haben 
theoretisch 1,6 / 2,6 GB/s. Für den zweiten Fall würde der AXI mit 100 
MHz schon nicht reichen.

Mit welchen Verzögerungen kann man bei dem DMA rechnen? Die 
Prozessorlast liegt bei unter 30% und es wäre rechnerisch möglich, die 
Arbeit des Prozessors in dem kurzen Moment, wo die Bandbreite gebraucht 
wird, auf gut die Hälfte zu senken. Die Zugriffe des Prozessors brauchen 
dann geschätzt 0,3 statt 0,5 GB/s.

Ich rechne nun einen AXI mit 150MHz. Der könnte 2,4GB/s (mehr kommt vom 
Exemplar 2 sowieso nicht). Rechnen wir 2,0. Abzüglich 0,5 bleiben 1,5. 
Davon müsste ich mindestens 70% abgekommen. Klappt das?

von Gustl B. (gustl_b)


Lesenswert?

Manni T. schrieb:
> Spartan und Artix müssen mit RAMs versehen werden, wahrscheinlich müsste
> man etwas selbst konstruieren und dann bleibt das Problem der
> wegfallenden IOs.

Auch da gibt es genug fertige Module. Auch mit vielen IOs. Es gibt auch 
kleine FPGAs mit einem großen Package und vielen IOs.

Ja sonst kann ich da leider nicht helfen. Ich weiß nicht was du vor 
hast. Woher kommen die Daten denn überhaupt? Ethernet? Werden die lokal 
errechnet? Wenn es möglich ist die Daten zu errechnen wie eine 
Sinustabelle oder so, dann geht das auch im FPGA Teil und man kann sich 
den Speicher vielleicht sparen.

von Roger S. (edge)


Lesenswert?

Reicht das Budget fuer ein UltraScale+ MPSoC Modul? Der macht die 
angestrebten 1GB/s aus dem PS DDR ohne Probleme, da geht auch mehr. Und 
nebenbei kannst du noch ein Linux laufen lassen um die Daten zu 
betanken.

von DSGV-Violator (Gast)


Angehängte Dateien:

Lesenswert?

Letztlich ist das doe Frage was der Memorycontroller an den Userports an 
Datenrate zur Verfügung stellt. Du musst also mal einen passenden 
DDR-Controller Konfigurieren, das steht in der Beschreibung der "Memory 
interface solution - MIS, früher auch MiG - Memory Interface Generator.

https://docs.xilinx.com/v/u/1.4-English/ug586_7Series_MIS

Die Angaben für den userport sind meist isochrounous über eine längere 
consecutive Blocklänge gemeint, währen DDR-RAM burstartig arbeitet, also 
nur kurze Blöcke schnell liefert, nachdem diese erst addressiert werden. 
DRAM-typisches-Refresh muss auch noch automatisiert werden. Da muss also 
einiges an Cache/Buffer-speicher dazwischen, das könnte man auch im 
Memory-controller konfigurieren. Natürlich sollte man auch ein paar 
FIFO's zwischen Memory-Controller-Userport und deinen Bitgeschubse 
einbauen.
Anbau Auszüge aus der Zynq-Doc die die Blöcke mit einer konhreten 
Realisierung der UserPorts als AXI-Stream-Interface aufzeigen.

Das Ganze ist kein triviales PLD-Gebastel, wielleicht besorgst du dir 
zuerst das kostenlose Zynq-book und arbeitest das Thema DDR-Controller 
und Grundlagen durch. Für einen FPGA-Anfänger, auch mit passender 
Uni-Qualifikation als Elektrotechniker/Informationstechnik (notfalls 
technische Informatik) wären dafür vier Wochen Intensiv anzusetzen.

https://github.com/Lauro199471/CECS-461/blob/master/The%20Zynq%20Book%20ebook.pdf

von DSGV-Violator (Gast)


Lesenswert?

Manni T. schrieb:
> Ich weis was ich bauen will und wie es funktionieren soll :-)

Dann mal ein Blockbild davon und präsentiere das hier.

von Falk B. (falk)


Lesenswert?

Manni T. schrieb:
> Ich weis was ich bauen will und wie es funktionieren soll :-)

Das ist schön für dich, aber leider vollkommen unbrauchbar für eine 
sinnvolle, technische Diskussion.
Siehe Netiquette.

> Es geht in
> der Tat darum, ein ausgewähltes Modul zu verwenden, welches nur ein RAM
> angeschlossen hat und dieses eben an am "Computerteil", also der PS.

PS?

 Die
> Idee dahinter ist, dass der Controller, der an der PS benutzt wird, eine
> ausreichend hohe Bandbreite hat. Schaue ich mir die Specs an, sehe ich,
> dass die Verbindung zu der PL langsamer ist, weil dort FPGA-Zellen

PL?

von Vancouver (vancouver)


Lesenswert?

Du müsstest mal dokumentieren, was du unter Längsmuster, Quermuster, 
intelligenten Schieberegistern und Matrixzellen verstehst. Das hört sich 
alles ganz toll nach Startrek-Technobabbel an, hat aber irgendwie keinen 
Inhalt.

Ich versuche mal etwas Struktur in das Wirrwar zu bringen. Du willst 
64bit breite Bitmuster mit hoher Geschwindigkeit aus einem Speicher 
auslesen, mit Schiebregistern hin- und her schieben und dann parallel 
über 64 Pins ausgeben. Dazu brauchst du einen großen und schnellen 
Speicher. Wie groß und wie schnell, hast du uns nicht verraten.
Bei einem Zynq kannst du den DDR-Speicher auch direkt aus der PL 
auslesen, ohne die CPU. Wie schnell das geht, hängt vom verwendeten Zynq 
ab und wie gut optimiert das FPGA-Design ist.
Ich würde mal schätzen, dass du den DDR-Speicher über die PL mit 
maximaler Geschwindigkeit auslesen kannst, zumindest bei den neueren 
Zynqs. Du könntest genauso gut z.B. einen Artix mit angeschlossenem 
DDR-Speicher nehmen, wie z.B. auf dem Arty-Board von Digilent.
Davon abgesehen kannst du noch die Blockrams der PL verwenden, wenn die 
groß genug sind. Ob sie das sind, kann dir niemand beantworten.

von DSGV-Violator (Gast)


Angehängte Dateien:

Lesenswert?

> PL?
> PS?


Ich spring mal für den TO ein...
Der Zynq als System-on-a-(FPGA)-Chip besteht in der Xilinx-Sprache aus 
zwei Teilen: PL und PS (siehe Anhang)

PL programmable-Logic (gelber Hintergrund) enzhält LUT's FF und den 
ganzen Kram die alte recken aus Zeiten von Spartan-2 bis Spartan-6 
kennen.

PS (Processing system -grauer Hintergrund) dagen bezeichnet das System 
aus (Hard-silicon)Dual-ARM-Core, diverse Priphereals (i.e I2C), dynamic 
memory controller, ..., vielen dieser Komponenten sind Pins fest 
zugeordnet.Es kann also sein das der DDR-Speicher auf einem 
Zynq-Eval-Board fest nur über das PS (eben als Speicher für die 
ARM-Core) angesprochen werden kann und nicht direkt vom (in HDL-) 
geschriebenen Memory-controller im PL-Teil.

Es gibt natürlich auch verbindungen zwischen PS und PL Teil;

 * AXI_GP ((Registerzugriff basierte general purpose) AXI-Bridges aber 
auch
 * AXI_HP_schnelle (streamfähige) Highperformance Interface eben um auch 
vom DDR um PS ans PL zu kommen. Dieser (umständliche weg übers PS) zum 
PL hat aber verständlicherweise eine höhere Latenz.

von Mann Fred (Gast)


Lesenswert?

Falk B. schrieb:
>> und dieses eben an am "Computerteil", also der PS.
> PS?
Ja, das "programmierbare System". Die Dokumentation unterscheidet PS und 
PL beim Zugriff auf den Controller.

>> die Verbindung zu der PL langsamer ist, weil dort FPGA-Zellen
> PL?
die "programmierbare Logic".

In der englischen Dokumentation sind die Begriffe im Übrigen dieselben.

Vancouver schrieb:
> Ich würde mal schätzen, dass du den DDR-Speicher über die PL mit
> maximaler Geschwindigkeit auslesen kannst
ja das würde ich auch schätzen, aber die Schaltmatritzen der AXI-Busse 
suggerieren mir eine Bandbreitenbremse. Dem Bild oben z.B. ist zu 
entnehmen, dass auf dem PHY 4 Teilnehmer arbeiten (können) während nur 2 
davon über eine Matrix an die 4 PS-Teilnehmer angeschlossen sind.

Frage der Frage: Welche Bandbreite bleibt für einen einzelnen übrig, 
wenn die anderen gerade nichts tun? Sicher keine 100%.

Ferner ist dem Diagramm zu entnehmen, dass es 64 Bit-breite Busse sind.
Das würde auch bei 250MHz nicht reichen.

> Du könntest genauso gut z.B. einen Artix mit angeschlossenem
> DDR-Speicher nehmen, wie z.B. auf dem Arty-Board von Digilent.
Das wird mit 16 Bit angeschlossen und mit 600 MHz ausgelesen. Der Zynq 
im avisierten board kann 1GHz und 32 Bit.

von DSGV-Violator (Gast)


Lesenswert?

Manni T. schrieb:
> Falk B. schrieb:
>>> und dieses eben an am "Computerteil", also der PS.
>> PS?
> Ja, das "programmierbare System".

Nein, nicht programmierbar sondern "processing System". "Programmierbar" 
ist alles auf den SoC wenn man nicht gerade ein 
Schmalspur-Software-Entwickler ist, der nur C kann.

Als unqualifizierter deutschsprachiger Halb-Laie würde man aus dem Bauch 
wohl eher zum Logic-Teil "processing (verarbeitend) sagen, das ist hier 
aber nicht gemeint. Vielleicht konzentriert man sich eher auf die 
Begriffe Logik und System. Dann ist PS das System das die Logik am 
Laufen (processing) hält. Xilinx betont das mit der Bezeichnung als 
"close coupled" SoC, während die SoftCore SoC Geschichten als loose 
coupled bezeichnet werden.

> Die Dokumentation unterscheidet PS und
> PL beim Zugriff auf den Controller.

Welcher Controller? Es gibt PL, PS und die Bridges GeneralPurpose (GP) 
und HP (high performance) dazwischen. Aber keinen Controller daneben. 
Die ARM-Cores gehören zum PS, ebenso der dynamic memory controller.

PS:
A bisserl zu den verschiedenen Möglichkeiten der Speicheranbindungen am 
Zynq wurde im dortigen thread erötert: 
Beitrag "Re: Terasic DE10-Nano & weitere Fragen" . Wobei, dort geht 
es im Retro-Computing, wo es, im Unterschied zu deinem hingekaspelten 
Systembeschreibung, keine "Zwischenpausen" im Speicherzugriff gibt.

von Mann Fred (Gast)


Lesenswert?

DSGV-Violator schrieb:
> Nein, nicht programmierbar sondern "processing System". "Programmierbar"
> ist alles auf den SoC wenn man nicht gerade ein

An einer Diskussion um die sprachlichen Spitzfindigkeiten möchte ich 
mich nicht beteiligen. "processing" oder nicht - der folgende Satz ist 
sicher nicht richtig interpretiert:

DSGV-Violator schrieb:
> Dann ist PS das System das die Logik am
> Laufen (processing) hält.
Die Logik läuft auch ganz alleine, ohne dass die Prozessoren aktiviert 
sind.

DSGV-Violator schrieb:
> AXI_HP_schnelle (streamfähige) Highperformance Interface eben um auch
> vom DDR um PS ans PL zu kommen. Dieser (umständliche weg übers PS) zum
> PL hat aber verständlicherweise eine höhere Latenz.
Die Latzen wäre zu verkraften. Alles was unter 2-3ms liegt, ist im 
externen Bereich transparent. Es geht ausschließlich um die Bandbreite.

Ich habe den Hersteller kontaktiert um eine Aussage zu bekommen. Diese 
lautet, dass die Bandbreite für unsere Anwendung nicht reicht, und ein 
alternatives Modul angeboten, das in Entwicklung ist und welches passt.

Der Hersteller ist im Übrigen sehr deutlich mit der Firma X ins Gericht 
gegangen, was Qualität an Dokumentation anbelangt und die Verprechungen, 
die selbige macht.

von DSGV-Violator (Gast)


Lesenswert?

> Der Hersteller ist im Übrigen sehr deutlich mit der Firma X ins Gericht
> gegangen, was Qualität an Dokumentation anbelangt und die Verprechungen,
> die selbige macht.


Dann haste ja die für Dich bequemste Antwort bekommen, Xilinx ist Schuld 
und du hast alles richtig gemacht ...

IMHO die Lösung dagegen ein Blockbild, das genau zeigt, wie die Daten 
durch die Daten-senken/quellen fliessen sowie eine Spezifikation der 
erforderlichen Datenraten.

Ein Anfang wäre bespielsweise nachvollziehbar aufzu zeigen, wie man 
aus den Angaben von 64 ausgängen und 4 GB Speicher auf 1 Gbit/s 
Transferate kommt um dann später zu behaupten, die wären nicht 
erreichbar.

(Nur mal so als Beispiel schon mit Spartan6 & Co kann man Videauausgaben 
realisiern, die rechnerisch eine Transferrate von 10 GBit/s ergeben:
Beitrag "HDMI Signalaufbau/Pinbelegung")


Daraus könnte man dann eine erste Implementierung in Vivado 
zusammklicken. Das erfordert, das man die Turorials abarbeitet und es 
hilft sich mit 3rd party literatur wie dem Zynq-book 
auseinanderzusetzen. Dazu bedarf es aber mehr als ein Wochenende und ein 
paar unillustrierte Beiträge in einem Hobbyisten-Forum.

von Mann Fred (Gast)


Lesenswert?

DSGV-Violator schrieb:
> Dann haste ja die für Dich bequemste Antwort bekommen, Xilinx ist Schuld
> und du hast alles richtig gemacht ...
Bitte korrekt lesen: Das war die Aussage des Modulkartenherstellers. Der 
plagt sich mit der XI-Dok herum und hat Supportanfragen laufen.

Ich nehme das natürlich zur Kenntnis und deshalb muss beim Planen 
solcher Systeme zuvor etwas gerechnet werden.

> IMHO die Lösung dagegen ein Blockbild, das genau zeigt, wie die Daten
> durch die Daten-senken/quellen fliessen
das liegt vor, wird aber hier sicher nicht pubiliziert!

> sowie eine Spezifikation der erforderlichen Datenraten.
Siehe Eingangspost: Die erforderliche Datenrate wurde berechnet:

Manni T. schrieb:
> was für alle Schalter eine Bandbreite von 1GB/s
> am RAM ergibt.

-> 1 GBps am RAM sind Man(n)ifest.

> Ein Anfang wäre bespielsweise nachvollziehbar aufzu zeigen, wie man
> aus den Angaben von 64 ausgängen und 4 GB Speicher auf 1 Gbit/s
> Transferate kommt
ist im internen Dokument genauestens gezeigt.

> (Nur mal so als Beispiel schon mit Spartan6 & Co kann man Videauausgaben
Dieses Beispiel ist keines, weil es sich auf die Ausgaben mit 
Transceivern bezieht. Woher die Daten kommen, bleibt offen. Der Spartan 
war zudem kein SOC, sondern hatte die RAMs direkt angeflanscht, wenn ich 
mich richtig entsinne.

Es muss also nicht geprüft werden, ob meine 1GBps richtig sind, sondern 
ob und mit welchem Steckkartenmodul sie erzielbar sind.

Und natürlich muss es wie immer das billigste sein.

von Gustl B. (gustl_b)


Lesenswert?

Wieso kein Spartan/Artix/Kintex mit uBlaze und mehreren DRAM Kanälen?

von Mann Fred (Gast)


Lesenswert?

Weil auf Spartanen mit Softcores kein Linux effektiv läuft und Kintex 
viel zu teuer ist. Ist alles geprüft und quergecheckt. Der Zynq ist 
gesetzt.

Es ging mir hier nur um einen eventuellen Tipp von jemandem, der sich 
zufällig auskennt, mit welchen Datenraten man rechnen kann. 
Möglicherweise ist das einfach das falsche Forum für solche 
anspruchsvollen Fragen.

Das Thema ist erledigt. Module sind geordert!
Es gibt aber ein Anschlussthema:
Beitrag "Lebensdauerverlängernde Maßnahmen für Flash-LEDs"

von DSGV-Violator (Gast)


Lesenswert?

Manni T. schrieb:
> Weil auf Spartanen mit Softcores kein Linux effektiv läuft und Kintex
> viel zu teuer ist. Ist alles geprüft und quergecheckt. Der Zynq ist
> gesetzt.
>
> Es ging mir hier nur um einen eventuellen Tipp von jemandem, der sich
> zufällig auskennt, mit welchen Datenraten man rechnen kann.

Diese Frage hast Du nie gestellt und diese Frage stelltsich Dir auch 
nicht.
Deine Frage wäre gewesen: "wie und welche erreiche LED-Schaltraten 
(Bereich <= 10 Mbit/sec erreicht man über ein LowCost FPGA?"

Bei OSRAM in München hab ich vor ca. 10 Jahren mal dergleichen gesehen, 
die technische Herausforderung ist nicht die Ansteuerung sondern das 
Schalten des Laststromes. LIDAR war da auch im Gespräch. Der Prototyp 
war wohl ein Virtex weil das aufgekaufte (Schwedische?) StartUp ein 
solches verwendet hat.

Aktuell findet man Publlikationen aus dem Chinesischen Kanton: 
https://www.mdpi.com/2073-8994/14/6/1256
und mit ein bißchen Gehirnschmalz sicher noch weitere. Wobei deren 
Schwerpunkt eher das DSP nach dem RX ist und nicht das bisserl 
TX-Steuerung wie hier angefragt.


> Möglicherweise ist das einfach das falsche Forum für solche
> anspruchsvollen Fragen.

Eher ist die Formulierung eine verständlichen Frage für Dich zu 
anspruchsvoll.
Vielleicht weil es hier eben nicht um reine Ja/Nein Frage geht sondern 
um den Entwurf eine Architektur unter Berücksichtigung mehrerer 
IC-Varianten und Bewertung derselben geht.Um die "dritte Meinungen" 
abzufragen, muss man eben wenigstens Blockbilder der Varianten vorlegen.

von Gustl B. (gustl_b)


Lesenswert?

Manni T. schrieb:
> mit welchen Datenraten man rechnen kann.

Zwischen PS und PL ist AXI und schnell, aber je nachdem was du im PS 
machst limitiert dann auch die CPU. Wenn es nur vom RAM an IOs gehen 
soll dein Muster, dann nimm doch ein Board mit schnellem/mehreren RAMs 
am PL selbst. Dann ist der Durchsatz klar aus dem Datenblatt 
ersichtlich.
Dort steht noch etwas dazu:
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842244/Zynq-7000+AP+SoC+Performance+Benchmarks

Manni T. schrieb:
> Weil auf Spartanen mit Softcores kein Linux effektiv läuft

Und das brauchst du zwingend? Außerdem gibt es Softcores mit RISCV und 
Linux.

von DSGV-Violator (Gast)


Lesenswert?

>> Weil auf Spartanen mit Softcores kein Linux effektiv läuft
>
> Und das brauchst du zwingend? Außerdem gibt es Softcores mit RISCV und
> Linux.

Naja, die Aussage "kein Linux läuft darauf effektiv " kann man 
kommentarlos in die Tonne kloppen.

Was meint effektiv ? Das erste Linux lief auf einem i386-PC mit 4 
MByte und 33MHz, einen mikroblaze auf einem Spartan kann man locker mit 
80 MHz takten.

Letzlich braucht man nur ein bisserl Shell und console, da braucht es 
kein HiPerformance ServerLinux mit deepPaketInspection und HeavyDuty 
WebServer.

Bitte 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
Noch kein Account? Hier anmelden.