Motorola 68060 FPGA replacement module (idea)

[matthey]

If you really plan on using strictly a FPGA to emulate the CPU, I would suggest someone modifying WinUAE to make a histogram of instruction usage.  This would let someone focus on optimizing the 680x0 core by looking at instruction usage which could help determine things like what changes in the cache, pipelines, etc. will benefit the speed.

Some instructions are used less often but reduce branching (my favorite), are very powerful and/or save code (some operations are easy in hardware but difficult to do in software). Some DSP or SIMD like instructions are used in processor intensive codecs and drivers where they offer huge speedups but are used less in normal code. A simple instruction count only gives a partial picture of what instructions are best.

[ChaosLord]

Some instructions are used less often but reduce branching (my favorite)

Yes!  I love those!  I (and Phil) were always pushing these at the Natami CPU Dezine Dept. but Gunnar did not like them or didn't understand so he was totally against adding a new instruction for this purpose.

[ChaosLord]

The micro and nano microcode instructions roms are being read out.

If they did this for 68060 it would be very interesting!

[matthey]

Yes!  I love those!  I (and Phil) were always pushing these at the Natami CPU Dezine Dept. but Gunnar did not like them or didn't understand so he was totally against adding a new instruction for this purpose.

Gunnar thought he could solve all short branches with predication but it has issues when variable length and cycle instructions are used. I originally thought instructions like ABS would not be useful for this reason but I came to realize predication was not a good idea even before Gunnar. It doesn't work well with the 68k updated address register addressing modes like (An)+ and -(An) either. The original Scc instruction takes the correct approach. It didn't take too much to convince Gunnar that these kinds of instructions were better than predication or conditional moves like x86 CMOV. That's why we added SBcc, SELcc, ABS, POPCNT, etc. to the ISA and which fit and have minimal pipeline overhead (hazards) while reducing short branches. Long branches still need to jump. If we could remove 5-15% of branches (the short ones) and the overhead in the branch cache and history, the 68k would be one of the best processors at branching. Add to that a relatively short pipeline (and mis-predicted branch penalty) and 0 cycle loops and we would have much improved performance, a beautiful CPU to program and even better code density.

[psxphill]

That's why we added SBcc, SELcc, ABS, POPCNT, etc. to the ISA and which fit and have minimal pipeline overhead (hazards) while reducing short branches. Long branches still need to jump. If we could remove 5-15% of branches (the short ones) and the overhead in the branch cache and history, the 68k would be one of the best processors at branching. Add to that a relatively short pipeline (and mis-predicted branch penalty) and 0 cycle loops and we would have much improved performance, a beautiful CPU to program and even better code density.

Trying to improve the ISA is a time sink which you'll never get payback from. The only benefit is a bit of ego boosting, but that subsides when reality hits.
 
Making the pipeline follow the predicted branch might be hard, but it's doable. Thumb drops a lot of conditional instructions from Arm.

[Plaz]

Different angle here..... Coldfire is not too far off from 68K instructions. A Coldfire V1 core is available for Altera FPGAs. Would it be a shorter easier journey to start with a Coldfire core and modify it to be more 68K compatible for our purpose?

EDIT: Hold on, I may be reading this Coldfire core information incorrectly. More study required.

EDIT 2: Yes, looks like my first comment was correct....  http://chipdesignmag.com/display.php?articleId=2371

Plaz

[Mrs Beanbag]

You might be able to license the core and use it but you won't be able to modify it, commercial cores are typically encrypted so you can't get at the source code.

[billt]

Different angle here..... Coldfire is not too far off from 68K instructions. A Coldfire V1 core is available for Altera FPGAs. Would it be a shorter easier journey to start with a Coldfire core and modify it to be more 68K compatible for our purpose?

EDIT: Hold on, I may be reading this Coldfire core information incorrectly. More study required.

EDIT 2: Yes, looks like my first comment was correct....  http://chipdesignmag.com/display.php?articleId=2371

Check the store for this thing at http://www.ip-extreme.com/corestore/

Yes, it is free without cost, but it is also encrypted. You are not going to take this and go make changes to turn it into something else (even ever so slightly) without spending a lot of money.

Still, it is very cool they have something without cost for those that can use exactly what that is.

[Fats]

The only benefit is a bit of ego boosting, but that subsides when reality hits.

Maybe it's just called hobby...
Staf.

[JimDrew]

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

Well Mike, that will definitely lead you in the direction of a perfect FPGA core emulation.  Table based should be much easier to implement pipelines and the correct size caches.

Motorola was working on a FPGA type chip between the 040 and PPC development with IBM.  Motorola in Phoenix, AZ asked me to visit and I got a chance to work with the microcode blocks for simulating the 68K CPU.  That chip was suppose to be able to become a x86 or 68K (or whatever) by uploading a new core.  It was abandoned because it was simply too slow.  I worked with other microcode projects as well, and I actually called my company Microcode Solutions.

[Plaz]

Check the store for this thing at http://www.ip-extreme.com/corestore/

Um, yeah. That's not going to happen. Darn, thought I had something there.

Plaz

[billt]

Um, yeah. That's not going to happen. Darn, thought I had something there.

It's not a bad thought process to go through. If the source for a well designed core was available, it would be a great idea to be looking at that for ideas and to see if it can be mutated to our ideal here. The problem with that idea is that the really great cores are expensive closed source things, particularly if they have a corporate name on them, and the free/open ones are catching up. Though TG68 is at least getting some real attention and becoming far more than the simple 68000 it started out as.

Some other 68k cores to look at:
ao68000 (github is newer than opencores, is wishbone rather than 68000 bus, but is 32bit)
k68 (opencores)
suska

I'm not really familiar with other architecture cores to consider. There's others out there, but I don't know how well they compare to what Yaqube and TG are doing to TG68 now.
Someone started an opencores project for a simple PowerPC core called zCore that I'd like to look at, but they've never actually uploaded anything. There's an older ARM core somewhere, but as it's an older ARM version I'm not sure how advanced it may be.

[Heiroglyph]

What's the performance like with some of these companies existing general purpose CPU cores on high-end FPGAs?  Each company seems to have one flagship CPU core.

I'd assume that they would be about as fast as could be done.  If you can beat theirs, you need to be working for them!

That should give a reasonable idea of what's even possible.

[Plaz]

@billt
Is this the ARM project you mentioned? Doesn't look like much aditional worl has been done in a while.

http://opencores.com/project,core_arm

Plaz

[billt]

@billt
Is this the ARM project you mentioned? Doesn't look like much aditional worl has been done in a while.

http://opencores.com/project,core_arm

Plaz

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

[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