Motorola 68060 FPGA replacement module (idea)

[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

[FrenchShark]

How many LUTs does it take to make a slice?


Trying to figure out which is smaller.

Usually, one slice contains 2 LUTs.

[FrenchShark]

Frederic,
your 68K core (Verilog) code looks interesting and appears to have taken a fair amount of effort. This is some good work.
How much validation have you done on your 68K Verilog CPU core?
The MC216 is the only place that this core is in use as the 68K core? The older Minimig code ports use the TG68K VHDL 68K core (Minimig DE1/DE2/MIST code ports).
I looked over the J1 Fourth CPU paper as well.

It is not yet in the MCC216 core.
The next Amiga core in the MCC will have the J68 and a new (smaller) ECS core.
The whole Amiga core takes just 8000 LUTs.
I have validated the core with a test assembly code that exercises all opcodes/addressing modes (over 1500 cases). The registers outputs after each instruction was compared with Musashi's registers outputs.
I also ran some test programs that use the fast floating point library from Motorola.
The VUBUG monitor was also tested on it.
Finally, I was able to virtually start the Kickstart 2.0 under Verilator : 10 seconds of Amiga execution takes around 1 hour of simulation on a core i5 430M.

Regards,

Frederic

[FrenchShark]

Okey so ur 16-bit 68000 core is about triple the size of that PB8051 Microcontroller thingy that MikeJ is using.

But ur core has triple the style points of a PB8051.

I was comparing the ways :
- Taking a picoblaze to emulate a 8051
- Taking a J1 to emulate a 68000.
I would not take a J68 just to make a keyboard controller. :-)

Moreover, emulation is not the exact term since the 68000 "emulation" is heavily HW assisted :
- instruction decoder generates microcode address
- specialized micro instructions help evaluating the effective address
- the ALU is 68000 compatible

On the J68, the bus interface is what is taking most of the room (1000+ LUTs).
Big endian is cool but really resource hungry.

Regards,

Frederic

[FrenchShark]

Fredric,
In your 68K Verilog code, I did not see code for the 68k interrupt acknowledge cycle (IACK cycle). The Amiga uses the 68K interrupt acknowledge cycle while the Atari ST (68K) uses both 68K Auto vector interrupts & 68K IACK cycle (for 68901MFP).
I may have missed this in your code, or do you need to still add this support in your 68K core?

Since all the Kickstart ROMs contain 0018 0019 001A 001B 001C 001D 001E 001F at location FFFFF0 - FFFFFF, I am not using interrupt aknowledge cycles, just auto vector.
That's enough for running an Amiga.

Regards,

Frederic

[FrenchShark]

All official kickstarts contain that & only 68000 based Amiga's use it.
 
However it can be changed to allow for WHDLoad quit key support on 68000 by pointing the vector back inside rom and only passing on to the actual vector if the quit key is not pressed (basically what the ACA500 will do ).
 
I don't know whether Datel Action Replay and the rommable hrtmon make use of this functionality also, but I can imagine it would be useful.
 
I think it's worth supporting the cycles if you're doing a pure 68000 core.

I do not have anymore room in the microcode ROM.
I can anyway do it differently since I have full access to the design, for example I can map the interrupt vectors at a different address by changing the micro-code.

Big vs little endian is an arbitrary choice.
 
The name comes from Gulliver's travels.
 
http://en.wikipedia.org/wiki/Lilliput_and_Blefuscu
 
Accessing little endian data on a big endian processor (and vice versa) is an extra overhead. However when emulating a 68000 the overhead is very small because it can't access unaligned data & it just takes a well placed xor of the address lines. 68020 and later plus all x86 processors can do unaligned access, so you have to take those cases into account. I'm not sure there should be any overhead in an FPGA implementation.

big endian is human's natural order. little endian is computer's natural order.
A xor on the address lines is just your view as a programmer. Where are address lines A0 and A1 when you are dealing with a 32-bit data bus ?

Regards,

Frederic

[FrenchShark]

Little endian is no more natural for a computer as big endian. The only difference in hardware is how you calculate the strobes and shifts. 32 bit values on a 32 bit bus are the same whether it's big endian or little endian, it's only when you access bytes or words that anything changes.
 
xor'ing addresses with 3 for bytes and 2 for words just affects how the host CPU generates the strobes and shifts, as most CPUs use byte addresses for everything.
 
In hardware then you will always have to calculate the strobes and shifts from the low bits of the byte addresses and whether you calculate them for big endian or little endian makes no difference in terms of complexity. If you're doing anything extra for big endian then you're doing it wrong.

OK, let's take an example : ADDI.L #$12345678,D0 on a 68000 CPU (16-bit bus).
You need to completely load immediate value $12345678 from memory before you can actually add it to D0.
This won't happen on a little endian CPU because you have the data in the correct order for the carry propagation.

Voila,

Frederic