Motorola 68060 FPGA replacement module (idea)

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

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

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

[Heiroglyph]

Yeah, the Flyer source is open

Ok, so SPI...

Typical SOC, Freescale iMX53.  SPI rates 16-60Mbps, or at most 7MBps.  That's theoretical mind you.  You also have a lot of CPU overhead, probably up to around 50% on long transfers (disk IO, etc).

The other thing is that isn't taken into account is overhead of addressing and error checking. The datarate is in raw bits, that doesn't take that into account telling the other side where to put the data or what the data size is.

For long transfers it's not so high a percentage, but for sending a single byte you've got 24bits+ of address, 8 bits of data and some unknown for data size.  I'd say roll the data size (like SIZ0-1 on the CPU) into the unused address bits and have a minimum transfer of 40bits for 8bits of data.

Worst case you've got 40bits to each byte, 5:1 and no error checking.  If that's a common operation, you'd need five times your amiga bus bandwidth to seem normal.

[Heiroglyph]

bloodline, I'm seriously not targeting you or anything, just putting my thought process out there for debate hoping you or someone else will see a flaw in my logic.

I read back through it and I was afraid you'd take it the wrong way.

I just haven't had the chance to discuss this CPU stuff with anyone, so I'm enjoying bouncing ideas.

[Heiroglyph]

My issue with the FPGA/ARM combo chips is the price.

I've been trying to find a good way to interface the wave of super cheap ARM's that are 800-1200Mhz and loaded with peripherals.

It might take a combo chip, but then we're back to $1000 CPU cards.

[Heiroglyph]

Whatever I used, I'd want to keep it CPU agnostic.  No more of this "oops, they don't make those anymore" or "these are WAY cheaper, too bad we can't use them".

I'd like to keep 68020 as the instruction set to avoid fragmentation.  I know some people would be upset that it's not PPC, but honestly there are a LOT of us who never touched a PPC and there are existing GHz+ PPC solutions.

It would be sort of like Java bytecode, the CPU cards just have to know how to execute it, whether its an Intel, Arm, PPC or whatever.

All our existing software would just work and new software could still run on 68030's and 68060's assuming they could handle the workload.

There would be some overhead but when you're jumping from 50MHz to 1.5Ghz and higher, would you even notice?

UAE is incredible, but it's also emulating the whole chipset.  Imagine how fast it could run without that overhead by letting the actual chipset do its thing.

[Heiroglyph]

Most modern CPU's can byte swap so fast we'd barely notice anyway.  I believe some Arms can deal with bi-endian data (bi, not big).  I don't really think emulation speed is an issue.

AFAIK, we do still need a JIT for ARM, but initially it could be tested with existing CPU emulations.

No offense to Jim and his amazing emulators, but I've always found the Executor CPU emulation to be very interesting.  It's tough to follow since it creates itself, but it could be extended to other CPUs and updated for better optimization with newer x86 CPUs.

There is no shortage of emulations to pick from and I'm sure there are emulator authors that would love to pitch in on the Arm JIT since it's pretty much the #1 platform now.

[Heiroglyph]

How about this for a low chip count start...

5v tolerant CPLD like Altera MAX 3000A or Lattice ispMACH 4000ZE.

The CPLD would take care of being a basic 68030 style busmaster at bus speed (14MHz on 1200, 25MHz on 3/4000).  It's almost an arbiter.  This is basically like building a Zorro card, not rocket science.

Then use an AVR32 with USB2.0 like a AT32UC3A3.  This is not the CPU, this is the USB interface to the real CPU.  It takes care of as much of the CPU duties as it can, but does not run applications.  It's mainly there to make the Amiga into a smart USB2.0 device.

The AVR would also forward any interrupts needed to the host, the real CPU running our CPU emulation.

Now hook up a PC and work out the communication protocol with easy to use tools.  No embedded device needed.

Anything below 16MB gets routed to the USB device.  Above 16MB is local to the CPU emulation.  You could use hooks similar to the way UAE does to add in RTG and other devices.

So far you've got a very small investment in parts (connectors, PCB, chips, etc) but you can use any CPU you want that has USB 2.0.

Doing it cheap?  Use a rasbperry pi.
Doing it no holds barred?  Leave an i7 PC plugged into the side.

Any combination in the middle could work.  Bigger Arm single board computers like Pandaboards, PC/104 or comExpress boards, custom internal boards powered from your Zorro slot, anything you can run your software on.  Hell, plug it into a video slot instead then use the camera input on many Arm chips to overlay the Amiga video signal onto its own video signal.  Instant flicker fixer and monitor switch.

You've got a small investment in hardware and software, then the hardware can move with you to bigger CPU's and newer software.

[Heiroglyph]

-edit- I notice that you suggested USB too, in your post. That's certainly a great idea, though USVB has loads of cool features that one would never need for this project like hot plugging etc... Not sure is the latency of USB would be an issue?

I'm not sure on the latency, but 2.0 is lower than 1.0 and available anywhere.  It certainly has enough bandwidth and isn't going away any time soon.

Regardless of what was used, I like the idea of a community standard for modularity.  Once the hardware is worked out for one model it could easily be adapted to another system by the same or other developers most interested in that system.  The 68000 models still need VPA/VPB etc to access 6800 devices, but other than that it's mostly just bus speed, width and a new connector.  Far cheaper than starting from scratch.

There's no point in starting from scratch for each model, otherwise it would never get done for some of them.  Once an Amiga had the adapter, you wouldn't have to scour the world looking for those crazy connectors that Commodore used to make a new CPU upgrade either.
 
We could have reusable CPU modules that users could upgrade easily or carry to their next Amiga or FPGA clone by buying a new adapter.

The other side is that clones could be easier to build and diagnose when you can leave much of the functionality on the CPU card, emulated but usable and replace individual functions with hardware as the project progresses.

A powerful CPU card alone with a power supply and case could even be a Mini-mig type system.

There are sales opportunities all over the idea of a modular CPU card, even if open to being a community project.

There is no point in duplicating someone else's hardware design, the market can't support that competition it so there is still a naturally protected market for someone willing to put in the effort and it significantly lowers the investment.

The benefit to the users is more accessible, cheaper upgrades, better long term investment in CPU hardware and documentation so that when they break in 10 years they can be fixed even though the designer is long gone from the scene.

[Heiroglyph]

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.

Good info on USB.  Someone will come up with a workable solution I'm sure.

As for op codes, I wouldn't expose the native CPU, I think that defeats the purpose.  The only one who would see the native opcodes is the person writing the embedded software for the CPU card.  It's just like an FPGA, the users don't write code in VHDL (bad analogy, but it's all I've got).  End users would just see a super fast 68020/30.

If we expose the native CPU opcodes, we break the market into at least two more fragments making software compatibility a problem.  Even exposing them like Amithlon did is too much IMHO.  Amiga Classic = 68k is much easier on everyone.

Any special functions could be exposed through standardized libraries, for example a video encoding/decoding library that uses the hardware directly.  

Think of it like Amiga drivers.  The user knows he's using WarpSCSI.device but doesn't know or care that it uses a different chip than GVPScsi.device.  Default standard libraries could be written in 68k and used if specialized ones aren't available.

[Heiroglyph]

then i would divide the approach in two parallel, as there are either suppoers for an asic cpu with fpga glue or pure fpga anyway. fpga may give us simpler purer solution, while arm or x86 will provide raw power. ok?

I would propose that we do it in the open and work together.

Getting the bus signals right is not super easy and there's no reason other than greed not to share this between projects regardless of what CPU is on the other end.

I'd like to break the cycle of closed NDA hardware, the community isn't big enough to support that anymore.

I'd even go so far as to propose a license for the shared hardware info.  The attachment between the Amiga and between cards must be open freely and changes fed back to the community.  You can keep your back end firmware/embedded software closed until you stop selling and supporting the hardware, then you must make your design open.  If you use a UAE based JIT, obviously that would still have to follow the GPL guidelines.

That covers commercial development but makes sure that the community gets enough info to interoperate and progress while eventually being able to support/repair your hardware in the future.

[Heiroglyph]

@Heiroglyph
+1 on all points
+ i think the approach to look from the 68k emulation perspective treating the amiga as expansion card providing interface to the original chipset and the original interfaces, is exactly right, since this is what it in fact is, even if you use your usual 68k accelerator today.
whats important is to provide yet some expansion possibility best not bound to amiga itself as for instance pci. who has fast cpu wants fast rtg as well.

Thanks for the +

I totally agree and I've glossed over that.

We've got the source to OpenPCI (at least I've got permission to distribute it and relicense under an open license).

So we could either ship with an OpenPCI library that is compatible with our hardware or just have PCI and other devices show up directly by using existing linux, bsd, etc. drivers on the back end.

It might make sense to have onboard components show up as devices and PCI either show up through OpenPCI or have some special fiesystem folder where native drivers/devices could be added.  That's one of the few places I'd be OK with seeing native code.

Amigans are notoriously bad at writing drivers, taking advantage of native drivers just makes sense.  Otherwise we'll never see them.

[Heiroglyph]

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

Wait, what do you mean by round trip?

The 500 has a 7MHz bus plus signaling overhead, times can't be that low for anything outside the CPU.

Internal to the CPU would be equivalent to inside the JIT.

The only time you'd hit a latency issue is on the initial read or write to the Amiga itself, not on long transfers, also on interrupts and probably not with any bus contention (chip ram access, etc.).  The data might already have been transferred to the Amiga side of the USB and waiting for the bus.

I'm still not 100% sure this wouldn't work, but like many accelerators it might some percentage of the time have wait states only when accessing the Amiga, not when accessing local devices or ram.

[Heiroglyph]

@ Heiroglyph

I'm concerned that USB (any flavour) will have too high a latency to be used for a CPU/Chipset bus, I'm gonna stick with my original idea of an SPI and see if I can make the numbers add up

That's cool with me, it would be way simpler if possible.  I've seen the opposite problem with SPI in my thought experiments, low latency but low throughput.

Maybe I'm shooting for to too much memory speed since I'm trying to match the best numbers I've seen.  Lower bandwidth might be acceptable.

The other option I've looked into a lot is being a PCI device.  It cuts out the ability to use really cheap SOCs, but many of the nicer ones (especially Freescale and TI) have PCI or PCI-e.  I don't think either latency or bandwidth would be a problem, even for ZIII, but the hardware cost would go up.