Motorola 68060 FPGA replacement module (idea)

[bloodline]

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.  

Hmmm... That's interesting!

[bloodline]

Wow, bloodline's right, you have a crucial piece of the puzzle.
There, of course, would still be a lot of work designing the hardware.
But a super fast '040 sounds ideal.

So which socket do we aim for?
The dip or the square '040/'060 type?

It might be easier to design a processor card, but then we'd be limited to A3000s and A4000.

Indeed!

Though I personally think that what might be more fun is to have the x86 interface directly with an FPGA large enought to take the MiniMig core, and bring out the Amiga compatible I/O (as the MiniMig does)

[bloodline]

How about this for a crazy idea, an accelerator with an Arm CPU and an FPGA, the FPGA can function as a 68k CPU if set up as such, so it could run like the PPC accelerator boards. BUT you install AROS for ARM ROM chips and use the Arm as the main CPU, and allow the FPGA to be reconfigured by the Arm chip, so then you could develop your 68k core "live", and install updates through software.

+1

Probably the most sensible comment in the whole thread

[bloodline]

Perhaps a better idea, is to make an FPGA bridge, like the zorro to PCI bridges... But perhaps more like a 68k to SPI bridge... That way any CPU with an SPI interface could be bolted on to an Amiga (or Amiga chipset clone), and endieness issues could be dealt with in the protocol/bridge?

[bloodline]

SPI is too slow, you need something that can handle about 15MBytes per second for basic use and about 30MBytes for ZIII to work.

Really? Haven't had a look yet (will do some sums tomorrow), but off the top of my head the Amiga chipset wouldn't need anything more than about 2meg per second and an SPI can easily hit 3meg per second... Remember that the alien CPU will have it's own ram local to itself, and the CPU is really just going to treat the Amiga chipset like a graphics/sound card, mostly just hitting registers

[bloodline]

bloodline, I'm seriously not targeting you or anything, just putting my thought process out there for debate hoping you or someone else will see a flaw in my logic.

I read back through it and I was afraid you'd take it the wrong way.

I just haven't had the chance to discuss this CPU stuff with anyone, so I'm enjoying bouncing ideas.

I only suggested SPI because it is super simple and cheap to implement, and I've used it in the past for some pretty fast transfers with ARM micro controllers... Also it was developed by Motorola so it might keep a few purists in the scene happy...

If you have a bigger budget then a more sophisticated bus would be better, many micro controllers have built in USB, so that could be an option too?

-edit- I notice that you suggested USB too, in your post. That's certainly a great idea, though USVB has loads of cool features that one would never need for this project like hot plugging etc... Not sure is the latency of USB would be an issue?

[bloodline]

@ Heiroglyph

I'm concerned that USB (any flavour) will have too high a latency to be used for a CPU/Chipset bus, I'm gonna stick with my original idea of an SPI and see if I can make the numbers add up

[bloodline]

That's cool with me, it would be way simpler if possible.  I've seen the opposite problem with SPI in my thought experiments, low latency but low throughput.

Maybe I'm shooting for to too much memory speed since I'm trying to match the best numbers I've seen.  Lower bandwidth might be acceptable.

Here is my thinking:

The PAL Amiga 500 has a CPU speed of 7.09Mhz, it only accesses the ram/chipset on every other cycle (effectively reducing the frequency to 3.545Mhz). With a bus width of 16bits, that means the highest data rate for the CPU/Chipset bus would be 6.76Meg per second.

A SPI bus with a frequency of 56.7Mhz can match that data rate, and I've used 80Mhz on an SPI bus with an SD card before, so bandwidth (at least for OCS/ECS) should be totally possible with SPI... Latency I guess will depend on how well the protocol is designed, but should be low

[bloodline]

But we've also got AGA machines with faster speeds and 32bit width.  All my numbers were based on the worst case A4000.

I figure if we can use it on a 4000, the others are a piece of cake.

I fear you want to run before you can walk

If the SPI idea is cheap and simple, and if it works then you advance the design

[bloodline]

I think Jim Drew is suggesting that the FPGA only swaps the bus when the CPU makes a request larger than a byte.

[bloodline]

There is quite a bit of work going on understanding the basic architecture of the 68K

http://www.visual6502.org/images/pages/Motorola_68000.html

The micro and nano microcode instructions roms are being read out.
If this works, a table based FPGA will be much smaller and more accurate than the current code - and can be tweaked easier.
A lot of the cloaning complexity of the 68K is a fall out from the way it was efficiently implemented due to die area limitations at the time.
/MikeJ

I've been watching the 68000k and Amiga chips on there for a while... Sadly it's slow progress... But eventually we will have real net lists for these chips!

[bloodline]

Personally I'd be inclined to start with something like a RISC core with 68k-like programming model, and optimise for speed first, then work in a compatibility layer. Starting with 68k compatibility and then trying to work in pipelines etc, seems like the difficult way around.

Obviously the most sensible idea... But apparently not popular with the FPGA hobbyist

When I used to play around with making my own virtual machines, I would often start with an 68k alike programming model then strip it back to the core features, it could then be optimised for speed and was simple to add back necessary features for efficient 68k emulation

[bloodline]

Once upon a time there was a maybe more advanced one than that but ARM had it disposed of. If you look hard enough you might find it in some shady corner of the netiverse, but that was news over 10 years ago...

Here is an implementation of the ARM2 ISA... It's old but would make a great starting point for any CPU project!

http://opencores.org/project,amber

[bloodline]

It's not a time sink if people are working together in parallel which is the way it was suppose to be when I started documenting the new 68k ISA. It's not a time sink if the new ISA attracts interest from outside of the retro crowd. It's not a time sink if the ISA is implemented and found to be a substantial improvement in power, code density, compiler support and ease of programming. You give up very little with the possibility to gain much more. There is a market for retro computing but a bigger market for a processor that can handle today's processing needs quickly with compact code as well as being compatible with old code. That's what ARM and x86 did. They evolved and now they are successful. Building a 68020 compatible CPU comes first, but even then it's smart to plan ahead to make future enhancements easier.



Yes, but they were using predication (unusual for a CPU) that only offers a small advantage in some specific hardware. The smaller the block of predicated instructions and the simpler the instructions the better. Most original ARM ISA instructions could be conditional which worked ok but was dropped with the Thumbs because it was not good for code density which they were going after. The ARM block predication instruction was for multiple instruction predication but ARM went to OoO processors where it didn't work as well. The conditional instructions proposed in the 68kF ISA should work nicely while being a small simplification improvement over a more generic CMOV like x86. They would work well on a Superscaler CPU with a short pipeline and a cheap branch predictor (or no branch predictor) which the 68k is likely to have. There would still be some optimized code that would not want to use them at times. This includes highly predictable branches that are executed often and very tight loops where a highly predictable branch could be used instead. Note that some instructions like ABS (absolute value) have no drawbacks yet remove a branch that can be difficult to predict and SELcc can remove 2 branches in some cases. I would like to do some testing in an implementation before finalizing the ISA.

Sounds interesting, you might want to start a new thread about optimising and evolving the 68k ISA... As any discussion here might get confused with talk about FPGA implementations

[bloodline]

Sorry if I'm dense, are we agreeing?

I thought you implied that no matter what, fragmentation would happen.

My point was that it wouldn't fragment us unless someone added or removed 680x0 instructions.

I guess I am dense.  I can't take yes for an answer

Adding/removing instructions isn't going to fragment, added instructions can be ignored (see the 68020) and removed instructions can be trapped (see the 68060)... Fragmentation would occur if instruction behaviour is altered...

Reusing a previously assigned opcode cold cause problems, unless it wasn't commonly used on the Amiga... If it has potential to improve compiler code generation, or speed execution... then I say go for it!!