Motorola 68060 FPGA replacement module (idea)

[freqmax]

Anything that isn't 68k will most probable require some FPGA glue. That means the minimum configuration is FPGA + EEPROM (core boot image). Adding anyting else adds to the BGA soldering hêll.

I say like @psxphill, there already exist TG68, opencore 68k, and FPGA Arcade 68030 softcore hybrid which is essentially a TG68 modded to 68020 modded to 68030.

I think that a CPU core in FPGA is fast enough to saturate the computer bus in Amiga.

So the least amount of hardware mess and using existing software availability is an FPGA + EEPROM with perhaps SRAM for cache.

KISS..

[freqmax]

Any idea on the signal integrity issues for sufficient fast SPI transfer line?

Those that have any idea regarding BGA, ground plane, cross talk, bus capacitance/inductance, power decoupling, multilayer routing.. raise the hand.

[freqmax]

Zorro-II equals 75 signals that need to be available at a 14 MHz on A1200. To just transfer this one way will require 74*14 MHz = 1.050 GHz. Something that is a completly different ballgame than a 14 MHz parallell bus. It's more on par with S-ATA drive interface.

So more radio frequency magic and related routing issues. Bus inductance and capacitance will be on the edge, no room for "hopefully works" or "oops traces" etc. This will make developers tire of the project and drive the cost!

Parallel m68k socket to parallel FPGA I/O equals piece of cake frequencies.

Again, KISS.

Btw, The Flyer seems to have a neat compression algorithm adaptive Statistical Coding (VTASC) that have noise artifact instead of Jpeg/wavelet blockiness. Anyone figured it out?

[freqmax]

The more specific the chip is, the harder to source it..

[freqmax]

Xilinx is a better option as their ISE has better Linux & BSD support during development than Altera.

USB has a minimum latency of 1 ms which make round trips to be 2 ms. Compare this with a slow A500 bus that has a round trip at 280 ns ie 3570 times faster!
Round trip matters..

As for choice of processor if direct FPGA implementation is not used I think ARM is the better choice as it is more efficient, more suitable to single board solutions unlike x86, can switch endianness etc.

But I still find one FPGA-done the least amount of fuss solution. And the m68k op codes to be way nicer to deal with in contrast to x86 ones.

[freqmax]

By using the PGA-208 68060 socket one can use it on FPGA Arcade and A4000. Models with less demands on bus frequency can then be used via an adapter because the lesser frequency will allow greater signal integrity margins.

[freqmax]

I think an A1200 accelerator is worth doing with just an FPGA, some flash and some ram.
 
Making a 68060 socket compatible version might be useful for a minority, but I'm not convinced it's going to be very useful for the FPGA Arcade. It doesn't need a physical 68060 & it has an FPGA waiting for code.

For the A1200 you would then have to spin another PCB => more fuss.

There's a shortage of >75 MHz 68060 CPUs for the FPGA Arcade. And the FPGA on the base board isn't large enough to implement a 68060 properly.

I think A1200 and A3000 users could benefit from a plain mechanical adapter. And A4000 could benefit directly.

[freqmax]

you absolutely must have a cycle exact emulation.  There are quite a few programs that require it.

Which applications  require that besides A500 specific demos? it has been up before when Minimig were in the pipe. And there were some serious refutations on the issue.

What buses do SoC support? (ARM etc)

[freqmax]

@wawrzon, Any application that has failed for you because of accelerators ?

For buses in general:
 * Latency
 * Capacity (Mbit/s)
 * Electrical compability
 * Protocoll conversion

So I think PCI is doable but don't forget that translation between PCI and Zorro may introduce bottlenecks. But why introduce any bus at all between the CPU-in-FPGA and the CPU-socket? KISS..

[freqmax]

So what bus does the SoC of reasonable price, package and availability use?

[freqmax]

Interrupts can be handled by letting the Amiga side setting an interrupt register in the FPGA which in turn just signal a general interrupt (like "IRQ" on C64) to the overdrive CPU. The CPU side then reads what interrupt source that triggered the event and act accordingly. The extra performance will negate any delays for this code.

On 8086 etc.. an instruction may take 3 cycles but an IRQ may take 100 cycles just to hint on the amount of wasted cycles that may occur. Not counting Push/Pop instructions.

[freqmax]

Choose another CPU

On the FPGA you can make any signal you need..

[freqmax]

If an FPGA is used in the first place as a soft core CPU. There is no reason whatsoever to use microblaze or other architecture CPU. It would just be a huge performance penalty. How can you even get to this conclusion?

[freqmax]

A couple of reasons I'm not jumping at pure FPGA:
Large fast FPGAs get really expensive.
A fast enough core hasn't been done by now, this makes me think it's excessively hard to do.
Very few people are capable of writing something that complex and efficient.  I'm not one of them.
Using an SOC gives a huge amount of devices for free, FPGA just gives a CPU.

I can help with software and smaller projects, so I'm tending to lean that direction.

If I depend on someone else to do the hardest part there's a really good chance it's not going to happen.  If I play to my strengths, I have only myself to blame if it doesn't.

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.

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