Motorola 68060 FPGA replacement module (idea)

[billt]

x86 has performance, but it has no charm. Ask yourself which you would rather go for dinner with.

You're right! My OS4 laptop is way more charming than any of my pc laptops or my iBook is. I'm really happy i can go to dinner with that instead of the others...

[JimDrew]

Actually, I would prefer a super fast 040 over an 060 any day.  The reason?  From a programmer's stand point, the 060 requires several work arounds for the superscaler and branch prediction caches.  When I did the code for the Mac emulation, I ended up turning off half of the 060's features because code would blow up due to the Mac OS and many different Mac apps that were not compatible with a full running 060.  You have to deliberately write your code to be 060 compatible, and since the 060 didn't exist when the Mac OS was written (all of the way through OS8.x), the OS didn't support it.  How many 060 boards did you see for the Mac?  None that I am aware of... they went from the 040 to the PPC.

[spirantho]

I think from a Mac emulation point of view, you're absolutely correct. Because the Mac didn't know about 68060s, it was rather incompatible.

However, on the Amiga we are used to the 68060. We have the 68060 library and setpatch which is designed to solve those problems, and does a pretty good job of it to be honest. I very very rarely have compatibility problems because of my 68060 these days.

So in this case I think a 68060 is the better bet. Unless you want to run Fusion.

[freqmax]

What does 68060.library and setpatch do?

(and what is Fusion?)

[billt]

Actually, I would prefer a super fast 040 over an 060 any day.  The reason?  From a programmer's stand point, the 060 requires several work arounds for the superscaler and branch prediction caches.  When I did the code for the Mac emulation, I ended up turning off half of the 060's features because code would blow up due to the Mac OS and many different Mac apps that were not compatible with a full running 060.  You have to deliberately write your code to be 060 compatible, and since the 060 didn't exist when the Mac OS was written (all of the way through OS8.x), the OS didn't support it.  How many 060 boards did you see for the Mac?  None that I am aware of... they went from the 040 to the PPC.

Can you talk about the things that needed turned off for the Mac? Whoever may end up doing the processor design may find that useful to consider while making design choices for his processor, and what might be good things for configuration settings via setpatch or similar utility. what the problems were and any explanations for them could help make something more compatible all around, while also trying to improve performance as well as the fpga environment allows.

[Mr_Vanos]

This is all an interesting idea. I don't know what the state of available FPGA cores for 68040 are, but a cursory search did turn up a Coldfire core. Might another option be to use a Coldfire FPGA core and modify the microcode of it to get around the incompatibilities. Weren't there just a handful of unimplemented instructions and a couple of instructions that behaved differently?

[ChaosLord]

I would just like to clarify that MacOS has problems with the 060 because MacOS is crap.  MacOS is so bad that its creator threw it in the garbage and switched to a totally completely different OS.

On the Amiga, the 68060 is totally compatible with all normal software and causes no problems.

In order to make a program be incompatible to the 060 on the Amiga, one would have try really hard to do it on purpose, or do something that is plain illegal, or be banging the MMU or performing some weird esoteric function that no normal programmer would ever have any need to do.

On the Amiga we have MMU.library so nobody needs to bang the MMU.

I have been writing Amiga software since 1985 and none of my C or asm programs has ever failed on the 060.

Microsoft BASIC fails on the 060 because Microsoft BASIC is a pile of garbage that does wildly illegal things.  M$ BASIC won't even work on 020.

[Mrs Beanbag]

This is all an interesting idea. I don't know what the state of available FPGA cores for 68040 are, but a cursory search did turn up a Coldfire core. Might another option be to use a Coldfire FPGA core and modify the microcode of it to get around the incompatibilities. Weren't there just a handful of unimplemented instructions and a couple of instructions that behaved differently?

It might be a good starting point. Differences are:

1. No DBcc
2. No bitwise rotation (rol, ror)
3. No bitfield operations
4. Multiply instructions don't set flags. From the Coldfire manual:
CCR[V] is always cleared by MULS/U, unlike the 68K family processors

Coldfire also has a few extra commands (some of which would be quite useful, such as saturate and multiply-accumulate)

[psxphill]

It might be a good starting point.

If this is the one then I'm not sure that you get the source for it
 
http://www.ip-extreme.com/IP/coldfire_altera_v1.shtml
 
"DELIVERABLES

• Encrypted RTL source code and Qsys component for the CFV1CORE_ALTERA
• Quartus IP license
• Integration testbench and example test programs
• Documentation "

You only get the source code if you buy the asic version.

[freqmax]

There's already some hybrid 68020-030-040-060 core in the FPGA Arcade.

No need mess with proprietary cores with requirement for specific FPGAs. Nor any Coldfire incompatibilities.

A practical issue is that due to the through-hole nature of the 68060 PGA socket any PCB will be occupied by solder pads from the pins. A solution is to put double row a straight pin 1.27 mm header around the PCB edges. Such that a another PCB can be mounted on top and the space be used for FPGA, DC-DC and EEPROM.

A plain PGA-206 socket will leave approximately 20.3 x 20.3 mm and the XC3S1600E -FG320 used in the FPGA Arcade uses 19 x 19 mm which leaves a margin of 0.66 mm around the edges. Tight! And ofcourse there's then no space for the DC/DC and EEPROM which is essential for operation.

Btw, it seems perhaps x86 motherboard "Socket 3" fits as socket for 68060.

FG320:


PCB stack (illustration):


DC/DC (illustration):

[billt]

A practical issue is that due to the through-hole nature of the 68060 PGA socket any PCB will be occupied by solder pads from the pins. A solution is to put double row a straight pin 1.27 mm header around the PCB edges. Such that a another PCB can be mounted on top and the space be used for FPGA, DC-DC and EEPROM.

Sounds like that assumes the PCM is limited to a square footprint matching the 040/060 size. We don't necessarily need to maintain that limit. Figure out a good compromise with various existing CPU boards to avoid other components, and this thing can be bigger. Go off to one side for power and DDR3 slot. Imagine something like the Xcaliber memory board that plugged into an 040 socket and you put the 040 chip back on top, only this time the 040 is inside the FPGA, and you can toss out your old 040. (as an example)

http://amiga.resource.cx/exp/xcalibur

While an FPGA alone may fit inside the PGA matrix of an 040/060, power probably doesn't, nor would level shifters to be 5V safe. Unless perhaps there are surface mount pins that mount on the bottom of this thing only and the top side is wide open for components and routing... Not sure if that is practical though.

[freqmax]

I just want to make sure it will work in as many machines as possible. The more assumptions that are made, the more problems may occur when those assumptions are broken.

A simple level shifter often cited in the Xilinx documentation is a series resistor (current limiter) and a zener diode (voltage limiter) to ground. Then the zener positive end is wired to the FPGA.

But I still think however just as you that some compromise regarding size will have to be made. So layer-1 will contain through hole 18x18 2.54 mm spaced pins and 1.27 mm pin headers on the four edges (less routing mess). Layer-2 will contain 1.27 mm pin headers and be populated with FPGA, level shifters, DC-DC, EEPROM.

[freqmax]

I stumbled on the FPGA Arcade daughter board again. One can see that the USB-ports to the left and the capacitor to the right could be in the way for wider than designed width of any 68060 FPGA module.

The A4000 motherboard CPU module A3640 seems also to have some mechanical obstacles.

Same for the Blizzard 1230 IV (*) 68030 accelerator card for the A1200. Different CPU and socket, but it illustrate the issue that circuit boards with CPU sockets may be so packed that there's very little "extra" space.

[Iggy]

I've messed around with Coldfire. While it would make a great basis for an AROS system, the differences between C.F. and 68K make it a pain running 68K code.




fire

[JimDrew]

I would just like to clarify that MacOS has problems with the 060 because MacOS is crap.  MacOS is so bad that its creator threw it in the garbage and switched to a totally completely different OS.

On the Amiga, the 68060 is totally compatible with all normal software and causes no problems.

In order to make a program be incompatible to the 060 on the Amiga, one would have try really hard to do it on purpose, or do something that is plain illegal, or be banging the MMU or performing some weird esoteric function that no normal programmer would ever have any need to do.

On the Amiga we have MMU.library so nobody needs to bang the MMU.

I have been writing Amiga software since 1985 and none of my C or asm programs has ever failed on the 060.

Microsoft BASIC fails on the 060 because Microsoft BASIC is a pile of garbage that does wildly illegal things.  M$ BASIC won't even work on 020.

Well, there are quite a few Amiga programs - including several of my own that all follow 100% legal programming practices (according to common sense and the RKMs) that will not run on an 060 with superscalar and/or branch caching enabled.  I don't recall all of the reasons behind the issues.  I should go look at the mmu.library replacement that we made for EMPLANT and FUSION... I know I commented some things there.  I know that self modifying code is definitely one of the things that causes a problem when one of the cached instructions in the pipeline has been modified (like a branch table).  Yes, I consider self-modifying code 100% legal.    You are suppose to flush the caches (or turn them off) with self modifying code, but when you do that you are then running at sub-030 speeds.

The 060 really only adds dual instruction pipelining and a 4-way cache.  A higher speed (100MHz+) 040 core would probably be better in the long run, especially if it handled floating point without completely stalling the core like the 060 does.

[ChaosLord]

Well, there are quite a few Amiga programs - including several of my own that all follow 100% legal programming practices (according to common sense and the RKMs) that will not run on an 060 with superscalar and/or branch caching enabled.  

Are these programs all emulators?

Emulators have to do weird exotic things and/or deal with weird exotic things in order to get good performance.  These weird exotic things are things that a regular programmer never deals with.

I don't recall all of the reasons behind the issues.

I am not entirely clear if your complaints about the 060 are not simply that all the first 060s had bugs in them.  Later on those bugs were ironed out.  Iirc at least one of the bugs only happened when was superscalar mode was active so it could be avoided by turning it off.

I am thinking that if you tried a later revision 060 you might like it.

  I should go look at the mmu.library replacement that we made for EMPLANT and FUSION... I know I commented some things there.

I remembered u coded Emplant but I didn't know about Fusion.  I never actually used either one.  The only mac emu I ever used was A-Max (I think that is what it was called) way back in prehistoric times.

  I know that self modifying code is definitely one of the things that causes a problem when one of the cached instructions in the pipeline has been modified (like a branch table).  Yes, I consider self-modifying code 100% legal.    You are suppose to flush the caches (or turn them off) with self modifying code, but when you do that you are then running at sub-030 speeds.

If u only modify your code once, flush the cache and go on then its not such a big deal... but if you have to do it in a loop then speed dies.

Does your Emu scan opcodes and runtime replace all those ILLEGAL instructions that MacOS used for Quickdraw etc. ?

The 060 really only adds dual instruction pipelining and a 4-way cache.  A higher speed (100MHz+) 040 core would probably be better in the long run, especially if it handled floating point without completely stalling the core like the 060 does.

040 core is slow at math.  060 is fast at math.  040 has no branch prediction too.