FPGA Development Deep Dive<br>– ModRetro
Skip to content
Your cart is empty
Continue shopping<br>Have an account?
Log in to check out faster.
Your cart
Loading...
Estimated total
$0.00 USD
Check out
Log in
Country/region
United States |<br>USD
Search
Australia
AUD
Austria
EUR
Belgium
EUR
Canada
CAD
China
CNY
Croatia
EUR
Czechia
EUR
Denmark
EUR
Estonia
EUR
Finland
EUR
France
EUR
Germany
EUR
Greece
EUR
Hungary
EUR
Ireland
EUR
Italy
EUR
Japan
JPY
Luxembourg
EUR
Netherlands
EUR
Norway
NOK<br>kr
Poland
EUR
Portugal
EUR
Slovenia
EUR
Spain
EUR
Sweden
EUR
Switzerland
CHF<br>CHF
United Kingdom
GBP
United States
USD
Country/region
United States |<br>USD
Search
Australia
AUD
Austria
EUR
Belgium
EUR
Canada
CAD
China
CNY
Croatia
EUR
Czechia
EUR
Denmark
EUR
Estonia
EUR
Finland
EUR
France
EUR
Germany
EUR
Greece
EUR
Hungary
EUR
Ireland
EUR
Italy
EUR
Japan
JPY
Luxembourg
EUR
Netherlands
EUR
Norway
NOK<br>kr
Poland
EUR
Portugal
EUR
Slovenia
EUR
Spain
EUR
Sweden
EUR
Switzerland
CHF<br>CHF
United Kingdom
GBP
United States
USD
Search
Log in
Cart<br>00 items
Save up to $60 on the Chromatic Starter Pack
We are excited to share a deep technical look at the M64's FPGA development, written by our core development partner Robert Peip (aka FPGAzumSpass). The M64 FPGA, memory subsystem, and interfaces were designed with accuracy in mind from the start. Even though we still have work to do (FPGA work takes a LONG time), we are excited by our hardware architecture's full potential. A huge upside is picking PSRAM over DDR as an early decision we know was right. We firmly believe that M64's hardware architecture is superior.
We're also excited to see how others unlock M64's potential. As a proof-of-concept, we ported a different core from MiSTer to M64's hardware to prove it was possible, and only time will tell which others are brought over. M64's design is a statement towards shedding the chains of hardware limitations available to the open-source retro-gaming community by having a powerful base with a large and fast FPGA, four fast and low latency PSRAMs and 4K-capable video output. Seeing other cores run on M64 hardware is only possible if we open source our design, and that's exactly what we're committed to doing.
What Makes Hardware Emulation Hard
By Robert Peip (aka FPGAzumSpass)
Accuracy in both software and FPGA emulation is often discussed as a hot topic. There are several misunderstandings and wrong assumptions around it and I want to take a deeper dive into this topic. First we'll look at what accuracy is and what FPGAs can do for that. Then we'll look at examples in games and tests, finishing with the current state of the M64.
Accuracy vs Cycle Accuracy
When replicating the behavior of a classic gaming console, ideally all the internal hardware components of this console are replicated. These can be processors, memory modules, or specialty-purpose chips. A clock is what typically drives all of these electronic parts.
The N64 CPU clocks in at 93.75 MHz, which means it can execute calculations 93,750,000 times per second.
While simple calculations (instructions) only take a single cycle inside the CPU, others can take much longer. For example, it might cost ~70 clock cycles to do a 64-bit division or 6 cycles to do a floating point multiplication with N64's CPU.
When emulating the CPU, care has to be taken that these timings are correct, otherwise the execution speed is wrong. You can easily see that if some emulator executes this multiplication in one clock cycle instead of six and a game is using plenty of them, it would make the game run too fast.
This is sometimes easier said than done with such pipelined CPUs, as they execute multiple instructions in parallel to some degree. Maybe the next instruction is not in cache and needs to be fetched from RAM while the multiplication is running in the background and due to the RAM read taking a while, the multiplication is already done when the RAM read is finished.
What makes things even worse is that multiple chips communicate with each other and run in parallel. This can lead to interlock dependencies and increase the effect of inaccuracies even further, or cancel them out by luck.
Why Bother Using an FPGA?
To make things short: A fully accurate emulator is easier to write in software than to build in an FPGA. The catch is execution speed, not correctness.
Emulation has relative deterministic behavior in the end and this can of course be done in software. In fact, every digital FPGA behavior can be simulated in software just fine. This is done during emulator development all the time.
Why even bother with FPGAs then?
Well, the more you want to emulate the parallel behavior of chips or functionalities inside a chip, the tighter the timing requirements are. The N64 does hundreds of things in parallel each clock cycle and to fully replicate that in software with...