Hallo an das Forum, mich würde interessieren ob es bereits Betriebssysteme gibt, die einen Fpga-Baustein bereits von Haus aus integrieren um die Leistung des Gesamtsystems zu steigern. Wenn ja wie ausgereift ist dies und wie sind da die Erfahrungen ? Gruss Andre
FPGAs sind Logikbausteine die zu Schaltungen "zusammengebaut" werden können. Also arbeitet man mit reiner Hardware. Es gibt kein Betriebssystem. Man kann aber einen Mikrocontroller aufbauen und dann auf diesen z. B. ein RT-System laufen lassen.
Walleby schrieb: > FPGAs sind Logikbausteine die zu Schaltungen "zusammengebaut" werden > können. Also arbeitet man mit reiner Hardware. Es gibt kein > Betriebssystem. Man kann aber einen Mikrocontroller aufbauen und dann > auf diesen z. B. ein RT-System laufen lassen. Das war nicht die Frage
Andre schrieb: > mich würde interessieren ob es bereits Betriebssysteme gibt, die einen > Fpga-Baustein bereits von Haus aus integrieren um die Leistung des > Gesamtsystems zu steigern. Wenn ja wie ausgereift ist dies und wie sind > da die Erfahrungen ? Also es gibt Hardware die ein Betriebssystem unterstützen, bspw. die MMU. Die MMU ist seit langen in die CPU integriert. Zu den Zeiten als das noch nicht so war, hat man sich eine MMU als "Coprozessor" selbst zusammengelötet um damit eine vernünftige Speicherorganisation für das Multitask-OS zu realisieren. Standardbeispiel ist die SUN-1 von 1982. OB die MMU in PLD oder ASIC realisiert wurde kann ich grad nicht sagen, andert aber nicht an dem OS-Coprozessor Prinzip. Aber vielleicht meinst du HIL - "Hardware in the loop". -> http://en.wikipedia.org/wiki/Hardware-in-the-loop_simulation MfG,
Vielleicht hat der TO nach sowas gesucht: http://newsroom.intel.com/community/de_de/blog/2014/06/20/kurzmeldung-erste-intel-xeon-prozessoren-mit-field-programmable-gate-arrays-fpga
123abc schrieb: > Vielleicht hat der TO nach sowas gesucht: > http://newsroom.intel.com/community/de_de/blog/2014/06/20/kurzmeldung-erste-intel-xeon-prozessoren-mit-field-programmable-gate-arrays-fpga Naja CPU und FPGA in einen Chip ist keine Erfindung von intel sondern ein alter Hut. Bspw. Xilinx VirtexPro, fürs kleine 8 bit Geschäft der FPLSIC von Atmel oder 32 bit die SmartFusion2-Familie von Actel. MfG,
Ergänzend vielleicht noch die PSoC von Cypress, als 8051er oder Cortex-M0/M3. Kein vollwertiges FPGA in dem Sinne, aber das "drumrum", sprich Spannungsversorgung etc ist wesentlich weniger aufwendig als bei einem FPGA mit integrierter MCU. Ralf
Fpga Kuechle schrieb: > Bspw. Xilinx VirtexPro, fürs kleine 8 bit Geschäft der > FPLSIC von Atmel oder 32 bit die SmartFusion2-Familie von Actel. Oder aktuell der Xilinx Zync oder von Altera gibts Arria und Cyclon V mit zwei ARMEN drin.
Oh man. Kann niemand mehr eine Frage lesen und verstehen? Gibt es FPGA-beschleunigte OS? Wenn ja welche?
danke für die zahlreichen Posts. David und 123abc... konnte die Frage richtig einordnen... Es geht darum ob es Betriebssysteme mit gewissen Erweiterungen gibt (zb Linux, Andriod, VxWorks oder vielleicht andere), welche die Möglichkeiten bieten das Gesamtsystem in eine bestimmte Richtung hin zu optimieren. Wie weit ist die Forschung im Bereich der Betriebssystem, um zB Techniken wie dynamische Rekonfiguration vom Betriebssystem zu steuern. Gruß Andre
Andre schrieb: > danke für die zahlreichen Posts. > > David und 123abc... konnte die Frage richtig einordnen... > > Es geht darum ob es Betriebssysteme mit gewissen Erweiterungen gibt (zb > Linux, Andriod, VxWorks oder vielleicht andere), welche die > Möglichkeiten bieten das Gesamtsystem in eine bestimmte Richtung hin zu > optimieren. > > Wie weit ist die Forschung im Bereich der Betriebssystem, um zB > Techniken wie dynamische Rekonfiguration vom Betriebssystem zu steuern. > > > Gruß Andre Es ist sicher nicht genau das, was Du suchst und hat auch keinen wissenschaftlichen Anspruch, aber hier: http://acp.atari.org/ gibt's ein Projekt, das mit einem Coldfire V4 und einem Cyclone III einen Atari-Falcon Computer "in schneller" nachbildet. Der FPGA übernimmt dabei die Aufgabe, die "alte" Hardware (mit Ausnahme des Prozessors) nachzubilden und die Inkopmatibilitäten zwischen Coldfire MCU und MC68030 soweit wie möglich auszubügeln.
was ist eine dynamische rekonfiguration des betriebssystems? ein betriebssystem teilt tasks rechenzeit zu. mehr macht ein OS nicht. was die einzelnen tasks machen ist dem OS relativ wurst. wenn du dir für deinen anwendungsfall eine hardware auf dem fpga-board konfigurierst und in einer task diese verwendest (sei es in dem du deinen eigenen compiler verwendest, der speziell auf deiner hw lauffähigen code erzeugt, oder etwas profaner einfach mit der harware kommuniziert), dann ist das vollkommen unabhängig vom betriebssystem. und das ist auch gut so.
iizi schrieb: > was ist eine dynamische rekonfiguration des betriebssystems? ein > betriebssystem teilt tasks rechenzeit zu. mehr macht ein OS nicht. An der TU-Wuppertal findet sich ein Thema zu diesen cluster aus buzzwords. Da ist von Rekonfiguration und Hardware-Betriebssystem die Rede. Das mit der Anpassung an Latenzen beim Managment von datenverkehr klingt logisch: http://www.lfa.uni-wuppertal.de/lfa/forschung/dynamische-rekonfiguration.html Ebenso wäre denkbar das Task scheduling zu optimieren, also einen Wechsel von Prioritäten durch Hardware (i.e. Packet Header Parser, IO-Port activity estimator) abschätzen zu lassen. MfG,
Fpga Kuechle schrieb: > Ebenso wäre denkbar das Task scheduling zu optimieren, also einen > Wechsel von Prioritäten durch Hardware (i.e. Packet Header Parser, > IO-Port activity estimator) abschätzen zu lassen. weiß man nicht bereits bei kompilierzeit welche task welche ressource benötigt? dann kann kann man doch ganz klassisch der ressource ebenfalls eine priotät geben und die taskpriorität auf die ressorucenpriorität anheben, solange die task die ressource benötigt? wenn nun ein paket kommt dann verlangt die task die ressource "packet header parser" und die task erbt dessen prio. warum sollte man die priortät dynamisch zur laufzeit abschätzen wollen? oder verstehe ich das falsch?
Die Hersteller kann man in 2 Lager aufteilen: das eine sind die klassische FPGA-Hersteller, die CPUs integrieren, das andere CPU-Hersteller, die FPGAs als Erweiterung integrieren (im Prinzip eigentlich das gleiche, die Hersteller haben aber unterschiedliche Zielseztungen). Meiner bescheidenen Erfahrung nach sind aber bei beiden die FPGAs nur als Device-Erweiterung zu sehen (bzw. von Hersteller so geplant), die sich sogar dynamisch d.h. zur Lauffzeit aufspielen lassen. Aber eine direkte Erweiterung bzw. Unterstützung von OS-Kernaufgaben habe ich (leider) noch nicht gesehen. Vom ersten Lager wirst du da auch nichts sehen, die sind schliesslich weit entfernt von der OS-Entwicklung. Aber such vlt. mal nach Intel/Atom, da gab's in den letzten Jahren mal ein paar Chips. Ein Blick in die Doks hilft dir vlt. weiter.
iizi schrieb: > Fpga Kuechle schrieb: >> Ebenso wäre denkbar das Task scheduling zu optimieren, also einen >> Wechsel von Prioritäten durch Hardware (i.e. Packet Header Parser, >> IO-Port activity estimator) abschätzen zu lassen. > > weiß man nicht bereits bei kompilierzeit welche task welche ressource > benötigt? dann kann kann man doch ganz klassisch der ressource ebenfalls > eine priotät geben und die taskpriorität auf die ressorucenpriorität > anheben, solange die task die ressource benötigt? wenn nun ein paket > kommt dann verlangt die task die ressource "packet header parser" und > die task erbt dessen prio. warum sollte man die priortät dynamisch zur > laufzeit abschätzen wollen? > oder verstehe ich das falsch? Angenommen wir haben mehrer gleichberechtigte Kanäle auf denen zufällig verteilt messages aus header und daten einlaufen. Die Datenpakete werden abgeholt und geparst sobald sie vollständig eingelaufen sind. Die messages haben unterschiedliche Prio bspw nach der Kritikalität des events das sie signalisieren. Diese prio ist im header vermerkt. parst man nun die header in einem nebenläufigen Prozess bspw auf extra hardware, können die zeitkritischen messages aussortiert werden, bevor die gesamte Message decodiert wurde. MfG,
Andre schrieb: > mich würde interessieren ob es bereits Betriebssysteme gibt, die einen > Fpga-Baustein bereits von Haus aus integrieren um die Leistung des > Gesamtsystems zu steigern. Mir ist dazu nix bekannt. Die bekannten Betriebssysteme setzen auf x86- und/oder ARM-Architekturen auf. Da bei den CPUs bisher keine FPGA-Erweiterung on-chip ist, kann auch niemand eine Unterstützung dafür programmieren. Oder hast Du an sowas wie Pif gedacht: http://www.heise.de/hardware-hacks/meldung/Pif-FPGA-fuer-den-Raspberry-Pi-1976232.html Daniel
Andre schrieb: > Wie weit ist die Forschung im Bereich der Betriebssystem, um zB > Techniken wie dynamische Rekonfiguration vom Betriebssystem zu steuern. Da war leider schon mal weit vor dem Ende des letzten Jahrtausends die Debatte bei den Transputern. Da wurden mit Links Netze aufgespannt, und jeder Knoten in diesem Netz konnte (theoretisch) von seinem Nebensitzer mit Daten versorgt werden und einen Teil der Gesamtaufgabe lösen. Leider war damals schon dieser relativ einfache Ansatz (man hätte nur die Rechenaufgaben parallelisieren müssen) zu viel für die Softies und so war dann nach gerade mal einer Dekade Schluss für diese Architektur. Mit der dynamischen Rekonfiguration von FPGAs verhält es sich m.E. ähnlich: die Hardware kann es, die Software und die Programmierer sind noch nicht reif dafür. Bestenfalls im absoluten High-End-Bereich oder im Akademiebereich tut sich da was. Nur eben nicht genug für den allgemeinen und problemlosen Einsatz...
Eine lange verschollen geglaubte Synapse hat sich bei diesem Thema wieder aktiviert. Es gab mal eine Französische Firma, die einen PDA angekündet hatte, der zusammen mit einem grossen FPGA sehr schnell (wenn nötig) und eine lange Bereitschaftszeit (wenn nicht benutzt) haben soll. Kombiniert optional mit einem E-Paper Display. 2004 tönte das wie Science-Fiction :-) Das Internet hat schon fast alles vergessen zu diesem Gerät, gut möglich, dass es auch gar nicht auf den Markt kam und der Firma vorher das Geld ausging. Was ich noch (un)brauchbares gefunden habe zum Jackito-PDA: http://radio-weblogs.com/0105910/categories/sidebars/2004/07/12.html http://compgroups.net/comp.arch/a-new-kind-of-architecture-for-a-new-pda/226303 Die wollten auch ein eigenes OS machen, dass die Möglichkeiten des rekonfigurierbaren FPGAs auch ausnutzen kann.
iizi schrieb: > was ist eine dynamische rekonfiguration des betriebssystems? ein > betriebssystem teilt tasks rechenzeit zu. mehr macht ein OS nicht. > > was die einzelnen tasks machen ist dem OS relativ wurst. Du denkst wie ein Hardware oder OS-Kernel Entwickler (nichts schlechtes daran). Ein Applikationsentwickler sieht das anders :-) Ein Applikationsentwickler ist sich gewöhnt das ein OS ganz viele Sachen anbietet die er nutzen kann: - Taskverwaltung - Eventhandling - Uhrzeit/Datum und Timers - Netzwerkfunktionen - Funktionen zum 2D und 3D "malen" - Teilweise ganze Datenbanksysteme die "einfach so" vorhanden sind (Newton, Palm OS, IBM AS400,...) - Audio und Video aufnehmen, abspielen durch Plug-ins routen etc. - Eine bunte IDE mit allem was man heute erwarten darf (FPGA Entwickler fangen nicht mal an von solchen Features zu träumen...) Aus dieser hohen Sicht herunter, gibt es schon Aufgaben und Operationen, die ein OS beschleunigen könnte, wenn es bei Bedarf Routinen in einen FPGA packen kann. Leider sieht die Realität seit Jahren anders aus. Aus meiner Sicht sind diese Gründe sicher auch daran Schuld: - Die ganze Geheimniskrämerei der FPGA Hersteller speziell zum Thema dynamisches rekonfigurieren - Die meisten Teile eines komplexen OS (mit den obigen Features) werden von Leuten entwickelt, die Hardware als fix gegebene "Black Magic" annehmen Das Thema ist spannend aber man sieht schon bei den ganzen Versuchen von AMD mit dem Heterogenous-Computing (Zusammenfassen von CPU und GPU Kernen zu einem grossen Rechenwerk) wie schwierig es ist, Anwender zu finden die das wirklich nutzen wollen (und können).
Hallo zusammen, mal eine Frage: welche Ressourcen sollen denn bitte auf den FPGA ausgelagert werden, damit ein 'hardwarebeschleunigtes Betriebssystem' Nutzen davon ziehen kann? Möchte ernsthaft jemand einen Low-Latency-Scheduler auf einem FPGA haben, der weitaus niedriger getaktet ist als ein Universalprozessor und wo durch den Kommunikationsoverhead zum FPGA die CPU ausgebremst wird? Und das in der zentralen Komponente des Betriebssystems? Also liebe Leute, ich mach ja gerne jeden Blödsinn mit, aber hier erschließt sich mir der Nutzen nicht. Einzig vorstellbare Anwendung: der FPGA ist wirklich um Größenordnungen schneller als die eigentliche CPU und füttert diese extern mit Instruktionen wie 'ne Art Speichercontroller. Dann ist aber auch die Frage, ob das nicht eher was für die Galerie als für die Praxis ist — ich möchte mal sehen, wer am Prozessor als Bauteil jeden Cent spart und dann 'ne hochgetakteten FPGA daneben auf's Board klatscht. Für nützliche Anwendungsfälle wie z.B. SDR oder sowas, wo ein FPGA-basierter Spezialprozessor (z.B. mit DSP-Blocks) wirklich soviele Daten zu kloppen hat, dafür gibt es ja bereits Lösungen (siehe HackRF). Aber das hat abgesehen vom Treiber nix mit dem eigentlichen Betriebssystemkern zu tun. Als Ergänzung um per DMA große einheitliche Daten zu crunchen, gerne. Sonst ist einfach die Kommunikation zu teuer, es sei denn der FPGA hostet den Prozessorkern (wobei da auch noch nicht raus ist, ob die Kommunikation da wirklich günstig ist). Meine Antwort: nö, gibt's nicht, weil's keinen Sinn macht. Ich lasse mich da aber auch gerne eines besseren belehren.
Hier der Interne Aufbau von Virtex FPGAs um eigene Toolchains zu Entwickeln inclusive Place and Route sowie mapping. Halt die Komplette Architektur: http://www.xilinx.com/support/documentation/application_notes/xapp151.pdf Gabs mal mit den Virtex FPGAs, für die war noch der gesammte Bitstream offengelegt und man konnte sich selber Routing und mapping Tools dafür schreiben. Damit konnte man zur laufzeit einen Algorithmus Parallelisieren und in Hardware gießen mit dem FPGA als Beschleuniger. Wenn der Beschleuniger fertig war konnte man das FPGA einfach mit einem neuen Design laden und erneut einen anderen Beschleunigten Algorithmus parallelisieren. Als Frontend gab es dafür noch JBits: http://users.utcluj.ro/~baruch/resources/JBits/JBitsMAPPLD.pdf
Achso und hiermit kann man den Bitstream zurücklesen die Ergenbnisse aus den FlipFlops holen, veränderungen vornehmen und zurückschreiben bzw. neues Design draufladen und weiterrechnen bzw. ergebnisse aus der Letzten berechnung in die FlipFlops laden. http://www.xilinx.com/support/documentation/application_notes/xapp139.pdf
wenn ich ein Betriebssystem habe, das auf einer Hardware läuft, wo die CPU Pins toggled um ein VGA Signal zu erzeugen und ich das Pinwackeln dann in ein FPGA packe um die CPU zu entlasten, ist dann das Kriteium für ein OS mit FPGA Beschleunigung erfüllt ? Wenn ja, dann kann man jedes IC im PC durch FPGAs ersetzen und dadurch "beschleunigen". Onboard Soundkarte durch Virtex6 mit DSP Funktion für Audio ersetzen und schon beschleunigt. Ist hoffendlich offensichtlich, warum das nicht gemacht wird in der Breite der Möglichkeiten. Gruß, dasrotemopped.
Markus Horbach schrieb: > dann in ein FPGA packe um die CPU zu entlasten, ist dann das Kriteium > für ein OS mit FPGA Beschleunigung erfüllt ? Wenn ja, dann kann man > jedes IC im PC durch FPGAs ersetzen und dadurch "beschleunigen". Das macht schon Sinn, z.B. um einen alten Chip an moderne Hardware "anzuschließen", die 10mal schneller läuft, insbesondere, wenn es den Chip nicht mehr gibt. > Onboard Soundkarte durch Virtex6 mit DSP Funktion für Audio ersetzen > und schon beschleunigt. Naja, in einen FPGA passen mal locker einige hunderte "Soundkarten" des Blaster-Typs rein, wenn man es pipelined :-) Das Thema "OS" ist dabei nochmals ein wenig anders gelagert. Das wird dann aktuell, wenn der z.B. FPGA dynamisch Daten von z.B. CPUs bekommt, die selber mit OS laufen und ihrerseits so bedient werden müssen. Dann ist es mitunter schwierig, einen Hardware layer zu schreiben, der das zufriedenstellend managed und besser, man rüstet Teile eines FPGAs soweit hoch, dass er selber OS-spezifische Funktionen kann und verschiebt die Kommunikation auf diese Ebene. Einen kompletten FPGA in Software zu verwandeln ist weniger zielführend. Dann lieber einen Controller.
Naja, interessant, wenn man mehrere FPGAs virtuell und flexibel verschalten will. Dennoch bleibt die Frage, ob das immer effektiv wird, wenn es darum geht, wesentliche Komponenten in einer SW so zu flexibilisieren. Im Allgemeinen sind DSP-Farmen dafür dann einfacher zu konstituieren und zu beschicken. Und: Sie sind billiger. Aus FPGA-Entwickler-Sicht muss ich sagen "Leider" :-)
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.