TG68 - The Open Source Minimig CPU into the FPGA

[Cymric]

So, from the software running on the machines point of view, the only difference is that the 68060 has floating point?

And an integrated memory management unit. Plus a superscalar architecture (though not pipelined, if Wikipedia is to be believed). The latter is not much of a problem since there never were any official Amigas coming from the main manufacturer with a 68060 installed, and it's just a means of speeding up execution rather than implementing a different set of mnemonics.

Personally, I think that if a more advanced make of CPU were to be coded into a FPGA, then it should be the one with the most informative exception handler stack frame (I vaguely recall that this began with the 68030, which could be made to recover from nearly everything you threw at it). A full implementation of the 68882 would be useful; I don't think the full 68851 is required and one can make do with the MMU-subset found in the 68030 and 68040. From the looks of the software-68000, it shouldn't be much work nor take much extra gates adding the instructions and abilities of a plain 68030 given that almost nothing changed in the register model save for the addition of proper support for longwords.

[Cymric]

freqmax wrote:
Guess the 2 instructions in parallel can be achived with some instruction decode pipeline?

Or multiple execution units. The question is: why would you want to? It's an addition to increase performance on the original chip, not to increase its capabilities. The FPGA'd 680x0 relies on a completely different model to increase its performance, and modelling the performance enhancements of the original chips is not guaranteed to work for the FPGA-equivalent. I know very little of FPGA-programming, so I'm not even sure a standard trick as introducing a cache will work. One would say it would, true. But it's the nature of the FPGA which determines what will work and what will not, and I'll leave that to the actual coders to sort out the details.

[Cymric]

downix wrote:
Not singling you out specifically, but this has a bit in it that is driving me a bit nutty.  A lot of people keep calling this a software CPU.  No, it's an HDL CPU, that is it's a description of hardware.  While it can be run as software, it's end goal is to be hardware.  So please, let's just call it the TG68000?

You are correct in that I get my terminology mixed up, and I shouldn't be doing that. For the record, I know that it isn't a genuine 'software' CPU in the ASIC sense.

However, thinking of the HDL CPU as a genuine software CPU when coupled with advanced Minimigs does aid people in showing why it isn't important to implement the full superscalar, cache rich, branch predicting core of a 68060. Even a 68020 isn't particularly useful.

[Cymric]

freqmax wrote:
Regarding 68020, is it mainly the 32bit capability that is needed/wanted from a 68000->68020 upgrade?
In such case maybe a hybrid solution where the HDL 68000 is made 32-bit capable is an easier and faster approach to accomplish any 68020 needs?

You cannot make a 68000 32-bit without turning it into a 68020; there's portability issues to consider. And the difference between a 68020 and 68030 is very small. Since the latter has a more informative stack frame upon handling of exceptions, I'd be in favour of doing a 68030 instead of a 68020.

Other factors are ofcourse FPU, and MMU. I know MMU is used by unix operating systems. But for anything else are these things really used in the Amiga enviroment?

They are used in program development in order to catch badly behaving programs. I've experienced enough crashes on my EC030 to know I would want its functionality, even if it isn't supported by the OS.