Hacker News Reader

Comment by luu | Hacker News Reader

It is. I did a Sega system on an FPGA in 2003 as a one-semester senior design project. Using a modern HDL (bluespec, or something like the proprietary language my company uses internally) on current FPGAs, you could probably do a much higher level implementation in 1/10th that time.

An SNES would be much more annoying to do, but probably no more than an order of magnitude moreso, so I doubt it would take more than a semester, even for someone who'd never touched an FPGA before.

View on HN

> I did a Sega system on an FPGA in 2003 as a one-semester senior design project.

The article was about achieving extremely high compatibility by emulating hardware quirks. What advantage would an FPGA be? Easier synchronization?

The hardware quirks, by and large (ignore things like the behavior of undocumented/unintentional instructions on the CPU -- these are a separate issue and easy to deal with), are due to the impedance mismatch you have of emulating hardware on software. When you're emulating old hardware on an FPGA, you don't worry about synchronization, you just have the cycle timing be a multiple of the original timing. This gives you "synchronization" in the same way the old hardware did -- these components are all running in parallel and pushing/pulling data at specific times, which happens implicitly in hardware.

FPGAs make this a complete non-issue. Of course, FPGAs bring in a whole host of issues when you want to make such a thing practical. One thing I've been considering for a long time is a super high-level HDL specifically for emulation like this, which can either be run on the CPU (slowly), synthesized for FPGAs, or burned into an ASIC. You could have a whole catalog of components and put them together just like building a real console.

FPGAs don't solve all the timing problems. In some cases, you have to accurately emulate the stalls that occur on one processor as computation or interrupts occur elsewhere.

Synchronization and timing issues are two different things, though, and synchronization is implicit if you get the timing right, unlike emulating hardware on software. The timing aspect of it is just a matter of properly emulating the behavior of the chip; not easy, but significantly easier to get right than synchronization in software.

But that said, FPGAs are by no means a silver bullet. There are a billion problems with them, mainly due to the terrible development tools, at least the ones that someone not doing this stuff professionally can afford.

I wonder if you could solve some of the issues by building each component in an FPGA and wiring up as appropriate to simulate the timing/sync better vs. emulating the entire system at once.

http://www.youtube.com/watch?v=onBmiHoOxGs

Reply on news.ycombinator.com