What Is Emulation?2018-02-06

Being a self-professed emulator developer since 2004, I understandably have rather strong opinions about what is and is not an emulator. And regrettably, it seems many very intelligent people have different ideas than I do. So let's have an honest discussion about that. No politics, no business, just tech.

FPGAs versus CPUs

An FPGA is a field-programmable gate array. You can program for it using Verilog, which is an HDL, or hardware description language.

A CPU is a central processing unit. You can program for it using C++, which is a high level programming language.

Both FPGAs and CPUs can have the programs they run altered at run-time.

An FPGA contains a very large number of logic gates that operate in parallel, whereas a CPU contains microcode that interprets instructions and executes them in serial - at least, per core.

Generally speaking, older game systems will be pure hardware devices: these will mostly resemble the FPGA in being a series of logic gates, but the process will be more refined. Instead of being a programmable device, transistors will be laid out in a fixed, permanent pattern, and this will form an ASIC, or application-specific integrated circuit. ASICs are very expensive to begin production on, but have vastly lower costs in large quantities. So you can kind of think of an FPGA as a sort of hardware prototype. (The oldest chips will have been laid out by hand, such as the venerable 6502, but I digress.)

Newer game systems will mix in software: you'll have operating systems, device drivers, support libraries, etc thrown into the mix. This will generally be written in C or C++.

Verilog versus C++

Let's say we want to implement an 8-bit counter. We start at zero on reset, and then we count upward by one on every positive clock edge.

Here is one way you would implement this in Verilog:

module up_counter (
  out,
  enable,
  clk,
  reset
);

output [7:0] out;
input enable, clk, reset;
reg [7:0] out;

always @(posedge clk)
if(reset) begin
  out <= 8'b0;
end else if(enable) begin
  out <= out + 1;
end

endmodule

And here is one way you would implement this in C++:

class up_counter {
  uint8_t out;
  bool enable, clk, reset;

  void clk_posedge() {
    if(reset) {
      out = 0;
    } else if(enable) {
      out = out + 1;
    }
  }
};

When the claim is made that FPGA is not emulation, the claim is that the former is fundamentally different than the latter. And honestly, maybe it is!

This is very obviously a minimalist example, and as the complexity of the design grows, so too will the overall structure.

But the point I want to convey is that at the end of the day, whether one is coding in Verilog or in C++, they're typing text into text editors, and parsing that text with various tools: programmers or compilers.

Reverse Engineering

What we are dealing with in cases like the Super Nintendo, is we both want to reproduce the original hardware experience: we want people to provide games, and we want to play those games. We want users to input the same values, and get the same audiovisual outputs from them.

If the user inputs "2+3", and gets back "5" in the same amount of time as the original hardware, is it really fundamentally important how the "5" is generated?

Unfortunately, we do not have the original transistor-level diagrams of the original hardware. And so we have to deduce how they work. And to do this, there are a myriad of methods.

We can read developer manuals and technical datasheets, we can analyze software designed for these devices, we can write our own code to run on these devices and log how the hardware responds, we can probe the pins on the chips and watch how they behave on logic analyzers, we can even decap the original chips with nitric acid and scan them in with electron microscopes!

But at the end of the day, no matter how we do it, it's all guess work until someone clones these chips at the transistor level.

For Want of a Name

Reproduction can be done on an FPGA with Verilog, or on a CPU with C++.

Hardware tends to be parallel, whereas software tends to be serial. Software can easily be made to simulate parallel processes through threading and state machines, and indeed this is how all CPU-based emulators work. But this does come at a performance cost. Thus, there is a clear advantage in terms of power efficiency to model hardware on an FPGA.

Furthermore, FPGAs generally tend to execute on their own, whereas software tends to run under an operating system, so latency advantages come into play. This does not have to be the case: an FPGA can exist inside a desktop computer, and a CPU can execute only a single software process that has direct control over all hardware. But in general practice, this is the case, and when it is the case, we can't deny that FPGAs hold the advantage in terms of latency. How much so is the topic for a different article. Estimates go as low as 5ms and as high as 50ms, depending on who you want to believe. How much that matters to you is going to be deeply personal.

You could also argue that it's easier to compare an FPGA to real hardware by comparing logic analyzer output on the chip pins.

However, CPUs have many advantages as well.

One major advantage is that it's vastly easier to observe the state of computer programs executing, through the use of tools like debuggers. ICEs, or in-circuit emulators, are unbelievably computationally expensive by comparison. With software, your logging abilities are endless and trivial. It can be done with FPGAs, but it is much more difficult.

Perhaps the biggest advantage is that pretty much everyone has a CPU. If you're reading this page, it was rendered on a CPU. Very, very few people have FPGAs at the ready. Fair or not, the reality is that there are far more C++ programmers than with Verilog, which leads to more available talent to work on and improve software written in C++.

Certainly, you can spend hundreds of dollars on an FPGA device. And certainly, you did spend probably many hundreds of dollars more on your CPU device.

But the economics of scale are important: especially for this field. When trying to recreate the functionality of a hardware device, there will always be flaws and imperfections. There is simply no way to verify that one has 100% replicated the original device's functionality, even in the most extreme cases.

What I am describing is essentially a variation on the halting problem, which is proven to be literally impossible to solve.

Therefore, the best we can hope for is lots and lots of testing. The more people using our recreation, and the more inputs they throw at it; the more issues that can be found, and the more accurate we can get things. Time also helps here.

What Is Important?

What's really important at the end of the day, to me, is not the technical details of how we recreate the original hardware. It's how closely the software running on our reproduction behaves like it would on the original hardware. Specifically, can the software determine that it's not running on the original hardware? If so, that's a bug. If the outputs went through the appropriate filtering (eg NTSC video encoding, analog audio conversion), could an end user tell the difference between software running on the original hardware and on our recreations? If so, that's a problem.

If my goal is to get from Ohio to Illinois, I am not concerned if my vehicle runs on gas, diesel, or electric. It's certainly a detail that matters to the people designing vehicles, of course! But to those looking to travel, they're just different types of vehicles. They aren't fundamentally different things.

Why Emulation?

The problem with claiming that FPGA devices programmed in Verilog are not emulators, is that it raises the bigger question, "well then, what are emulators??" - and that's a question that needs to be addressed. I'd like it if people could agree on what to call the field I've dedicated over thirteen years of my life to!

It's not just FPGA/Verilog versus CPU/C++. There's so many shades of gray.

One could argue that Verilog is an abstraction over manually laying out transistors on silicon. One could argue that C->HDL translators exist. One could argue about a hardware device containing a CPU that only executes as if it were the original hardware ... with an embedded program ROM inside of it ... to the point where from the outside it would be indistinguishable from the original.

Why *Not* Emulation?

The reason why this matters to me, is because when people make a strong point to claim that FPGAs are not emulation, I have to ask myself, "why are they doing that?? What does it matter?"; and the only conclusion I can reasonably come to is that the soomehow value emulators written for PCs less than emulators written for FPGAs.

Maybe that's not the case, and I'd love to have more discussions with them around this point. But when these claims are made, it feels very disparaging to me and my work in emulation. I hope those making these claims will understand that.

Accuracy

And what this really all comes down to is the accuracy of our reproductions. And this is the point I want to argue the most. There is absolutely nothing inherent in the design of FPGAs that make them capable of more accuracy than code running on a PC.

There's no utility in arguing about which theoretically leads to better accuracy: that is going to be entirely dependent upon both the skill and knowledge of the people working on them. There can exist awful FPGA devices, and amazing software emulators - and vice versa!

What matters is what exists in reality: the actual FPGA devices and software that already exists, and how accurate it is to the original hardware.

We don't need elitism, we need cooperation. Both FPGA devices and CPU-based emulators have their pros and cons. We should be working together, and bettering both of our products.

In Closing

Words are important. We need to agree on what words mean to have constructive dialogue. I can't ask someone to read a lengthy article like this when I want to explain what something that tries to replicate the original functionality of a hardware device should be called. Especially not in response to the question, "So what do you do for fun?"

So my request is for people to honestly ask themselves, "Why is it so so important that FPGA devices are not called emulators?"

The Super Nt is not fundamentally different than higan in what it is trying to do, so then, what word can we use to refer to both of them?

It is still my belief that the correct word for both is "emulator". And I hate to do this, but ... per Merriam Webster, an emulator is defined as "hardware or software that permits programs written for one computer to be run on another computer." So it isn't as though my position on this is coming from left field.

But I welcome your thoughts on this as well. It's important that we come to an agreement, regardless of the outcome. Thanks for reading!