Motorola 68060 FPGA replacement module (idea)

[wawrzon]

it was me who proposed x86 accel i admit, in order to simplify the design using widely awailable prefabricated components. if you look at jens schoenfeld x-surf, apparently one of the best zorro network cards, its an pc low profile isa card assembled with a simple zoro adapter board and a little logic. jens must have done the simplest and most reasonable thing there was.

also i did not propose to run native code on that accelerator, whatever cpu it would carry, except for 68k emu. everything else would run 68k native without any modifications. at least at the beginning. the rest could stay open. but lets leave this topic to better informed.

[psxphill]

What we DON'T have is a FPGA accelerator, because we don't have a 68k core. One reason why not is it means developing both hardware and software at once, while either on their own is a task in itself, so we get stuck at an impasse. No core? FPGA accelerator=useless. No FPGA accelerator? Core=useless.

There are already open source 68k cores, the bus interface is going to be specific to the hardware you build. The problem is that nobody wants to make accelerator fpga hardware. The a600 has a prototype one, which is looking promising.
 
If someone did an a1200 one and it could run 68k code at the equivalent of 100mhz then loads of people would buy it.

[Plaz]

In following the thread, Beanbag's suggestion of a FPGA/ARM combo is intriguing. Reminds me in a way of an Emplant board. I'd picture a proto/dev only board with 040/ARM/FPGA combo for developement of the FPGA. *IF* successful, then a production ARM/FPGA(040) for all kinds of interesting things. Not opposed to x86, but feel that's kind of covered already with AROS and UAE. Not speaking for anyone else, but I wouldn't go to much expense to put an x86 in my classic. BTW, I'm a master at soldering.  Perhaps time to brush off the old asm skills and get an ARM manaul?

Plaz

[wawrzon]

but I wouldn't go to much expense to put an x86 in my classic

even if it would make your amiga fastest original amiga ever, faster than x1k and a g5mac?

[Plaz]

@wawrzon

I'd prefer something more unique for my Amiga even if it wasn't bleeding edge on speed. For years I preferred and enjoyed my 50mhz Ami while other 300mhz, then 400, 500, 667, 733, 800, 933 and 1200mhz systems were made available. Imagine a classic at hundreds of mhz with ARM support.... cool.

Also such work could benefit future advances in things like minimig, fpgarcade and ... ??  And again, I'm not against x86, it's just less interesting for me. I also agree with earlier post that an x86 will probably need more supporting hardware on board than a FPGA.  Isn't "tying" an x86 to an Amiga buss going to require it?

Plaz

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

[Mrs Beanbag]

Anything that isn't 68k will most probable require some FPGA glue.

Even a 68k needs an asynchronous bus interface to run at anything other than the motherboard clock speed. ACA1230 etc use an FPGA for this, as well as for the memory controller (I believe).

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

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

[Heiroglyph]

SPI is too slow, you need something that can handle about 15MBytes per second for basic use and about 30MBytes for ZIII to work.  You can't cut it too close, you need some headroom to make up for any small delays that might occur.

Latency is another issue. If the latencies are too high, no sustained transfer rate is going to help you.  You'll stall the bus and at best have retries and wait states slowing you down.

I've done a TON of research on this same idea in the last few years (and still am, but not as heavily).  One of the reasons I keep putting it off is the fear of rejection by users.  It's not a "real" Amiga, it's just an emulator, etc.  You have to admit, we're an easily offended and fickle group.

The other is getting a fast link between the CPU and the Amiga bus.  Most SOC's have limited IO capability.  GPIO isn't fast enough on any I've seen and local buses are long gone.  PCI-e is on some of them, but that's not a cheap interface.

The other big stumbling block is ZorroIII.  IMHO, forget Z3, it's not worth it for the 4-5 available cards that are easily replaced with faster components on an SOC.  Z3 never worked right anyway, you get at most one busmaster out of the 4 available.

Edit: let me clarify on the Z3 issue.  If you don't allow Z3, you only need to communicate with the system on the lower 16MB, using 24 bit addresses.  This would apply to any Amiga model.  Everything above that could be local to the SOC.

[wawrzon]

i wouldnt mind people not taking solutions as amiga enough. ppc isnt amiga as well. people will complain and then shut up and want have when they see the results. all that runs available and potentially possible 68k codebase but faster is fine whatever the tech behind it.

[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

[Heiroglyph]

Chipram access can hit over twice that, then there are ZorroII devices.  Rom access can be a little over 9MB, although I'd assume you'd want to put that into fast ram anyway.

I'm thinking AGA Amigas, for ECS you might get away with it since they have a slower, narrower bus.

I haven't seen a reasonably available SPI that was fast enough.  There are faster more exotic ones, but your SOC has to support it too or you're back to bolting that onto your SOC.

[ChaosLord]

Chipram = a good solid 14.? MB/sec unless I am misremembering something.

[Heiroglyph]

I don't think chip can get quite hit 7MBps, although I could be wrong.  It's not easy to get reliable real world info.  Some of the benchmarks seen online are just obviously incorrect.

Fast ram on the motherboard and ZII would still need to be taken into account.  I'm not sure I'd want to give up some of my ZII devices that are unique to Amiga, like the Flyer, etc.

It's possible that I've missed something on SPI though, it might be doable.  I'd love to be proven wrong, SPI is on pretty much every SOC.

And getting a theoretical maximum that just barely cuts it isn't going to really work.  Nothing ever hits theoretical max.

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