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

There are 136 replies in this Thread which has previously been viewed 22,588 times. The latest Post (July 13, 2020 at 1:19 PM) was by ZeHa.

  • Alleine dadurch gibt es schon ein Lag von durchschnittlich 1/2 Frame, wenn nicht sogar mehr (Stichwort Grafik-Treiber).

    Es gibt keine Vorschrift das ein Grafiktreiber verwendet werden muss. Das ist eine Bequemlichkeit damit die Software auf vielen Systemen läuft, aber nicht zwingend vorgeschrieben.

  • ZeHa Ja und? Inwiefern spielt das eine Rolle? Also ich bin ja allemal für FPGAs, aber Deine Argumentation ist schräg. FPGAs haben ja nichtmal 5V-TTL an den I/O-Pins, wie sollen die da "original" sein? Und warum sollte die Im-Browser-Emu des 6502 weniger exakt sein, obwohl sie potenziell z.B. sogar Leckströme oder kosmische Strahlung oder Temperaturänderungen recht sauber nachbilden könnte, was der FPGA ganz sicher nicht kann (sofern man es nicht mit Extra-Logik eben emuliert)?

  • Worauf ich hindeutet war etwas ganz anderes, denn mit FPGA assoziieren die meisten, dass das dann ein 1:1 Nachbau ist, also Chip-Identisch. Das trifft jedoch weder auf den von bwack entwickelten 6526 Nachbau, noch auf den FPGA-SID, und auch nicht auf Gideos Ultimate 64 zu. Sie bilden keine "Die" Gatter 1:1 Stück für Stück nach, [..]

    Deshalb ist es am Ende doch eine Software-Emulation, anstatt ein 1:1 Gatter-Nachbau.

    Ah, verstehe. Deswegen ist ein AMD-Prozessor auch kein richtiger x86-Prozessor, weil er nicht die gleichen Gatter 1:1 verwendet wie das Original von Intel und damit die Befehle von Intelprozessoren nur nachbaut und emuliert.

    Aber... Moment mal...

    x64 ist ja eine Erfindung von AMD. Dann sieht das wohl eher so aus:

    Intel:

    - Originalgatter für x86

    - emuliert x64

    AMD:

    - emuliert x86

    - Originalgatter für x64

    Oder etwa doch nicht...? :gruebel

  • ZeHa Ja und? Inwiefern spielt das eine Rolle? Also ich bin ja allemal für FPGAs, aber Deine Argumentation ist schräg. FPGAs haben ja nichtmal 5V-TTL an den I/O-Pins, wie sollen die da "original" sein? Und warum sollte die Im-Browser-Emu des 6502 weniger exakt sein, obwohl sie potenziell z.B. sogar Leckströme oder kosmische Strahlung oder Temperaturänderungen recht sauber nachbilden könnte, was der FPGA ganz sicher nicht kann (sofern man es nicht mit Extra-Logik eben emuliert)?

    Ich habe nicht gesagt dass sie weniger exakt ist, ich habe nur gesagt dass im einen Fall ein Strom durch einen Schaltkreis fliesst, wie er es auch im Original-Bauteil tut, und im anderen Fall wird dieser Vorgang von eine Programm SIMULIERT. Das sind einfach im Grundsatz zwei voellig verschiedene Dinge. Auch wenn sie das gleiche Ergebnis haben. Siehe mein Beispiel Brief selbst zustellen oder zur Post bringen. Ergebnis das gleiche, der Weg des Briefs sehr unterschiedlich.

  • In Software hat man nur dann ein Problem wenn man Sachen berechnen will die gleichzeitig eintreten und eins vom anderen abhängig ist. Dafür gibt es aber auch Lösungen, wie so eine Schaltungsimulation ala SPICE. Audio Plugin Hersteller wie uhe arbeiten mit solchen Simulationen in Echtzeit, um das Verhalten von Synthesizer-Schaltungen so genau wie möglich nachbilden zu können und wenn ich das richtig verstanden habe, dann wird auch bei der SID-Emulation so eine Schaltungssimulation durchgeführt. Intern funktioniert das wohl durch Wahrscheinlichkeitsrechnungen oder so. Damit wird geschätzt wenn Signale gleichzeitig eintreffen und je mehr Rechenzeit man zur Verfügung hat, desto besser kann man schätzen.

  • Dann wäre es faktisch kein Emulator mehr, sondern eine Portierung auf andere Hardware....

    Das ist falsch, denn die CPU und die Hardware muss trotzdem emuliert werden. Nur eben unter Umgehung des OS. Wenn ich am Amigs programmiere schalte ich auch das OS aus, aber wenn ich damit einen C64 emuliere, wäre das trotzdem noch immer eine Emulation, denn wenn ich auf dem Amiga ein

    MOVE.B $d020,10 mache, dann passiert da nichts. Keine Farbe ändert sich. Und das ist es was der Emulator macht. ;)

    Wenn ich Eure Argumentation so folgen würde, dann wäre Linux auf ARM ja emulation und keine Portierung.

    Auch Solaris auf den ixx86ern wären dann Emulationen statt Portierungen...???

    ArOS Emulation??

  • Freddy Nein Du verwechselst da was. Im einen Fall ist es eine Software (Linux) die Du fuer einen oder einen anderen Prozessor kompilierst und dort ausfuehrst. Im anderen Fall ist es eine Hardware-Architektur, fuer die Du einen Emulator schreibst. Nur dass Du den halt direkt fuer den jeweiligen Host-Prozessor schreibst, dennoch wird hier eine CPU auf einer anderen simuliert. Mit Linux auf x86 oder ARM hat das ueberhaupt nix zu tun.

  • Sagen wir ein Raspi kostet 100,-EUR und ein FPGA C64 200,-EUR, nach wieviel Spielzeit habe ich die 100,-EUR Stromkosten eingespart?

    Ich schätze mal nie. Die nehmen sich nicht viel. Ein Raspi-Netzteil hat um die 13W maximale Leistung. Das U64-Netzteil maximal 24 Watt. Beide werden das nicht ausschöpfen. Der Raspi 3 dürfte unter Volllast so bei 5W liegen, das Ultimate64 vielleicht bei 3W. Bei ~30 Cent/kWh kannst du von den 100€ 333kWh verbraten. Bei 2 W Differenz verbrauchst du mit dem Raspi eine zusätzliche kWh in 500h. 333 kWh hast du "frei", also 333*500=166.500h. Das sind 19 Jahre. Ich glaube, dieser Sparansatz führt zu nichts.

  • Das sind 19 Jahre. Ich glaube, dieser Sparansatz führt zu nichts.

    Danke für die Berechnung, ja sowas habe ich mir schon gedacht.

  • Freddy Nein Du verwechselst da was. Im einen Fall ist es eine Software (Linux) die Du fuer einen oder einen anderen Prozessor kompilierst und dort ausfuehrst. Im anderen Fall ist es eine Hardware-Architektur, fuer die Du einen Emulator schreibst. Nur dass Du den halt direkt fuer den jeweiligen Host-Prozessor schreibst, dennoch wird hier eine CPU auf einer anderen simuliert. Mit Linux auf x86 oder ARM hat das ueberhaupt nix zu tun.

    Stimmt, da war mein Hirn wohl etwas daneben...

  • Wenn ich Eure Argumentation so folgen würde, dann wäre Linux auf ARM ja emulation und keine Portierung.

    Auch Solaris auf den ixx86ern wären dann Emulationen statt Portierungen...???

    ArOS Emulation??

    Da muss man halt trennen zwischen dem OS und den Hardwareabstraktionen. Streng genommen ist ein Emulator nur ein OS für eine bestimmte Umgebung. :D

    Beinem OS wie Linux hast du einen kleinen Teil der Gerätetreiber die auf die entsprechende Hardware geschrieben werden. Und drüber liegt dann das OS, das eine einheitliche Schnittstelle für Programme anbietet. Abgesehen davon kannst du ein Programm das für ein x86 Linux compiliert wurde, nicht auf einem m68k Linux laufen lassen, weil es eben KEIN Emulator ist.

  • Ich denke, da liegst Du falsch. Der MISTer hat noch zusätzlich einen ARM-Prozessor, dieser wird wirklich sehr warm und braucht einen Lüfter.

    Nö, der Verbrauch kommt nicht komplett vom ARM - dann wäre der Hinweis auf Kühlkörper und Lüfter ja nicht spezifisch für den ao486-Core, sondern würde generell gelten.

    Der Stromverbrauch eines FPGAs hängt stark von der instanziierten Logik und deren Takt ab - das ist bei anderen ICs genauso, nur dass da die Logik schon bei der Herstellung festgelegt wird.

    Quote

    Zudem wird das ganze auch nich warm; dies zeigt schon, daß der Stromverbrauch bei einem FGPA sehr gering ist.

    Ich habe hier auch noch einen Videoscaler, der um einen FPGA herum aufgebaut ist und da sitzt schon ab Werk ein Kühlkörper mit Lüfter drauf, damit das Ding nicht zu warm wird.

    Das sind einfach im Grundsatz zwei voellig verschiedene Dinge. Auch wenn sie das gleiche Ergebnis haben.

    Der 6502-Simulator von visual6502 liefert ja nicht mal immer das gleiche Ergebnis - die Lorenz-Testsuite meldet bei manchen illegalen Opcodes Abweichungen.

  • Anderes Beispiel: Du wirfst einen Brief direkt beim Empfaenger ein (z.B. weil er in der selben Stadt wohnt), oder Du gibst ihn bei der Post auf. Das Ergebnis wird das gleiche sein - der Brief kommt beim Empfaenger an. Und wenn er erst am naechsten Morgen in den Briefkasten schaut, dann ist es fuer ihn sogar voellig gleich.

    Und jetzt die Frage, warum jemand für etwas, das "für ihn völlig gleich" ist, für eine Lösung (FPGA) Geld bezahlen soll und für die andere Lösung kostenlos einen Emulator runterladen kann? :)

  • Du kannst Deinen Salat und Deine Karotten im Garten anpflanzen, trotzdem kaufen viele das im Supermarkt und zahlen Geld dafuer. Was ist jetzt hier genau der Sinn hinter der Frage?

    Eine FPGA-Loesung ist was anderes als ein Software-Emulator und je nachdem was man haben moechte nimmt man das eine oder das andere - weil es eben doch nicht das gleiche ist. Die einen wollen ein Auto, die anderen fahren lieber Bahn... ich verstehe jetzt hier grad nicht wohin die Diskussion abdriftet? Wurde irgendjemandem befohlen, eine FPGA-Loesung zu kaufen, obwohl ihm ein Emulator ausreicht?

  • Was ist jetzt hier genau der Sinn hinter der Frage?

    Der Versuch, diese Frage des Threaderstellers zu beantworten? :)

    "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?"

    Wenn er als Benutzer keinen Unterschied zwischen einer FPGA-Lösung und einem Emulator feststellen kann, dann "lohnt" es sich für ihn nicht.

  • Sind nicht gerade ARM und nun umso mehr RISC V prima Beispiele? Da geht es nur um eine ISA und jeder setzt das um, wie er mag (bei RISCV :).

  • Da geht es nur um eine ISA und jeder setzt das um, wie er mag (bei RISCV :).

    Da sehe ich gerade nicht wie das in den Kontext passt?

    Sind nicht gerade ARM und nun umso mehr RISC V prima Beispiele?

    Meinst du RV32I, RV32E, RV64I oder RV128I? Und mit welchen der 14 optionalen Erweiterungen?

  • Verstehe ich auch nicht ganz... evtl soll damit ausgesagt werden, dass das alles verschiedene Implementierungen der selben Spezifikation sind, und das bei einem FPGA, der eine MOS 6502 implementiert, so aehnlich ist? :huh:

  • ARM verkauft keine Chips mehr, nur noch die Cores in der Form von Hardware Decription Languages .

    Auf dem Chip bringt das dann der Hersteller selber, zum Testen sogar oft als FPGA.