The MMU is one of the areas we need to talk about and work out. Gunnar's MMU is very simple and incompatible with the 68k MMU in the 68030-68060. The 68030 MMU is very flexible and has some interesting ideas but is far from modern MMUs. The 68040 and 68060 MMUs are similar and very capable but the page sizes only go up to 8kB which is small and not optimum for modern large memory sizes.
We are not talking about modern applications here. We are talking about Amiga applications. Still, the page size for the intels is 4K, with optional huge page support. The 68030 design could offer that out of the box ("early termination descriptors").
Enlarging the page sizes would break compatibility with the 68040 and 68060 MMU
Compatibility with *what*? Programs that hack on the MMU should go anyhow. As far as other Oses are concerned, I cannot tell you what they do, but one way or another, the core requires some software support in first place, in the same way the 68060 required software support. As far as the mmu.lib is concerned, every page size works. (Provided it is a power of two). Still, 4K pages are - for Amiga - really not too bad. In the end, I would probably not go for a complete 68060 MMU in first place, but rather emulate parts of its functionality in software in the same way the 68060 emulates parts of the chip in software. Thus, I would probably only have the ATC logic on chip, and would do the table-walk in software (i.e. that part that collects the descriptor from RAM). Such a construction could emulate any MMU from 68851 to 68060 with a bit of software support.
ThoR or Gunnar could probably give more details as the MMU is not my strong point. The 68060 MMU allows virtualization (virtual addresses and physical to virtual translation) which is a great modern feature but it has a cost.
That is an elementary feature that goes for all MMUs right away.
All cached addresses which may have a virtual address need to be flushed on context switches which has overhead. The 68060 may require this already with it's branch cache.
No, that's rather a matter of whether the cache is addressed by physical or logical addresses. If it is addressed by physical addresses, context switches are free. Only the relatively slow 68030 and 68020 caches were logically indexed, everything above that was physically indexed, and hence, context switches do not require a cache flush on these processors.
Memory performance can degrade with many page misses from accessing memory in a dispersed or random way. More hardware can make up for this problem but at a cost. The CPU pipeline can increase by 1 stage depending on how the MMU is designed also.
The major problem with a MMU is really the enlarged pipeline, which limits throughput.
Gunnar and Jens know the best way to make a modern MMU and ThoR could help with the design. Gunnar is resistent to a more advanced MMU with virtual addresses in an FPGA because of the cost of performance and because the Amiga doesn't need it. The overhead of such an MMU as a percentage of performance is much smaller in an ASIC and the advantages for an open platform 68k board which would support multiple OSs is more compelling.
Jens is making good hardware designs, but I don't believe he has the knowledge in CPU design. Gunnar has, I can certainly give a broad design of a MMU that is powerful enough to emulate everything with proper software support, and design the system software for that. But whether such a design is performing well and worth implementing in an FPGA is really something only Gunnar can answer.
This still leaves the question of how compatible an updated and modernized 68k MMU could be.
See above. I have a small design in my back-head somewhere that is a software-driven MMU capable enough to emulate the 68851 up to the 68060. But, as the 68060, it requires an additional support library.
Some changes to existing 68060 MMU support in the OSs which support the 68k would be necessary for optimal performance at least and maybe even to be usable. Personally, I think an MMU which supports virtual addresses is an important modern feature which would be important if competing against the Raspberry Pi with an ASIC.
Actually, a MMU that does not distinguish logical and physical addressing is hardly ever an MMU.
Embedded applications use memory protection more and more all the time but I expect the extra performance to be more important than virtual addressing.
All the nice features like kickstart remapping, zero-page remapping or MuRedox require a logical addressing that is different from physical addressing. You could hard-code such cases in the FPGA, but how ugly a design is that? It would be "Amiga only". It's not the type of design I would call "elegant" or "future proof" (for whatever "future" and "Amiga" could mean together, but hey, if you design something as an engineer, you want to make it right, ok?)
