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