Motorola 68060 FPGA replacement module (idea)

[freqmax]

More cache, different FPGA like the Actel ones can make it possible. Another approach is to use more pipelined and parallellized processing.

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

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

[freqmax]

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

[freqmax]

The ARM corporation is extremely aggressive when it comes to ARM implementations in any form. Beware! I think they have some sneaky patents on some 10 or so instructions. This is also a reason I prefere MIPS or perhaps OpenSPARC.

[freqmax]

The fundamental problem with this and other sites is that threaded discussion management is missing. Usenet is the ****

[freqmax]

Personally I prefer Verilog. But it lack som capabilities, I think it was in regard to level triggering etc. So VHDL is it.

Btw, those links are books , not hw.

[freqmax]

If not Amiga coding then what?

What makes EAB better?

[freqmax]

im just trying to figure out how to modularize the project in order to divide it in a smaller easier doable parts dedicated to particular talents the contributors may have.

FPGA + 68060 socket.. DONE!

Where's the bus?


As for the embedded market. When people used to m68k continue to use it in work projects it may continue to exist. There's quite a lot of people used to it. It's nice to deal with which is one of the big values. And there's a lot of existing control system software.

[freqmax]

The builtin CPU core in the FPGA Arcade is limited because of logic matrix constraints.

[freqmax]

Instruction fragmentation may occur regardless how it's implemented. Be it ARM-emulation, FPGA or ASIC.

[freqmax]

I'll agree. Make it work FIRST. If it ships it's a bonus

The beauty with FPGA is that you can ship first, and code later

[freqmax]

Adding instructions may cause fragmentation regardless of it's implementation. Reread my post

[freqmax]

Unexpected behaviour will fragment.

So our best option so far for FPGA implementation then is to support Yaqube's efforts? Does he want or need help, are there resources he needs to help things along?

The best situation is that he release the HDL-resources. Other than that one could start with TG68 and work from there.

[freqmax]

It's hard to work with sources that you don't have

[freqmax]

I'm thinking on developing at least one FPGA just to try it out. And you can't have the core until you have a PCB nor can you have a working PCB test until you have a core

So one make a PCB. Then generate a core that just toggle bits and does basic bus testing. When that is complete. The next step is to code a 68k core.

Perhaps it's possible to run the 68k bus really slow like 1 MHz just to prove it works.