There are 136 replies in this Thread which has previously been viewed 22,589 times. The latest Post (
Also von einem technischen Standpunkt her würde ich sagen, ist der Unterschied, dass Software parallel auf (größenordungsmäßig) 10 komplexen Prozessoren läuft und HDL auf FPGAs parallel auf 100.000 sehr einfachen Einheiten.
Da hängt es ganz vom Einsatzzweck ab, was besser ist. CPUs lassen sich besser in Software abbilden, Graphikeinheiten besser in HDL.
Wie Jeek sagt, handelt es sich bei der Umsetzung eines Rechnerkonzepts in Form einer Hardware- oder Softwarelösung um zwei Wege, die letztendlich zum gleichen Ziel führen. Am Anfang der Entwicklung stand ohnehin nur die Idee eines C64. Im Grunde genommen entspräche auch nur diese dem "Original", und jegliche Manifestation ist nur eine Variante davon. (Wie war das noch mit den SIDs? Klingen die alle gleich?)
Was man nun für gewöhnlich als Original betrachtet, hängt dabei von der Zeit ab: Was zuerst da war, gilt als "Original", und weder Emulatoren noch FPGAs werden daher jemals ein Gefühl von "Original" erhalten. Aber wie wäre das im umgekehrten Fall? Zuerst gibt es ein System nur als Emulator, und später erscheint eine Hardware dazu. Ist dann der Emulator auch "originaler" oder "realer" als die Hardware? Interessanterweise konnte ich bemerken, daß mir persönlich die Hardwareumsetzung der p-Code-Maschine (von USCD-Pascal bzw. ApplePascal) nicht so "real" vorkam wie der Software-Bytecodeinterpreter auf dem AppleII. Vielleicht einfach, weil ich den zuerst erfahren habe und bestimmte Erinnerungen damit verbinde.
Emulatoren haben eventuell den Nachteil, daß man sich als Benutzer mehr oder weniger bewußt ist, daß die Emulation nur ein Untersystem erzeugt. Ohne das Hostsystem (z. B. PC mit Windows) wäre der emulierte C64 nicht lebendig. Beim FPGA hingegen wird nach der Programmierung das FPGA (mitsamt Shield und Anschlüssen) zum vollständigen, eigenen Rechner. Der FPGA "ist" dann quasi der C64, denn er benötigt keine weiteren Hilfsmittel. Theoretisch. Praktisch sieht es jedoch meist so aus, daß zur Verwendung moderner Peripherie (USB) nebenbei ein ARM-Prozessor auf dem FPGA-Board werkelt, welcher die Kommunikation übernimmt und die Ergebnisse an das FPGA weiterleitet. Inwieweit man diese Verwendung als zugehörig mit einschließt (der ganze FPGA mit seinem Partner-ARM zählt als eine Einheit) oder den ARM pragmatisch als "Peripherie" aus der Betrachtung herausläßt, darf jeder selbst entscheiden.
Bleibt aber noch die Frage, inwieweit denn ein FPGA-Nachbau noch ein C64 sein kann, weil ja z. B. alle Chips in einem einzigen FPGA zusammengefaßt werden. Das hängt wohl davon ab, wie wichtig einem generell "Originalbausteine" sind, und wieviele davon nötig sind, um noch von "original" zu sprechen. Nebenbei sind Fragen wie "Wann ist ein Objekt noch original?" schon ziemlich alt. "Das Schiff des Theseus" wäre ein Beispiel aus der Antike. Anderes Beispiel: Ein Gebäude (Burg, Rathaus etc) wurde durch Feuer zerstört und daraufhin wieder aufgebaut. Ist der Neubau dann noch das "Original"? (Hinweis: Beim Menschen wird im Laufe von ca. 7 Jahren jedes Atom des Körpers ausgetauscht. Ab wann ist der Mensch nicht mehr "original"?)
Also angenommen jemand würde einen C64 nehmen und Stück für Stück die Chips austauschen, z. B. durch FPGAs ersetzen. Ab welchem Punkt wäre es dann kein "echter" oder "originaler" C64 mehr? Wenn die CPU ausgetauscht ist als Herzstück des Rechners? Wenn der SID getauscht wurde und die Filter jetzt auf eine bestimmte vorgegebene Art nachgebildet werden? Leute, die sehr hardwarenah arbeiten, z. B. Elektroniker, würden vielleicht schon beim ersten Austausch eines Bausteins sagen: "Das ist nicht mehr mein C64". Andere, die sich eher mit Software beschäftigen, akzeptieren vielleicht ohne Probleme einen C64, der nur noch aus einem FPGA besteht. Es gibt hierbei einfach keine "richtige" Sichtweise, nur andere Geschmäcker aufgrund verschiedener Erfahrungen.
Reicht nun ein Emulator aus, um zu erfahren, was ein C64 ist? Ja, natürlich. Heutige Emulatoren setzen die Idee des C64 sehr gut um. Lamer wie ich, die sowieso kaum spielen, werden eine Latenz nicht bemerken bzw. es wird sie nicht stören. Praktisch braucht man daher keine Hardware mehr, um den C64 kennenzulernen oder sich mit ihm zu beschäftigen (spielen/programmieren). Aber zu wissen, daß eine Hardware ("Original"-C64) für sich alleine arbeitet und ein in sich abgeschlossenes System bildet, das nach dem Einschalten einfach da ist, ist halt ein schönes Gefühl. Der Duft von Freiheit und Unabhängigkeit. Und deswegen kommt dann doch irgendwann der Punkt, an dem man sich eine reale Hardware anschafft. Aber - wie gesagt - ist halt alles Geschmackssache.
Also wie ich schon weiter vorn sagte, fuer mich ist es schon ein Unterschied, ob eine Software "nur so tut" als waere sie etwas, oder ob ein Schaltkreis die identische Arbeit uebernimmt. Selbst wenn beide "perfekt" implementiert sind, ist das eine immer noch etwas, was nur so tut, waehrend das andere als aequivalente Schaltung angesehen werden kann.
Quote from ZeHa... ob eine Software "nur so tut" als waere sie etwas, oder ob ein Schaltkreis die identische Arbeit uebernimmt
Zum Beispiel tut das "identisch" ein Ultimate 64 nicht 
Ist im Prinzip auch nur eine Software-Emulation, die anschließend in Gatter umgewandelt wird, und dadurch den Timing-Vorteil nutzt (im Gegensatz zu einem Emulator auf einem PC, der sich auch noch mit dem Host-System Delay begnügen muss). Deshalb hat der Ultimate 64 ja noch jede Menge Fehler (an den roten Test-Checks zu erkennen), die bei einer kompletten 1:1 System Kopie nicht auftreten würden.
Den Einzigen den ich kenne der 1:1 Die's nachbaut ist androSID... mit entsprechend gigantischem Mannstundenaufwand 
Wenn VHDL/FPGA lediglich "Emulation" und "Software" sind, wird's dann magisch Hardware, wenn man das VHDL einer Foundry gibt, die dann ASICs draus presst? An welcher Stelle genau passiert denn die Magie?
Emu-Ception! In Software den FPGA nachbilden und dann darauf die Software des FPGAs laufen lassen
Macht mach das nicht schon indem man mit einem Simulator seinen FPGA Code testet?
@Matthias Ja, ist vielleicht noch nicht identisch, das gilt aber vermutlich auch noch für die meisten Software-Emulationen. In der Theorie könnten aber beide irgendwann 100% die gleiche Arbeit machen (das schrieb ich ja), und dennoch wäre es ein Unterschied, ob ein Software-Emulator einen Schaltkreis simuliert oder ein Schaltkreis direkt etwas tut.
Ein FPGA ist keine Software-Emulation, das ist eine falsche Aussage. Sie ist in Software beschrieben, aber das gilt ja heute für alles. Eine Auto-Karosserie wird auch in einem CAD-File beschrieben bevor sie hergestellt wird, aber deshalb ist das Ergebnis am Ende trotzdem ein echtes Auto und kein 3D-Modell. Oder nimm meinetwegen einen 3D-Druck als Beispiel, da kommt am Ende auch ein echtes Stück Plastik raus 
Auch wenn für FPGAs eine Programmiersprache verwendet wird, z.B. VHDL, so ist z.B. das Abarbeiten der Instruktionen
unterschiedlich zu einem herkömmlichen Programm. Eine Programmiersprache wie z.B. C arbeitet ein Programm immer Schritt für Schritt ab. Während VHDL parallel Instruktionen abarbeiten kann.
Für mich der grösste Unterschied zwischen einem Emulator und einem FPGA liegt darin, dass ein FPGA wirklich, die integrierten Schaltkreise nachbildet, während ein Emulator immer nur das Ergebnis emuliert.
Beispiel SID: Wenn man die Millionen von Transistoren eines SIDs in einem FPGA nachbildet und verbindet hat man eine exakte Kopie des Chips.
Während man sich also bei einem Emulator, durch das verändern der Ergebnisse langsam an eine Kopie des Chips annähert, wird bei einem FPGA der Chip selber nachgebaut, das Ergebnis ist also das Resultat in der Genauigkeit bei der Nachbildung des Chips.
Daher ist es meines Erachtens zukunftsweisend, diese Chips nachzubilden und so zu archivieren.
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.
Und der letzte ausschlaggebende Unterschied, zwischen einem Emulator und einem FPGA....die Zeit !
Den MEGA65 oder U64 schaltest du ein und der Rechner ist im Bruchteil von ein paar Sekunden einsatzbereit. Bei einem Emulator muss immer erst einmal der Hostrechner booten und dann der Emulator gestartet werden, das kostet Zeit.
Paul hat dazu ein nettes Video gemacht:
Beispiel SID: Wenn man die Millionen von Transistoren eines SIDs in einem FPGA nachbildet
SID ist das schlechteste Beispiel, dass ist der einzige Chip, den man mit FPGA nicht nachbilden kann, da Analog-Anteile. Für Digitalschaltung hast du aber recht.
Ein wirklich interessanter Thread, zu welchem ich auch meinen Beitrag leisten möchte.
Ein Punkt fehlt in meinen Augen noch: Energieverbrauch. Bei einem FGPA hats Du im Gegensatz z.B. zu einem PC o.ä. nur einenn minimalen Stromverbrauch und so gut wie keine Wärmeentwicklung; meistens haben die FGPAs nicht mal einen Lüfter, so daß Du auch eine geräuschlose Emulation/Implementation hast.
Ich bin seit 30 Jahren Retro- und Commodore-Freak und muss sagen, daß für mich mein MIST (habe 2) die eindeutig beste und auch sehr komfortable Lösung ist. Habe auch schon Raspberries usw. probiert, aber in meinen Augen war vor allem das Joystick-Lag hier im Vergleich zu Origonal-Hardware oder FGPAs nicht akzeptabel.
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.
Die Software die auf einem FPGA läuft
Allein das ist eigentlich schon der Punkt: Auf dem FPGA "laeuft" keine Software
Allein das ist eigentlich schon der Punkt: Auf dem FPGA "laeuft" keine Software
War vielleicht falsh formuliert aber ...
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.
Ja es ist auch Software, wenn man Software im Sinne von "Daten" sieht. Aber es ist keine Software, die auf dem FPGA "laeuft" - denn es ist kein Programm, es ist nur ein Bauplan der ein paar Weichen stellt und danach ist das Ding "fix". Daher ist das eher mit einem digital abgespeicherten Schaltplan zu vergleichen (im Gegensatz zu einem, der halt auf Papier gezeichnet ist), aber am Ende wird ein Chip draus, der diesen Schaltkreis abbildet, und kein Programm, das einen Schaltkreis "simuliert" (so wie das ein Software-Emulator macht).
Ich wollte auch Deinen Beitrag nicht kritisieren bzw bin nicht der Meinung, dass Du vom Sinn her etwas falsches erzaehlst, ich wollte nur speziell diese Formulierung aufgreifen, weil diese fuer Missverstaendnisse sorgt. Daher habe ich das gerade direkt zitiert 
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.
Das selbige gilt für HTML, es beschreibt eine Website, ist aber nicht deren 'Inhalt', und so ist es bei VHDL: es 'beschreibt' die Schaltung, ist aber nicht die Schaltung selbst.
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?
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.
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.
Soweit mir bekannt ist, gibt es mehrere 'Chip-Beschreibungssprachen'. Also mindestens 2: VHDL & Verilog.
Und genau wie Postscript und HTML werden diese Sprachen wohl auch weiterentwickelt.
Ich muss da immer an ein "Blackbox"-Experiment denken: Man steckt eine FPGA-Lösung und einen Emulator samt benötigter Hardware in jeweils ein gleiches Gehäuse. Am besten zur Kontrolle als dritte Box noch echte Hardware. 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.
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.
