Posts from sparhawk in thread "Unterschiede zwischen Emulator (Software) und FPGA (Hardware) bei Nachbildung von Systemen --> Vor- und Nachteile"

Quote from Diddl

Da ist alles gut solange das Host System schnell genug ist.

So ein Windows System macht aber viele Dinge gleichzeitig.

Wenn es mal nicht mitkommt, dann verlangsamt sich die virtuelle CPU.

Um manche Dinge kommt man sicher nicht rum, weil man die nicht beeinflussen kann. Wenn man allerdings zig Sachen daneben laufen lässt, dann muss man sich nicht wundern wenn irgendwo die Rechnzeit fehlt. Wenn man den Emulator startet und nicht tausend andere Sachen daneben, dann hält sich das aber in Grenzen und kann IMO vernachlässigt werden.

Ärgerlich finde ich allerdings wenn Windows meint es muss jetzt ein Zwangsupdate checken, weil ich in dem Fall durchaus immer wieder merke dass die Rechenleistung nachlässt ohne dass ich das selbst beeinflussen kann.

Quote from Freddy

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.

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.

Quote from peiselulli

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.

Quote from Freddy

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.

Quote from Unseen

Die mythischen High-Level-Synthese-Tools, die einen Emulator in ein FPGA compilieren können werden gerne bei solchen Diskussionen in den Ring geworfen, aber meines Wissens existiert auf dem Markt kein einziges Tool, welches Code in der Komplexität eines typischen Emulators wirklich zu Hardware umsetzen kann.

Kann mir auch nicht vorstellen das es so ein Tool gibt. Ein Emulator der für ein OS geschrieben wird, hat eine andere Umgebung als ein FPGA darstellt. Was ich mir allerdings vorstellen könnte ist, dass man vielleicht den FPGA Code in Form eines C++ Programms formulieren könnte und DIESES dann übersetzt werden könnte.

Quote from Snoopy

Der Benutzer hat keine Möglichkeit die Systeme anhand der Optik zu unterscheiden. Dann startet man die Lösungen und lässt dann den Benutzer dran.

Mal schauen, ob der Benutzer tatsächlich unterscheiden kann, welche "Box" sich "am echtesten" anfühlt. Das bezweifel ich bei mindestens 90% der Benutzer. Und für die ist es dann in der Tat vollkommen egal, was sie benutzen. Sie fühlen keinerlei Unterschied.

Quasi ein Turingtest.

Quote from Freddy

ZeHa , sparhawk, Snoopy @all VHDL ist eher mit Postscript bzw. HTML zu vergleichen.

Postscript 'beschreibt' die Seite (das Aussehen etc.) ist aber nicht den Inhalt der Seite.

Danke! Der Vergleich macht es leichter das besser einzuordnen. Wie unabhängig ist diese Sprache dann? Kann ich als einen "alten" FPGA nehmen und das drauf anwenden? Dachte das wäre stark an die Hardware gebunden.

Quote from adtbm

Man könnte also, in Zukunft, auf eine Chip Bibliothek zugreifen, den Code der einzelnen Chips in einem FPGA zusammenstellen und so einen wirklichen Rechner nachbilden.

Habe mit FPGA keine Erfahrung und kenne das eher vom "Hörensagen". Das klingt jetzt so, als wenn man die einzelnen Chips definiert und die dann quasi "reinstecken" kann, so wie man das auch mit einem echten Chip machen würde?

Also z.B. ich nehme dann einen Z80 Chip, den stecke ich auf eine Platine und baue dann drumherum einen ZX Spectrum, oder eben CPC usw. Würde das mit FPGA dann ähnlich funktionieren, oder ist das zu einfach gedacht?

Quote from ZeHa

Allein das ist eigentlich schon der Punkt: Auf dem FPGA "laeuft" keine Software

War vielleicht falsh formuliert aber ...

Quote from ZeHa

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.

... du sprichst hier ja auch selbst von "Software" und in diesem Sinne meinte ich das auch. Für die Portierbarkeit spielt das eh keine Rolle, weil das Argument gleich bleibt.

Quote from Snoopy

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

IMO kann man das so nicht vergleichen. Die Software die auf einem FPGA läuft ist schon sehr spezifisch und ich glaube nicht dass man die leicht auf einen anderen FPGA portieren kann, oder liege ich da falsch? Insofern ist ein Emulator, der dann in C oder C++ oder sonstwas geschrieben ist, schon ein riesen Unterschied.

Und wenn man den Emulator in Assembler auf die Hardware schreibt, was dann IMO eher vergleichbar wäre, dann siehts auch mit der Portierbarkeit auf zukünftige Systeme schon schlechter aus.

Das Argument mit dem FPGA im Gehäuse eines C64, sehe ich auch als eher schwach an. Ob in dem Gehäuse ein Raspberry mit Vice steckt oder ein FPGA, dürfte für den Anwender kaum einen Unterschied machen, solange das Systemverhalten gleich bleibt. Wenn der Rechner schnell genug ist, sollte der Lag irgendwann auch (fast) verschwinden.