3 ms·

I can see how an FGPA can perfectly emulate the logic of an older chip--but the actual physical layout is different, right? Are there any timing issues that re

by jxdxbx 3y ago

I can see how an FGPA can perfectly emulate the logic of an older chip--but the actual physical layout is different, right? Are there any timing issues that result from this?

wmf 3y ago
In normal synchronous logic if something takes N cycles it takes N cycles; sub-cycle timing differences don't matter. If the original chip is doing weird asynchronous stuff it could be hard to properly emulate.
- willis936 3y ago
  I'm under the impression that there were test and debug ROMs for each console that stretch capabilities and can reveal non-ideal behavior. They now work as unit tests for emulators.
andrewf 3y ago
An FPGA can enable these things but it doesn't magically happen. A MisterFPGA can emulate a PC with the ao486 core, which is an achievement, but the ao486 core doesn't precisely mimic the machinery or timing of the 80486 or any other CPU.
mikepavone 3y ago
The reality is that the vast majority of these FPGA-based clones don't actually perfectly emulate the logic. They're using the same reverse engineering techniques the traditional emulator developers used and sometimes even the same community documentation. The results are often quite good, but they're making a new implementation that matches the observed behavior of the original system to the best of their abilities. Now there are some exceptions. Nuked MD FPGA[0] is a recent example of an FPGA recreation that is a fairly direct translation of the original logic using silicon die analysis. In this case, the logic is basically identical, but as you guessed the physical layout is different. Generally speaking, you write FPGA "gateware" in a language like Verilog or VHDL. These don't intrinsically have any information about the physical layout of the logic which is handled by the toolchain instead. As wmf says, this is generally not a problem most of the time. For synchronous logic, either the total propagation delay is small enough for a single cycle or it isn't. The toolchain will estimate this delay and report whether you met timing or not for the configured clockspeed. Not everything you can do in silicon translates well to FPGAs (both clock edges is also generally not well supported for instance), but for the most part these things are easy enough to work around. [0] https://github.com/nukeykt/Nuked-MD-FPGA https://github.com/nukeykt/Nuked-MD-FPGA
mips_r4300i 3y ago
Except for the rare cases where a chip can be decapped, turned into a netlist and painstakingly translated 1:1 into logic primitives (which itself is usually impossible without some fudging), all re-implementations are exactly that. You can still do higher level stuff in an FPGA. Maybe you don't actually care how the sprite hardware really works, and you just make your own that mostly works the same. Maybe you don't even care that a PPU is split into 3 chips, you make yours without regard for the physical delineation of the original. There are some cores out there like this - written off of software emulators with minimal original research. It is many times possible to get something that somehow plays games even while being "inaccurate", but yields little benefit over software emulation besides lower latency from controller inputs. Higher-quality cores always involve original research. It is rare that documentation already exists at the detailed level you need. The best people in the field blackbox the original chips and, based on years of experience and knowledge of sussing out behavior by thinking like the original chips designers, can make a functionally and timing accurate model that can operate in lockstep with the real chip, cycle for cycle the same data on the bus. This is the sweet spot for FPGA implementations, but also requires a lot of skill and expertise. At the extreme end is stuff like NukeMD and the visual 6502/68k projects. The logic is cloned at the gate level without any guessing. Still, some changes are necessary. For example, chips with internal tristate busses are impossible to do on FPGA fabric. Clocking in both sides of the clock. Using multiple phase clocks. Using dynamic logic. And so on. These implementations are usually much less space-efficient than the paragraph above, but offer the highest accuracy.

by jxdxbx 3y ago

I can see how an FGPA can perfectly emulate the logic of an older chip--but the actual physical layout is different, right? Are there any timing issues that result from this?

wmf 3y ago

In normal synchronous logic if something takes N cycles it takes N cycles; sub-cycle timing differences don't matter. If the original chip is doing weird asynchronous stuff it could be hard to properly emulate.

willis936 3y ago
I'm under the impression that there were test and debug ROMs for each console that stretch capabilities and can reveal non-ideal behavior. They now work as unit tests for emulators.

andrewf 3y ago

An FPGA can enable these things but it doesn't magically happen. A MisterFPGA can emulate a PC with the ao486 core, which is an achievement, but the ao486 core doesn't precisely mimic the machinery or timing of the 80486 or any other CPU.

mikepavone 3y ago

The reality is that the vast majority of these FPGA-based clones don't actually perfectly emulate the logic. They're using the same reverse engineering techniques the traditional emulator developers used and sometimes even the same community documentation. The results are often quite good, but they're making a new implementation that matches the observed behavior of the original system to the best of their abilities. Now there are some exceptions. Nuked MD FPGA[0] is a recent example of an FPGA recreation that is a fairly direct translation of the original logic using silicon die analysis. In this case, the logic is basically identical, but as you guessed the physical layout is different. Generally speaking, you write FPGA "gateware" in a language like Verilog or VHDL. These don't intrinsically have any information about the physical layout of the logic which is handled by the toolchain instead. As wmf says, this is generally not a problem most of the time. For synchronous logic, either the total propagation delay is small enough for a single cycle or it isn't. The toolchain will estimate this delay and report whether you met timing or not for the configured clockspeed. Not everything you can do in silicon translates well to FPGAs (both clock edges is also generally not well supported for instance), but for the most part these things are easy enough to work around. [0] https://github.com/nukeykt/Nuked-MD-FPGA https://github.com/nukeykt/Nuked-MD-FPGA

mips_r4300i 3y ago

Except for the rare cases where a chip can be decapped, turned into a netlist and painstakingly translated 1:1 into logic primitives (which itself is usually impossible without some fudging), all re-implementations are exactly that. You can still do higher level stuff in an FPGA. Maybe you don't actually care how the sprite hardware really works, and you just make your own that mostly works the same. Maybe you don't even care that a PPU is split into 3 chips, you make yours without regard for the physical delineation of the original. There are some cores out there like this - written off of software emulators with minimal original research. It is many times possible to get something that somehow plays games even while being "inaccurate", but yields little benefit over software emulation besides lower latency from controller inputs. Higher-quality cores always involve original research. It is rare that documentation already exists at the detailed level you need. The best people in the field blackbox the original chips and, based on years of experience and knowledge of sussing out behavior by thinking like the original chips designers, can make a functionally and timing accurate model that can operate in lockstep with the real chip, cycle for cycle the same data on the bus. This is the sweet spot for FPGA implementations, but also requires a lot of skill and expertise. At the extreme end is stuff like NukeMD and the visual 6502/68k projects. The logic is cloned at the gate level without any guessing. Still, some changes are necessary. For example, chips with internal tristate busses are impossible to do on FPGA fabric. Clocking in both sides of the clock. Using multiple phase clocks. Using dynamic logic. And so on. These implementations are usually much less space-efficient than the paragraph above, but offer the highest accuracy.