MMU on FPGA with H5 Phoenix platform

[ijor]

We have a FPGA running a cycle exact MMU implementation on an H5 dev board:

20240912_142638.jpg

20240923_141958.jpg

The FPGA board itself, as you can see, is a Qmtech board. The adapters were made by @exxos and also based on work by @Icky . Thanks a lot to both!

Testing closure:

20241014_210924.jpg

I implemented an enhancement that you could select a specific wakeup. Very useful for debugging and testing purposes:

20241014_210521.jpg

One type of tests I always do and consider crucial, is to tests programs and configurations that fail in real hardware. An accurate implementation (either FPGA or emulator) should fail these cases as they fail in real hardware. The NOSTALGIC original (not patched) demo works in some wakestates, but fails in others (that's why it was eventually patched):

20241002_131515.jpg

20241002_130830.jpg

PS: Sorry for the pictures quality :(

[sporniket]

amazing work :)

[troed]

*tears of actual joy*

This is amazing! Many many thanks for this work. How is the clock synchronization with GLUE for the wakestate selection performed?

[rubber_jonnie]

Great work :)

[tin]

This is so very awesome! Thank you so much, Ijor et al.

[alexh]

Interesting work. Is this a new design? Or based on your work for FX Cast? I understand that making an FPGA of individual chips includes an additional challenge to a core (e.g. collection of chips) with real bidirectional I/O.

[Cyprian]

Great. Many thanks @ijor

[ijor]

How is the clock synchronization with GLUE for the wakestate selection performed?

Well, it is far much easier to implement this inside the FPGA, than with external logic. I can detect the GLUE wakestate alignment by monitoring the DE signal, and then I can adapt my own phase accordingly to the wanted wakestate.

Interesting work. Is this a new design? Or based on your work for FX Cast? I understand that making an FPGA of individual chips includes an additional challenge to a core (e.g. collection of chips) with real bidirectional I/O.

It is based on my old core. But yes, as you are saying, there are additional requirements when you need to interface with multiple "real" chips. I also had to implement the old school Async DRAM interface from scratch, as my cores were designed for the "MiST/MiSTer" hardware that use synchronous DRAM.

Particularly challenging is to adjust the timing to interface with chips that have no published timing specifications, like GLUE and SHIFTER in this case. Without datasheets you have to make some assumptions based on measurements and some common sense. But even with datasheets it can be challenging. I.e, it is quite difficult to meet timing for the worst case 68000 specifications. According to the 68K datasheet the clock to output delay can be up to 70ns. That's more than half cycle at ~8MHz! I'm sure the original chips didn't met worst case timing. They assumed, and probably correctly, that you never actually run the chips at the worst case conditions.

Plus the 68K bus is designed to be asynchronous. The original chips use either async latches or flip flops clocked by the chip select signals (not by the actual clock). As I"m sure you know, it is important to avoid these old school async techniques on modern FPGAs. But then it is not so easy to maintain cycle accuracy when you use a fully synchronous design. But what can I say, it was a lot of fun! :)

[Badwolf]

Wow! Congratulations!

:o

I admit I had clicked on the topic thinking it was another 'is there such a thing...' post before I saw who'd written it. :lol:

BW

[exxos]

:bravo:

I want to further add that this is a monumental step forward in the Phoenix platform development. As mentioned previously many times, once we can control the chipset within FPGA, we can add to it as much as we want, including increasing memory, increasing the speed and adding in other features that we may see fit in the future. A 32Mhz true bus speed may finally be on the horizon... With of course the option to switch back to the original speed which are cycle accurate with the original Atari chipset to maintain maximum compatibility with legacy software.