[Gormo]

> Yup, FPGA recreating other hardware definitely fits the bill of emulation.

It really doesn't. The FPGA actually implements the target hardware, rather than using other hardware to produce equivalent behavior.

That's not to say that no emulation is involved, as not all of the functionality is actually achieved through the FPGA, but where it is, it's perfectly valid to distinguish it from emulation.

[BearOso]

It doesn't implement the original hardware. It's not copy of the original chip. Reverse engineering is used to get the behavior of the hardware. They reproduce the inputs and outputs with Verilog and write it to an FPGA.

If it weren't emulation, they would decap the original chip and directly copy the chip, gate-by-gate. It could be done, but it hasn't been done that way anywhere to date.

[renaudg]

At the end of the day both FPGAs and software emulators are Turing machines that produce a set of outputs given a set of inputs : any logic an FPGA can implement can also be implemented in software, it's computer science 101

FPGAs aren't magically more accurate. That is only up to the programmer and what effort they put in.

The main difference is efficiency and parallelism : it's much easier to reliably produce cycle-accurate parallel outputs in real time with an FPGA, compared to software running on a multi-tasking OS with many layers of abstraction and no deterministic real-time guarantees.

But, as a single-core processor can fake multitasking, by slicing time between processes (preemptive multitasking), software emulation can mimic parallelism if the host is beefy enough compared to the old school system it's emulating. The larger the performance / clock speed gap between the host and target, the more indistinguishable from a truly parallel FPGA an emulator can be.

Software emulation also has practical advantages for developers : while FPGAs force you to painstakingly implement every bit of functionality at the logic gate level, with software you can start off with a much higher level model of the target system that's much easier to implement, and mix & match that with more precise low level simulation where it matters. The time this frees up (+ the availability of various libraries) allows the developer to spend more time researching the original system and adding modern quality of life features that just wouldn't be possible otherwise.

Great article on the topic : https://archive.is/fWosI

[15155]

Nobody has put these chips under a scanning electron microscope, catalogued each gate, and then recreated those in extremely verbose Verilog.

That's what "implementing the target hardware" in an FPGA would consist of.

Even if this extremely-arduous process were to take place, you would likely still be unable to reproduce the analog chips used for audio and video in most FPGAs - certainly not the cheap FPGAs MISTer and friends use.

[Gormo]

> Nobody has put these chips under a scanning electron microscope, catalogued each gate, and then recreated those in extremely verbose Verilog.

I don't think anyone was doing that when iterating on the hardware back in the day, either. Dollars to donuts, the 65C02 was not based on a deep empirical analysis of the behavior of as-implemented 6502s, but was rather produced from modifications to the design spec that the original 6502 was itself implemented from, with the intent of maintaining compatibility with the original design.

Same thing here. An FPGA implementation of the original schematics of the hardware can be viewed as another instance of variant hardware built against the original design, whereas software emulation is simulating the outward behavior of the original hardware without any ability to be implemented directly from the original design at all.

> Even if this extremely-arduous process were to take place, you would likely still be unable to reproduce the analog chips used for audio and video in most FPGAs

Which returns us to the original description of these solutions being mostly hardware implementation via FPGA, but not entirely, as some emulation is still needed.

[naikrovek]

FPGAs are reimplementations, to me, not emulation. But I don’t begrudge anyone who wants to be a stickler on the definition of “emulation”.

Even the original hardware “emulates” a game if you want to get down to it.

[markemer]

That’s how I see it too. The FPGA version are knock offs, like would have been done back in the day but with fancy future hardware. A gate level reproduction would be kinda strange aside from pure desire for preservation. (Which is still a decent goal, just not of these projects)

[cacois]

So your argument is that its closer to virtualization, than to emulation?

[Gormo]

Not really. And I'm not sure the concept of virtualization makes sense when applied to hardware in the first place.

The FPGA is actually implementing the hardware. It's like using a newly manufactured edition of the original.

[fourfour3]

The FPGA is used to implement an approximation of the original hardware’s functionality - not a perfect clone of the original hardware itself, which means they have their own unique bugs and inaccuracies compared to the original designs.

I think “emulation” fits as a reasonable description of this, personally - at least as something an average person will understand.