www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Xilinx FPGA + micro Linux


Autor: eugler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

innerhalb unserer Arbeitsgruppe versuchen wir uns an Softcores. 
Mittlerweile haben wir den Microblaze (da alles Xilinx, XUP) gut im 
Griff. Jetzt hatten wir mal recherchiert, inwiefern da ein Linux drauf 
läuft. Bei Xilinx direkt wird das BlueCat Linux angeboten, welches für 
eine Uni aber defakto viel zu teuer ist.

Hier nun die Fragen:
Kennt jemand eventuell eine OS Portierung? Wie kann man jene ins EDK 
einbinden (wahrscheinlich eher nicht)? Gibt es fertige Ports für den 
MicroBlaze? Wie kann man eigene Hardware Treiber (zB. GPIO Lämpchen ;-) 
) in den Kernel implementieren?

Für Anregungen wäre ich sehr dankbar.

Eugi

Autor: BOM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RTOS gibt es einige (auch freie)...
Schau mal hier: http://www.xilinx.com/ise/embedded/epartners/listing.htm

Wenn ich dran denke kann ich Montag auf der Arbeit mal nach einer 
schöneren Übersicht schauen...

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schlecht recherchiert sag ich da nur. Klar, wenn ihr die 
"one-click-bauchpinsel-und-hintern-abwisch"-Suites nehmen wollt, kostet 
das was. Die können/dürfen aber eben nur für Services und Tools Geld 
verlangen. Der Kernelsource und die Laufzeitumgebung sind zwangsweise 
GPL und damit kostenlos.

Nur mal so ein gaaanz kleiner Hint: Lad dir einen aktuellen 
2.6er-Kernelsource und schau in den arch-Ordner ;)

Auch das hier könnte möglicherweise helfen:
http://www.uclinux.org/

Und wenn es die Bauchpinsel-Lösung sein soll:

http://www.petalogix.com/

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur als Hinweis: Mir fällt gerade ein, dass ich mal irgendwo gelesen 
hatte, dass man für größere OS und MicroBlaze auch externen RAM braucht, 
da der interne BRAM nicht mehr ausreicht. Vielleicht könnte jemand, der 
mehr Erfahrung hat auch etwas dazu sagen. Würde mich auch interessieren, 
in welchen Fällen man mit dem internen BRAM auskommt.

eugler schrieb:

> Jetzt hatten wir mal recherchiert, inwiefern da ein Linux drauf
> läuft.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist das nicht das MontaVista Linux, was die bei den Xilinx Boards immer 
mal einsetzen? Ich hatte sowas mal auf dem ML405 getestet, naja, ging 
schon, aber war ein Kampf bis dahin. Leider ist das schon mehr als 3 
Jahre her, da weiß ich nicht mehr viel drüber...

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> dass man für größere OS und MicroBlaze auch externen RAM braucht,
> da der interne BRAM nicht mehr ausreicht. Vielleicht könnte jemand, der
> mehr Erfahrung hat auch etwas dazu sagen.

Sicher braucht man für Linux externes RAM. Da der Kernel allein schon so 
1-1.5MB gross ist, sind für vernünftiges Arbeiten 8MB wohl die 
Untergrenze. Mit Mühe gehen evtl. auch 4MB, das hat dann aber vom 
Look&Feel nicht mehr viel mit Linux zu tun...

> Würde mich auch interessieren,
> in welchen Fällen man mit dem internen BRAM auskommt.

Wenn man kein Betriebssystem hat ;) Ein reiner Scheduler braucht nicht 
viel Platz, aber wenn es dann mit Filesystemen und Netzwerk losgeht, 
sind solche Sparsysteme dann bei der Entwicklung eher hinderlich.

> Ist das nicht das MontaVista Linux, was die bei den Xilinx Boards immer
> mal einsetzen?

Bei der PPC-Variante. Der Microblaze hatte recht lange keine MMU, 
deshalb das uCLinux.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Georg A. schrieb:

> Wenn man kein Betriebssystem hat ;) Ein reiner Scheduler braucht nicht
> viel Platz, aber wenn es dann mit Filesystemen und Netzwerk losgeht,
> sind solche Sparsysteme dann bei der Entwicklung eher hinderlich.

Danke für die Info Georg! Meine Idee ist, in Zukunft ein altes Microchip 
PIC Projekt (64 KB Program Memory) mit MicroBlaze mit einfachem 
Scheduler oder sogar mit Endlosschleife zu realisieren. Der Microblaze 
wird dann mit einem LCD und einigen ADC-Interfaces in VHDL 
kommunizieren. Kannst Du mir da einen Spartan-3A/E empfehlen, ab dem 
sich das ganze implementieren lassen würde?

Danke,
Anguel

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Microblaze-Core allein braucht je nach Konfig ca. 10-15% eines 
3S1600E. Kleinperipherie (UART, TIMER, GPIO, evtl. auch ein Interface zu 
SRAM/Flash) kostet noch ein paar % mehr. D.h. das SOC würde schon in 
einen 3S500E bequem reingehen. Der 1600E hat aber nur 36*2KB=72K 
Blockram, kommt mir da schon knapp vor. Wie das Codeverhältnis 
Microchip/Microblaze wirklich ist, kann ich nicht beurteilen, mit war 
der PIC immer zuwieder. Der MB hat trotz RSIC sicher mächtigere Befehle, 
erst recht wenn es mehr als 8Bit-Rechnung ist, aber die sind halt auch 
32Bit lang...

Autor: eugler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Georg A. schrieb:
> Auch das hier könnte möglicherweise helfen:
> http://www.uclinux.org/

Danke für die vielen Inspirationen. Das uLinux Projekt war mir nicht 
geläufig. Das scheint aber genau das zu sein, was wir brauchen. Nach 
einer ersten Übersicht ist da der MB als Schalter beim Kernel bauen ja 
auch schon drin.

> Und wenn es die Bauchpinsel-Lösung sein soll:
>
> http://www.petalogix.com/

Naja, die EDK Integration der Linux Distribution muss nicht unbedingt 
sein, auch wenn ich beim System-Bauen nicht darauf verzichten möchte (da 
wir keine FPGA bzw. VHDL Cracks sind).

Also, Vielen Dank.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die ausführlichen Infos Georg! Es ist echt super, eine 
konkrete Vorstellung von den Anforderungen zu haben. Andererseits ist es 
doch ernüchternd, dass ein größerer PIC doch mehr Speicher als ein FPGA 
bietet ;) Andererseits habe ich auch gesehen, dass man die Progs wohl 
auch vom Flash ausführen kann, wenn man keine hohen Geschwindigkeiten 
braucht:
http://www.xilinx.com/support/answers/23748.htm
Ob das in der Praxis was taugt, und ob das mit dem internen Flash eines 
3AN läuft, müsste man wohl austesten.

Georg A. schrieb:
> Der Microblaze-Core allein braucht je nach Konfig ca. 10-15% eines
> 3S1600E. Kleinperipherie (UART, TIMER, GPIO, evtl. auch ein Interface zu
> SRAM/Flash) kostet noch ein paar % mehr. D.h. das SOC würde schon in
> einen 3S500E bequem reingehen. Der 1600E hat aber nur 36*2KB=72K
> Blockram, kommt mir da schon knapp vor. Wie das Codeverhältnis
> Microchip/Microblaze wirklich ist, kann ich nicht beurteilen, mit war
> der PIC immer zuwieder. Der MB hat trotz RSIC sicher mächtigere Befehle,
> erst recht wenn es mehr als 8Bit-Rechnung ist, aber die sind halt auch
> 32Bit lang...

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anguel S. schrieb:
> Andererseits ist es
> doch ernüchternd, dass ein größerer PIC doch mehr Speicher als ein FPGA
> bietet ;)

Naja, 64kByte RAM auf einem PIC ist schon doch was anderes als 64kByte 
DualPort BlockRam im FPGA, der mit 300+ MHZ laufen kann. Der BlockRAM 
ist leider das teuerste an den FPGAs. Daher sollte man möglichst 
externen SDRAM anschließen.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beim PIC ist es nicht mal RAM, sondern Programm-Flash :) Schade 
eigentlich, ich wollte das alte PIC Design um einige schnelle 
Peripherals in VHDL ergänzen und dachte, dass da eine Single-Chip Lösung 
mit FPGA und MicroBlaze möglich wäre. So wie es aussieht, braucht man da 
aber wohl doch externen RAM :( Ist es eigentlich beim Spartan-3AN 
einfach und üblich, aus dem internen Flash z.B. Strings während des 
Programmablaufs in den RAM einzulesen, oder ist der Flash nur dazu 
gedacht, den Programmcode beim Start des FPGAs einmal reinzuladen?

Christian R. schrieb:

> Naja, 64kByte RAM auf einem PIC ist schon doch was anderes als 64kByte
> DualPort BlockRam im FPGA, der mit 300+ MHZ laufen kann. Der BlockRAM
> ist leider das teuerste an den FPGAs. Daher sollte man möglichst
> externen SDRAM anschließen.

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ist es eigentlich beim Spartan-3AN einfach und üblich, aus dem
> internen Flash z.B. Strings während des Programmablaufs in den RAM
> einzulesen, oder ist der Flash nur dazu gedacht, den Programmcode
> beim Start des FPGAs einmal reinzuladen?

Du bist definitiv PIC-verseucht... Wenn im FPGA ein Microblaze läuft, 
ist es dem piepegal, woher er seine Befehle oder seine Daten bekommt, 
solange sie über den Speicherbus kommen. Es gibt keine unterschiedlichen 
MOVEs für Flash vs. RAM... Wo da in dem Adressbereich welcher Speicher 
sitzt, ist dir überlassen. Oft wird aber ein kleiner Teil des Blockrams 
als Bootloader ab Adresse 0 benutzt (heisst dann LMB und erlaubt 
maximale Geschwindigkeit).

Es ist auch möglich, das externe Flash für Bitstream und CPU-Daten 
gleichzeitig zu nutzen. Man kann der Konfiguration sagen, dass sie von 
"oben" her das Flash auslesen soll, während die CPU danach normal von 
unten her bootet.

Autor: eugler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Georg A. schrieb:
> Es ist auch möglich, das externe Flash für Bitstream und CPU-Daten
> gleichzeitig zu nutzen. Man kann der Konfiguration sagen, dass sie von
> "oben" her das Flash auslesen soll, während die CPU danach normal von
> unten her bootet.

Hm, da muß ich als Laie doch nochmal reinhaken (aus Unverständnis ;-)). 
Muss denn der "Bitstream", also die FPGA Konfiguration nicht eh auf 
einem Nicht-Flüchtigem Speicher, sprich Flash, liegen? Gleich im 
Anschluß die Frage: Macht der CoolRunner auf dem Spartan 3E Starter Kit 
das Management des selbigen? Das OS kann man dann doch auch auf den 
Flash legen, bzw. einen Loader, der es zB. von einer CF Karte liest. Der 
DDR RAM kann doch dann dem MB für Heap bzw. Stack zur Verfügung gestellt 
werden. Immerhin kann er 32 Bit Adressieren, oder?

PS: Mich bitte nicht gleich zerreißen, wenn irgendwas inhaltlich falsch.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.