Hallo Besucher, der Thread wurde 15k mal aufgerufen und enthält 136 Antworten

letzter Beitrag von ZeHa am

Unterschiede zwischen Emulator (Software) und FPGA (Hardware) bei Nachbildung von Systemen --> Vor- und Nachteile

  • Hallo zusammen,


    wenn ich ein System (z.B. C64) nachbilden will, kann ich das doch entweder in einem Emulator (also softwareseitig) oder mittels FPGA-Chips (hardwareseitig mittels verschiedener Cores) machen.

    Kann mir als Laie mal jemand in einfachen Worten erklären, ob und wo die Nachbildung mittels FPGA-Chips Vorteile gegenüber einem Emulator hat (z.B. Geschwindigkeit, Stabilität, ...)? Und lohnen für einen Otto-Normal-Nutzer (welcher auf den nachgebildeten Systemen hauptsächlich spielt, Demos anschaut und etwas programmiert) FPGA-Systeme? Oder reicht da auch ein Emulator?


    Vielleicht kann mir da jemand ein paar Infos geben.

    Danke!

    Ausrüstung:


    2x C64 Brotkasten, 1x C128, 1x SX-64, 1x Amiga 500 mit ACA500+, 1x Amiga 1200 mit ACA 1221lc

    1x Floppy 1541 alt, 1x Floppy 1541 neu, 1x Floppy 1571, 1x Datasette 1530
    1x Monitor 1702, 2x Monitor 1084S, 1x Nadeldrucker Star NL-10
    1x PS1 und PS2, 1x SNES, 1x Mega Drive, 1x Pandora, 1x Wii, 1x N64, 1x MiSTer

  • Grundlegender Unterschied:


    Bei einer FPGA-Lösung läuft nur der nachgebauter Rechner. Bei einer Softwareemulation ist immer noch das Betriebssystem des Hostsystems "dazwischen", was zu Verzögerungen z.B. bei der Joystickeingabe oder Ungenauigkeiten beim Timing führen kann.


    Aktuellere Softwareemulatoren können zumindest die Verzögerung bei der Joystickabfrage gut abfangen (Stichwort: Runahead) und sind auch im Handling komfortabler, da man eben das gesamte Gastsystem nutzen kann.


    "Perfekter", im Sinne von Timing genauer, sind FPGA-Lösungen. Ist nur die Frage, wem konkret das wichtig ist.


    In >95% der Fälle dürften Softwareemulatoren mehr als "ausreichend" sein.

  • Ich habe seit zwei Tagen wieder ein MIST FPGA in der neuesten Version. Ich finde die FPGA Lösung sehr bequem. Der Rechner wird eingeschaltet und das gewünschte System ist nach wenigen Sekunden da. Bis auf wenige Spiele funktioniert auch alles wie gewünscht. Die kompatibilität wird in der Regel auch zunehmend besser. Dies ist bei Emulation aber genau so der Fall. Ich finde beide Lösungen gut, aber FPGA ist unter dem Strich doch mein Favorit, da dies dem Original noch etwas näher kommt.

  • hinzuzufügen wäre ggf. noch, dass man auch Softwareemulatoren unterscheiden muss zwischen denen, die die Originalhardware möglichst genau nachbilden, und denen, die nur das Verhalten nachbilden.

    So wird bei letzteren z.B. einfach geschaut, welches Ergebnis z.B. die benutzung eines bestimmten Opcodes nach sich zieht, und das wird nachprogrammiert, ohne Rücksicht darauf, ob die internen Vorgänge denen in dem echten System entsprechen.

    Das ist recht einfach zu programmieren, führt aber oft zu Inkompatiblitäten.
    Zu sehen ist das z.B. oft bei der Emulation von moderneren Spielekonsolen, da oft keine Vollständige Dokumentation der Hardware vorliegt. Das führt dann dazu, dass nur eine Hand voll spiele läuft, und auch das nicht ohne Fehler. Die Entwickler passen dann den Emulator mehr und mehr an die bekannten Probleme an, sodass immer mehr Spiele laufen, aber Probleme gibt es da immer. Solch ein System in FPGA nachzubilden wäre aber nicht weniger inkompatibel, da dort die gleichen Probleme auftreten.


    Beim c64 ist das weniger ein Problem, da (bis auf z.B. teile der illegalen Opcodes) eigentlich alles bekannt ist, um das System exakt nachzubilden.

  • Das kommt ganz darauf an, aus welchem Blickwinkel man das betrachtet. Endbenutzer, Programmierer, Hardwaretüftler, Hersteller, Vermarkter...


    Hier im Forum wird, für mein Gefühl jedenfalls, oft irgendwie die These vertreten, FPGA sei "besser", weil es "echte Hardware" ist. Als Argument gegen Emulation wird dann immer die damit im Allgemeinen verbundene Latenz angeführt, die "echte Hardware" nicht hat. Ich denke aber, diese Richtung der Argumentation führt zu nichts.


    Letztendlich ist FPGA in der Tat irgendwie Hardware und Emulation Software. Alle Vor- und Nachteile ergeben sich aus diesem Unterschied. Generell ist Software einige Abstraktionsebenen über Hardware angesiedelt. Das macht sie flexibler. Ich kann eine Emulation im Prinzip überall laufen lassen, wo ich genug Speicher und Rechenleistung zur Verfügung habe. Wie bei jeder Abstraktion zahle ich dafür einen Preis. Meistens in Form von erhöhter Leistungsanforderung, zusätzlichen Latenzen usw. Der Vorteil ist, dass eine Abstraktion leichter übertragbar ist als eine konkrete Ausprägung von etwas.


    Dem Endbenutzer dürfte das alles eher egal sein, solange das Ergebnis stimmt. Sieht man beides als Weg an, die Funktionalität alter Geräte über die Zeit zu retten, dann würde ich langfristig zu 100% auf Software setzen. Hardware stirbt irgendwann, Software (in Form von Quelltexten) nicht.

  • Man muss abwiegen, was man möchte.


    Die Emulatoren wie Vice und, noch recht "neu", Denise machen einen genialen Job, die "echte" Hardware nachzubilden.

    Software zu finden, die nicht auf einem Emulator oder dem U64 (andere FPGA-Lösungen kenne ich nicht im Einsatz) läuft, ist sehr schwer.


    Vorteile des Emulators: Er kostet nix, also kann man immer damit anfangen und schauen, ob das so läuft, wie man das möchte. Wenn man zufrieden ist, ist doch gut. Und: Man kann die Peripherie des Host-Computers nutzen, um die Emulatoren zu steuern - spielen etwa mit dem XBox-Gamepad usw. Durch Emulation nahezu sämtlicher ehemals erhältlicher Hardware (oder halt auch diverser Kernels) kann man hier auch viel experimentieren. Sehr grosser Vorteil für Spieler auf einem Emulator: Snapshots. Auf dem U64 muss man hierzu (zumindest aktuell noch) wie "früher" mit Freezer-Cartridges (auch emulierten) arbeiten, was es etwas aufwändiger macht.


    Vorteile des U64: Er fühlt sich an wie ein "echter" C64, weil er (zumindest bei mir) in einem echten Gehäuse sitzt. Das macht eben schon viel von der Haptik aus. Überlegen wird der FPGA hier durch die Möglichkeit, USB- und HDMI zu nutzen. Hunderttausende Disketten auf einem USB-Stick, kein Problem. Auch hier gehen diverse Kernels, Cartridges etc. direkt einzubinden, was diese Lösung auch dem "Original" überlegen macht. Im Sinne von HDMI für mich sogar sehr sehr überlegen, da es ein hoher Aufwand ist, mit dem Original ein gutes Bild auf heutigen Schirmen zu bekommen. Für moderne Joysticks braucht es Adapter-Lösungen.

  • Ein "nackter" FPGA ist ohne Funktion. Konfiguriert wird er mittels einer Hardwarebeschreibungssprache, die auch nichts anderes als Software ist. ;)

    Auf das Argument habe ich gewartet...;) Auf einmal ist FPGA dann also doch Software...ach nee! Nichts für ungut, mir ist schon klar was du damit meinst. Aber es ist eben Software auf einer viel niedrigeren Abstraktionsebene als das z.B. ein C++-Programm ist. Von daher würde ich es zwischen echter Hardware im Sinne eines echten 64ers und einem Software-Emulator ansiedeln. Es hat Vor- und Nachteile aus beiden Bereichen.

  • Ein "nackter" FPGA ist ohne Funktion. Konfiguriert wird er mittels einer Hardwarebeschreibungssprache, die auch nichts anderes als Software ist. ;)

    Auf das Argument habe ich gewartet...;) Auf einmal ist FPGA dann also doch Software...ach nee! Nichts für ungut, mir ist schon klar was du damit meinst. Aber es ist eben Software auf einer viel niedrigeren Abstraktionsebene als das z.B. ein C++-Programm ist. Von daher würde ich es zwischen echter Hardware im Sinne eines echten 64ers und einem Software-Emulator ansiedeln. Es hat Vor- und Nachteile aus beiden Bereichen.

    Da widerspreche ich dir auch nicht. :)


    Es ging mir nur darum, dass die Quelltexte der FPGA-Konfigurationen genauso "für Dauer" archivierbar sind wie "echte" Software.

  • Emu-Ception! In Software den FPGA nachbilden und dann darauf die Software des FPGAs laufen lassen 8)

    Das ist gar nicht einmal so abwegig. Was machst du, wenn du eine FPGA-Implementierung in 50 Jahren laufen lassen willst/musst? Dann ist das ein Weg, dies zu tun.

  • Emu-Ception! In Software den FPGA nachbilden und dann darauf die Software des FPGAs laufen lassen 8)

    Ich habe mir tatsächlich schon mal im Wartezimmer vom Zahnarzt Gedanken gemacht, ob es nicht möglich wäre, die FPGA vom MIST als Software nachzubilden, um damit die MIST-Cores laufen zu lassen. Waren aber bislang nur Gedanken ... :D

  • Ich habe mir tatsächlich schon mal im Wartezimmer vom Zahnarzt Gedanken gemacht, ob es nicht möglich wäre, die FPGA vom MIST als Software nachzubilden, um damit die MIST-Cores laufen zu lassen.

    Man kann tatsächlich VHDL-/Verilog-Code nehmen und ihn auf dem Rechner laufenlassen, zB mit Verilator, GHDL oder ModelSim und das wird auch zum Debugging gerne gemacht. Es ist sogar so, dass VHDL und Verilog ursprünglich genau für diesen Zweck entworfen wurden, als Sprachen zur Beschreibung von Hardware, die man simulieren möchte - Synthese kam erst später. Der Nachteil davon ist allerdings, dass es extrem langsam ist, durchaus auch mal im Bereich von Stunden pro Millisekunde oder Mikrosekunde, wenn man den kompletten FPGA-Inhalt simuliert und nicht nur das interessante Stück.

  • Naja das Argument "FPGA ist auch nur Software auf anderer Ebene" ist meiner Meinung nach nicht ganz richtig. Bin kein Experte, aber im Prinzip ist hier die Software nur der "Bauplan", der FPGA konfiguriert sich dann ja selbst um und dann laufen die Stroeme in einem echten Schaltkreis. Meiner Meinung nach ist das eher damit zu vergleichen, dass man eine Datei hat, die ein Platinen-Layout vorgibt, und diese gibt man dann zum Platinen-Bauer und bekommt die fertige Platine. Nur mit dem Unterschied, dass sich das beim FPGA halt beliebig oft aendern laesst.


    Ein Software-Emulator hingegen ist ein Software-PROGRAMM, welches auf einem Computer laeuft. Selbst wenn kein Betriebssystem unten drunter ist, ist es immer noch ein PROGRAMM, das ablaeuft auf einer fremden CPU.


    Das ist also schon ein gewaltiger Unterschied.


    Zudem ist auf einem FPGA auch echte Nebenlaeufigkeit/Parallelitaet moeglich, so wie auch in einem echten Schaltkreis. In einem Software-Emulator kann das nur simuliert werden, dadurch dass die Host-CPU das schnell genug abhandeln kann. Ok, mit Multicore-CPUs laesst sich hier vielleicht noch argumentieren.


    In der Praxis gibt es uebrigens noch den Unterschied, dass Software-Emulatoren auf PCs das 50Hz-Bild meist auf einem mit 60 Hz-Bildschirm ausgeben, was zu Scrolling-Ruckeln fuehrt, waehrend ein FPGA direkt ein Videosignal mit 50 Hz erzeugen kann das dann direkt an einen Fernseher oder CRT gehen kann und somit sauber scrollt.

  • Wenn man einen FPGA computer in assembler programmiert, weiss man dass gerade eine bestimmte Zahl/Adresse auf einen echten Bus geschoben wird (zumindest wenn die FPGA implementierung Hardware nachbildet).

    Bei Software-Emus ist das aber NIE (deterministisch) der Fall. Ich kann dem schon einen gefuehlten Unterschied abgewinnen.

  • Zudem ist auf einem FPGA auch echte Nebenlaeufigkeit/Parallelitaet moeglich, so wie auch in einem echten Schaltkreis. In einem Software-Emulator kann das nur simuliert werden, dadurch dass die Host-CPU das schnell genug abhandeln kann. Ok, mit Multicore-CPUs laesst sich hier vielleicht noch argumentieren.

    Natürlich habe ich in heutigen Prozessoren auch echte Nebenläufigkeit. Die meisten Emulatoren dürften aber im Ursprung so alt sein, dass sie davon noch nicht viel gehört haben. Und selbst wenn doch, dann ist die Synchronisation der einzelnen Threads nicht trivial.

  • Bei Software-Emus ist das aber NIE (deterministisch) der Fall. Ich kann dem schon einen gefuehlten Unterschied abgewinnen.

    Wieso das den nicht? Natürlich ist das dann kein "echter" Bus, aber der Emulator ist doch auch getaktet und schiebt entsprechend seine Daten über den in Software nachgebildeten Bus. Wobei das natürlich auf den Detailgrad und die Ebene der Emulation ankommt.

  • Zudem ist auf einem FPGA auch echte Nebenlaeufigkeit/Parallelitaet moeglich, so wie auch in einem echten Schaltkreis. In einem Software-Emulator kann das nur simuliert werden, dadurch dass die Host-CPU das schnell genug abhandeln kann. Ok, mit Multicore-CPUs laesst sich hier vielleicht noch argumentieren.

    Natürlich habe in heutigen Prozessoren auch echte Nebenläufigkeit. Die meisten Emulatoren dürften aber im Ursprung so alt sein, dass sie davon noch nicht viel gehört haben. Und selbst wenn doch, dann ist die Synchronisation der einzelnen Threads nicht trivial.

    Ja, deshalb hatte ich auch die Multicore-CPUs erwaehnt, aber ob ein Emulator davon Gebrauch macht, ist eben die Frage. Die andere (berechtigte) Frage ist natuerlich auch, ob das am Ende ueberhaupt noch einen wesentlichen Unterschied macht, wenn die CPU eh schon so schnell ist. Die Emulation koennte in der Praxis also genauso exakt sein wie in einem FPGA, zumindest wenn die CPUs noch schneller werden irgendwann.


    Nichtsdestotrotz ist es aber ein prinzipieller Unterschied, denn hier kann man mit dem FPGA etwas machen, was man mit Software nicht machen kann.