Motorola 68060 FPGA replacement module (idea)

[Mrs Beanbag]

What you're suggesting will break I/O, which is the major use of TST. You can only perform the read once & you can't do the read until all the registers are correct, or you could be reading from anywhere.

Good point. I was only thinking of tests on registers.

[JimDrew]

I think the thing with TST being the #1 instruction in SEGA games is either:

A: All those games were compiled with either SASC or GCC which generates silly wasted TST instructions all the time.

B: The Sega Genesis uses PIO (Polled IO) for some things so it has to constantly TST a certain memory location all the time in a loop.

C: All of the above.

I agree... with the MacOS, TST is not even in the top 10 instructions used.

[ChaosLord]

I agree... with the MacOS, TST is not even in the top 10 instructions used.

Awesome.  Thanx for the confirmation.

[bloodline]

I've had a bit more of a think about this... Would it make sense to design a RISC CPU for the FPGA with the same condition codes/flags as the 68k (where instructions would set the flags as expected), but limit all the exotic addressing modes to the load/store instructions?

A simple MMU could be added to mark memory block, to assist a JIT... That way we could have an FPGA CPU that could execute code really fast, allow for easy mapping of 68k instructions to the native instructions and move the 68k->native decoding to a software JIT

[mikej]

I've had a bit more of a think about this... Would it make sense to design a RISC CPU for the FPGA with the same condition codes/flags as the 68k (where instructions would set the flags as expected), but limit all the exotic addressing modes to the load/store instructions?

A simple MMU could be added to mark memory block, to assist a JIT... That way we could have an FPGA CPU that could execute code really fast, allow for easy mapping of 68k instructions to the native instructions and move the 68k->native decoding to a software JIT

This is quite a neat trick, I've been looking into it for my own 68K core.
The Replay PS2 keyboard/mouse controller uses a picoblaze softcore as it is smaller than the logic used otherwise - and you can to a lot more.

http://www.roman-jones.com/PB8051Microcontroller.htm
Here they are using it as a 8031...
/MikeJ

[bloodline]

This is quite a neat trick, I've been looking into it for my own 68K core.
The Replay PS2 keyboard/mouse controller uses a picoblaze softcore as it is smaller than the logic used otherwise - and you can to a lot more.

http://www.roman-jones.com/PB8051Microcontroller.htm
Here they are using it as a 8031...
/MikeJ

I've actually spent a few days trying to design my own 68K emulator, to work out how to modify the MIPS ISA to make it super efficient at 68k emulation... I used a three jump table design, with first using the first 4bits of the instruction, the next jump table using not the next three bits, but the three bits after them and then finally the upper three bits below the top nibble... At this point I got fed up... There seems to be about 504 unique instructions, but little organisation... I prefer RISC here

[bloodline]

This is quite a neat trick, I've been looking into it for my own 68K core.
The Replay PS2 keyboard/mouse controller uses a picoblaze softcore as it is smaller than the logic used otherwise - and you can to a lot more.

http://www.roman-jones.com/PB8051Microcontroller.htm
Here they are using it as a 8031...
/MikeJ

Thanks for the PicoBlaze hint, that lead me to the microBlase which lead me to the DLX... A sort of stripped back MIPS

[Heiroglyph]

I had considered this as well.  I didn't think of modifying the original CPU quite as heavily as you mention though.  It's a very interesting idea.

That brings me back to the question of just how much performance can you get out of a general purpose FPGA CPU? Is that a sufficient upgrade for the time and money spent?

Edit: By performance, I don't mean MHz or MIPs, actual work done.  RISC vs CISC instructions per second are as meaningless as MHz.

[JimDrew]

Use several BIG lookup tables if you can afford the memory.  I tried several smaller tables, but ended up using a couple of large tables.  I think the emulation (PC) ended up being around 1.25MB in total size because tables were imbedded in the executable (along with the instruction emulation), repeated over and over in most cases, instead of being built in memory.  But, the speed difference is dramatic.  You have to remember, if you can save just 4 cycles, benchmark programs and anything else sitting in loop is going to really benefit from it!

I think Mike's table based microcode lookup is going to the most efficient (and fastest) method of doing the microcode core emulation.

[psxphill]

I've actually spent a few days trying to design my own 68K emulator, to work out how to modify the MIPS ISA to make it super efficient at 68k emulation...

Going from a general purpose cpu would end up as an inefficient microcode based 68k.
 
It makes sense to dump the original 68000 & 68010 microcode to emulate those processors. Not all of it's done yet though, there is some work hopefully happening soon.
 
I don't know how much of the 68020 and later were microcoded.

[AJCopland]

Going from a general purpose cpu would end up as an inefficient microcode based 68k.
 
It makes sense to dump the original 68000 & 68010 microcode to emulate those processors. Not all of it's done yet though, there is some work hopefully happening soon.
 
I don't know how much of the 68020 and later were microcoded.

That isn't the idea thought is it? He mentioned looking at the MIPS as a basis so if I was doing that it would be to take the ALU and other sub-sections and then work out how to feed the 68k through it.

Rather like parts of the Natami/N68k idea was inspired by Paul Metzgen's ALU paper "A High Performance 32-bit ALU for Programmable Logic", it's not meant for 68k but it's a proven and powerful basis to build upon.

Although yes I agree that a microcoded 68k would probably be a bit rubbish. That wasn't at all the impression I got from Bloodlines post.

[Mrs Beanbag]

Yes the ALU is a piece you could get from various places ready made. I was pondering the possibility of using the cache management systems out of the OpenSPARC core.

68060 is definitely microcoded to some degree, move , is split into two "standard operations". No doubt fancy addressing modes are split up into even more operations. The RISC cores (x2) seem to be able to handle register-memory operations on their own though.

[Hattig]

Yes the ALU is a piece you could get from various places ready made. I was pondering the possibility of using the cache management systems out of the OpenSPARC core.

Don't some FPGAs actually include ALUs as hardware on the chip, as they're a common component of the logic that people implement using an FPGA.

However for the non-ALU part, using features from other fast cores makes a lot of sense, e.g., the cache interface and implementation and so on.

[FrenchShark]

This is quite a neat trick, I've been looking into it for my own 68K core.
The Replay PS2 keyboard/mouse controller uses a picoblaze softcore as it is smaller than the logic used otherwise - and you can to a lot more.

http://www.roman-jones.com/PB8051Microcontroller.htm
Here they are using it as a 8031...
/MikeJ

Hello,

I have done that already with the J68 core :
https://github.com/rkrajnc/minimig-de1/blob/master/minimig-src/j68/j68.v
It is loosely based on the J1 core (hence the name). So the heart of it is a stack-based CPU.
The ALU is a 16-bit ALU, compatible with a 68000 ALU.
It has some special micro-instruction for the effective address computation.
The core must run 2x to 3x faster than the original to reach the same speed.
The advantage is the size : less than 2000 LUTs. Micro-code take 2048 x 20 bits.
With further optimization (cache, prefetch, 32-bit ALU and effectve address ALU), I am sure it can be as fast as a 030/040.
Right now, this softcore can boot a Kickstart 2.04 in my AmiSOC core.

Regards,

Frederic

[ChaosLord]

How many LUTs does it take to make a slice?


Trying to figure out which is smaller.

[FrenchShark]

How many LUTs does it take to make a slice?


Trying to figure out which is smaller.

Usually, one slice contains 2 LUTs.