Motorola 68060 FPGA replacement module (idea)

[Heiroglyph]

A large enough FPGA like XC3S1600 as used in FPGA Arcade cost 68 USD at D-key. Currently it can be seen in the FPGA Arcade thread it can beat 68030 @ 20 MHz Amigas using a 16-byte cache (4.46 times A1200). With hope of 28 MHz.
Thread: http://www.amiga.org/forums/printthread.php?t=39806&pp=15&page=57
Sysinfo: http://www.yaqube.neostrada.pl/images/SysInfo28-16.gif

So XC3S1600 is more than enough and it has already been done.

The FPGA gives you any device you can imagine that can be expressed as binary gates.

I know VHDL is a bitch but so was assembler, C etc too. It's hard but the reward makes it worthwhile. The power is awesome.

I'm not really excited about 4x A1200 speeds. It's still not faster than an off the shelf 680x0 that just needs glue.

I feel that if it's not 10+ times the speed of an 060@50 then it's not a success.  If you can get 20x 060/50 performance then it's time to pat yourself on the back.  UAE can do it while also emulating the whole chipset, so it is possible with the right  CPU.

That type of speed just doesn't seem doable in a reasonably priced FPGA.

Edit: Also, like I said, *I* can't reasonably do it in an FPGA.  I can do a localbus interface and I can do software.  I'm just tired of waiting for "it's not that hard" to happen and following my gut on the quickest path to get there.

[freqmax]

Here is another sysinfo screenshot:


The following paths has not been explored:
 * Replacing Xilinx FPGA with Actel (may give 5x right of)
 * Explore larger than 16-byte cache
 * Use larger pipelines
 * More parallelization

The performance target is 68060 @ 75 MHz or better.

If the piggyback option is to be used. Is there any SoC that has a bus that can manage Amiga without FPGA glue? (less mess)
The other option would be something like a CPU+RAM+EEPROM+FPGA on a board.
Any data on this?

[psxphill]

Here is another sysinfo screenshot:

sysinfo is horrendously innacurate, but it's showing that it's about half the speed of a 25mhz 68040 on the dhrystones test. So it needs to be at least 4 times faster.
 
longer pipelines might do it, getting from here to there is a huge jump though.

[billt]

A large enough FPGA like XC3S1600 as used in FPGA Arcade cost 68 USD at D-key. Currently it can be seen in the FPGA Arcade thread it can beat 68030 @ 20 MHz Amigas using a 16-byte cache (4.46 times A1200). With hope of 28 MHz.

And Spartan3 is old stuff now. Since then they did Spartan6 and now the 7-series stuff, which should e both easier on performance as well as easier on power. I'm not familiar with Altera parts in terms of speed or capacity etc. I have a DE1 buried in storage somewhere for Minimig, hope to get to use it at some point... I also really want to get a Zed board to play with someday. But I of course need a 56 hour day too.

[billt]

Using an SOC gives a huge amount of devices for free, FPGA just gives a CPU.

Two thoughts in response to this:

1: Look at all them peripherals on opencores. Stick some of them in that same boring FPGA.... OK, now you may need a bigger FPGA, but something to consider. Understand that an FPGA can give you anything you can fit in there and meet timing with...

2: For the ARM SoC FPGAs, can the FPGA area only be a slave, or can it be an AXI master, and use all them ARM peripherals as if they belonged to our 68k softcore? I don't know the answer to that, but it would be interesting to find out.

[freqmax]

The possibilities hasn't been explored yet. Getting 68000, 68020, OCS, ECS, AGA, Paula, etc to happen in HDL since 2006 is a huge task. That also means not a lot of time has really been spent on the CPU specifically. The "68020" is essentially a TG68 quickfix because there were some worries that AGA required 32-bit CPU and datapath to even work at all.

The 68060 uses lot's of bit juggling, time for the FPGA version to do so to. I guess the only real rule is to make sure the op-codes are acted on as fast as possible.

[billt]

Finding one that has that plus external interrupts with levels is tricky.

It's also not standardized across chips so you're back to vendor lock-in.

Well, we're not going to find a better 060 already made for us, and we're not going to find an ARM with an 060 bus on it either.

I don't think anyone will find the perfect chip in a standard package from lots of vendors that are all pin compatible for this. You may have to suck it up and live with vendor lock-in of something. That includes straight FPGAs, as changing from one FPGA to another is not a trivial thing. I don't believe Altera has anything to go on a Xilinx board or vice-versa...

[billt]

Edit: Also, like I said, *I* can't reasonably do it in an FPGA.  I can do a localbus interface and I can do software.  I'm just tired of waiting for "it's not that hard" to happen and following my gut on the quickest path to get there.

I think doing the PCB of an FPGA (or SoC FOGA) only design would be pretty straight forward. I do not expect the softcore to be trivial. Luckily TG and Yaqube have already been doing wonderful things. This part needs a processor designer, and Motorola surely had quite a team. As do Arm, Intel, AMD etc. Not just a simple student engineer like me, but we do have some good people doing this sort of thing, and at some point it'll open up and more of us can see and play, and if time allows try some more ideas in there. I was surprised at how simple a RISC control unit can be this past fall semester, I really wish our project had been in something useful like VHDL or Verilog instead of the crummy schematic tool LogicWorks...

Look at the instruction set, and start breaking each down into easy steps. (hardwired logic or microcode, I don't have a good handle on microcode way yet) Look for common pieces, such as the first part of every instruction is the fetch part. Then decode. If you know VHDL and are good with digital logic, you should be able to figure it out. I had my aha moment and it's making a lot more sense now, so anybody can...

It starts with a counter, up to the maximum number of steps for your instruction analysis. The longest instruction (most steps) determines the maximum this counter increments up to. Shorter instrictions can clear the counter earlier back to 0 (fetch step). Along side that you have your instruction opcode, which is used to address/select registers, select which ALU operation gets to the ALU output, etc.

Then things get more complicated as you bring in pipelines, bypassing (shortcut result of one instruction back to ALU input for use before it actually gets written to its destination register), mux NOPs into pipeline stages if they need to stall/bubble  for a cycle, start doing superscalar (multiple parallel ALUs), caching, branch prediction, etc. And goes on from there.

The fundamental thing isn't hard. Competing with an 060 most likely is hard, but is possible. Will take a while though.

[JimDrew]

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.

[mikej]

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

[freqmax]

Isn't 68000 architectually too far from the 68060 in order to gain useful insight into the original 68060 ..?

[psxphill]

Isn't 68000 architectually too far from the 68060 in order to gain useful insight into the original 68060 ..?

Probably. However the current cpu emulation is even further away from any architecture that Motorola ever used.
 
I see it more as a way of going on the same journey that Motorola did.

[Mrs Beanbag]

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.

[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

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