Motorola 68060 FPGA replacement module (idea)

[JimDrew]

It's certainly possible to replicate any of the 68K CPUs with an FPGA.  The end result would depend on the work put into it, including the level of compatibility desired.  The 68060 would definitely be the most work due to the superscaler and pipelines. The FPU/MMU (and basic opcodes) would be pretty straight forward.  Altera makes a couple of FPGAs with sufficient internal memory that could mimic the cache.  It could all be done, but i dont think there is not enough of a market really to attract any serious developers that can do this type of work.

[JimDrew]

I am curious why there is some idea of a shortage of 68060 chips?  There are tens of thousands of these chips, both 50MHz and 60MHz (MC and XC versions) available from suppliers in China.  These were used in the Northern Telecom call center boards.  There is a thread here about this.  Just pull the chip with the heat sink and put it in your Amiga (or replay) board.

eBay has a slew of these boards, for about 1/2 of what 68060's by themselves are selling for.

[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.

[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.

[JimDrew]

I never saw in crashing of the Mac OS itself under FUSION, but there were plenty of apps that did not like superscaler and/or branch caches enabled.  However, in all fairness these apps were written for the 020/030, so minimal cache flushing was required for self modifying code, which is quite common for decompression programs, encryption for copy protection, etc.  Some of these issues could be due to buggy superscaler mode in early 060 revs.  I went from the first rev available from Phase 5 to the PPC, so I never tested any newer revs.

I know that floating point math scores were often times faster with the 68040-33MHz X-Calibur board than the Cyberstorm 060-50MHz.

Sadly even a 75MHz 060 is really slow compared to modern Intel processors, so the idea of a dedicated Intel CPU adapter is probably the fastest and least expensive option.

[JimDrew]

The experienced users that have this much hardware/software/firmware knowledge generally do not work for free.  So, with an extremely limited market, there is really no desire to work on something where you won't at least recoup your time investment.

There are quite a few neat Amiga products I would make if I could sell thousands of each of them.  But, there is no chance for that.  The C64 market is MUCH bigger (as I am finding out and making products for it).

[JimDrew]

Would the x86 doing nothing more than emulating a 68K be higher performance than the FPGA? That's possible.

Yes.  Some glue logic (Mach or some type of small FPGA) and probably a bit of dual ported RAM would make a great 680x0 emulator.  The performance could be quite impressive even with an older x86 CPU.  The x86 CPU would be not much more than a state machine and floating point processor.  This is a project that makes sense to me... and since I have written a 68040 core in x86 assembly, I could probably lend a hand.  

[JimDrew]

I guess it depends on how fast you want things to go.  A 75MHz 68060 is around 110 MIPs.  An Intel Pentium Pro was 541 MIPs.  Funny thing is that the Xenon x86 used in the XBox360 is 19,200 MIPs.  If you really want to make things go, try out a Core i7 3960x at 177,730 MIPs.

I think the biggest challenge in this design would be to figure out how slow of an Intel CPU you would need to so you weren't just wasting time waiting on the bus to change.

[JimDrew]

You can get one of Xlinx's Zynq-7000 devices, which is basically an FPGA with a dual core ARM Cortex-A9 all in one chip.

http://www.xilinx.com/products/silicon-devices/soc/zynq-7000/silicon-devices/index.htm

That might be the Holy Grail!  An integrated FPGA with twin high speed ARM cores would work great @1GHz.    This means just one chip interfaced to a 040/060 PGA socket plug.  I am sure you could keep the entire thing within the form factor of a standard 040/060 chip.

edit - these are way too expensive!  You are still better off with a $50 x86 CPU.

[JimDrew]

Endian is not an issue.  You can swap with the FPGA.  

My 68040 core handles everything without needing the endian reversed, but I am sure it would be significantly faster without having to do that.

The only thing I don't do in my code is instruction cycle counting.  That could be done, but I never bothered.  The FPGA could be used to trigger an event to denote the end of the instruction cycle (where a process loop just waited for this to occur).  So, based on the speed of your x86 CPU, you could reliably have cycle exact timing at a speed limited to by your fastest instruction (nop).  I know my Mac emulation has no JIT type of stuff, is 100% assembly, and is frightenly fast on modern PC hardware.  I will have to test it on my Sandy Bridge setup to see how fast of a 040 Mac it is.  

[JimDrew]

I know for fact you can do the byte swap/word swap with the FPGA in real time, but depending on how fast the x86 is it could slow down the operation of the 680x0 emulation.  By the way, the fastest way to swap bytes and words is through a big lookup table.  It's faster than trying to convert it by hand using shifts, ANDs, and XORs.   If you run everything backwards in memory you don't need to do the byte swaps, but the x86 doesn't cache backwards, and anything requiring DMA (like audio) won't work.  It's also interesting to note that there are certain x86 addressing modes that although reduce the size of the code, significantly reduce the throughput of CPU instruction lookup.  I learned quite a bit about the Intel and AMD architectures when I did the port of FUSION to the PC.  It is always faster to ADD an offset twice and branch than it is to use a *2 in a branch instruction.  The *2 stalls the pipeline while calculating the address.  When I created FUSION-PC, I made a histogram of the instructions used during the Mac boot up.  I was surprised that fewer than 10% of all of the available instructions were used when the Mac booted.  I would bet the Amiga boot up is very similar.

[JimDrew]

How do you know if you need to swap or not ? For example a memory copy function that uses 32bit transfers but may be copying strings that may not be byte swapped ?

greets,
Staf.

There are several ways to handle this.  One requires that the FPGA follows the instruction stream, so as instructions are decoded the data bus can be swapped depending on the incoming instruction.  The other way is by having the x86 side (during the decoding) change the bus interface.  As I stated before, this will limit the speed of the emulation to how fast the FPGA can respond, which could be much slower than a fast x86 chip.  So, with a fast x86 chip, it would probably be faster to do the byte swaps manually (through shifts/ORs/ANDs/XORs/etc) or though a lookup table if you have enough memory for that.

As far a copying strings, well the x86 is always backwards Endian from the 68K, so you always have to swap words and long words when fetching/storing data.

[JimDrew]

But then it goes in the cache, and there are any number of things that can go wrong. Such as if you read an address as a longword for some reason, and then go on to process it as part of a string, it will have been byte swapped into the cache. Either you turn the cache off and destroy any advantage of using such a fast CPU, or you have serious difficulties ensuring coherence.

Huh?  You have to remember there are already 68K emulators for the x86 that do the byte swapping.  I believe I have the fastest non-JIT type ever made.  There are no issues with caches, and there would not be any under any circumstances.  ALL data with a x86 is backwards from the 68K (little Endian vs. Big Endian), so everything dealing with words or longs is swapped and remains that way.  If the FPGA performed the swap instead of doing it in software, I would hope that it would be cached!

[JimDrew]

I think we're having trouble understanding what you're suggesting, because you can't just convert a little endian processor to big endian using an FPGA.

Sure you can.  In fact, the FPGA would only swap certain instructions where this is required.

The swap is only required because the byte order is backwards (Endian issue).  So, if you fetch a long word from memory using something like mov.l $12345678,d0 that memory location will appear backwards to an x86 and would have to be swapped.  The swap occurs during the opcode emulation, and using some hardware means to perform the swap (like the bus wired backwards momentarily) would eliminate having to do it in software.

The problem with JIT is that it is not cycle exact, so it breaks a LOT of programs.  This is where the FPGA would come in handy as it could be used to throttle the instruction cycle speed so it is correct for a given desired performance level.

[JimDrew]

I hope you mean move.l #$12345678,D0. But look at Psxphill's example. Supposing you do
move.l (A0),D0
move.b (A0),D1

which byte of (A0) ends up in D1? Given that (A0) is now cached.

Since it is A0 itself that is byte swapped, the correct value for the lower byte will be returned.

Let A0 point to an address that contains $12345678. FPGA swaps it to $78563412. Second line then reads $78 instead of $12!

No, because the BYTE value of $78563412 is $12 - just as it would be with a software only op-code interpreter.

Again, I think the FPGA would end up slowing down the process when you had a fast x86.  I am not sure where the break even point would be - that would depend on how fast you could clock the FPGA.

Endian is really not that big of a deal when doing a 68K emulation.  It's just an extra process.

I guess you guys have to decide if you want 100% compatibility or not.  If you do, you absolutely must have a cycle exact emulation.  There are quite a few programs that require it.  You could also deliberately set emulation thresholds.  For example, you could set the speed/emulation type to be Amiga 500 (68000), Amiga 3000 (16MHz or 25MHz 030), Amiga 4000 (25MHz 68040), etc.  This way you could run those euro demos in Amiga 500 mode that won't work on anything else.