Motorola 68060 FPGA replacement module (idea)

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

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

[billt]

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

I don't understand the horror of many pins BGAs. have it assembled. no big deal. or get a rework kit to assemble BGAs. (I am gradually building this up myself) But pro Assemblers are probably better.

Indeed, there are a handful of open/free 68k softcores to start with, so that simply is not a problem. Get them on the 040 or 060 bus is a little  work, but quite doable.

For those without resources to get harcware designed, consider KiCad or UpVerter. UpVerter sounds good for this sort of thing, but may need to advance a bit more first. Online tools, cloud data, free for open-source projects... KiCad is GPL (and one of the reasons I want WxWidgets for OS4)... Upverter sounds like it's becoming a good platform for collaborative/group design.

I'd put a microSD slot for the FPGA bitstream, so it's relatively easy to update even if something goes bad, rather than a soldered-on eeprom/flash. Maybe a simple microcontroller to get some config manager like FPGA-arcade to choose 68k softcore or Aros Arm-native or etc. I like the idea of using the internal Arm for that, but not sure how easy that is to do. (I've not done reconfigurable work before, and am not sure what mikej's approach is, or what other minimig boards do or not.

I'd use a Zync or Cyclone/Arria5 soc FPGA with Arm inside. Then Aros peeps can play with Arm, 68k peeps can play with softcore and maybe figure out something interesting for Arm to do, and software emu peeps have a fast cpu to interpret or jit 68k on. And I think that these Arm things inside would do better than adding a Geode or other X86/64 Pc to it all. Also consider than the Arms connect to the FPGA fabric, as I understand, via the Arm AXI system bus, so there is a better pathway to 68k socket than through PCI or PCI-express from a PC chipset.

[billt]

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.

GPIO would be terrible. I've done Arm APB bus over GPIO (as a software C implementation) and it was horribly slow. funtional yes. some things would have been weird such as interrupt latency. But this was for a testbench experiment (inside verilog simulator of a full soc chip) and ended up not used in favor of something else. Doing 68k bus as GPIO would not be any better, and probably worse as APB is not very complicated.

The Arm AXI bus inside the SoC FPGA chips is your local bus.

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

[freqmax]

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

[Plaz]

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.

As much as anything else we're hardware geeks, not just more GUI users. What's under the hood is as interesting or more so than what icon is being clicked. For flat out speed, apps, and support wintel is a great way to go. But if that's all everyone ever wanted there'd be no reason to hang around an Amiga site. If this were a "for profit" project, market research would say some wintel based solution would be the best option. But wait... we already have a wintel option. In reality this project will probably mostly be done for free and loose money. So devs might as well pick what's the most fun then.

Why did Amiga devs back in the day go PPC? Well two basic reasons I see....#1- it was Motorola and #2- it wasn't Intel. With current options, who knows what they might have chosen. Well I guess that's what we're working out now.

Plaz

[Plaz]

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

Cheaper if using individual chips? I'm poking around the internet and seeing some FPGA/ARM dev combo boards for around $150-200. FPGA on those probably to small for the 68K core though.

Plaz

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

[JimDrew]

But then it goes in the cache, and there are any number of things that can go wrong. Such as if you read an address as a longword for some reason, and then go on to process it as part of a string, it will have been byte swapped into the cache. Either you turn the cache off and destroy any advantage of using such a fast CPU, or you have serious difficulties ensuring coherence.

Huh?  You have to remember there are already 68K emulators for the x86 that do the byte swapping.  I believe I have the fastest non-JIT type ever made.  There are no issues with caches, and there would not be any under any circumstances.  ALL data with a x86 is backwards from the 68K (little Endian vs. Big Endian), so everything dealing with words or longs is swapped and remains that way.  If the FPGA performed the swap instead of doing it in software, I would hope that it would be cached!

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

[bloodline]

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.

I only suggested SPI because it is super simple and cheap to implement, and I've used it in the past for some pretty fast transfers with ARM micro controllers... Also it was developed by Motorola so it might keep a few purists in the scene happy...

If you have a bigger budget then a more sophisticated bus would be better, many micro controllers have built in USB, so that could be an option too?

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

[ElPolloDiabl]

We already have WinUAE that can perform like a 2Ghz Amiga. So...
I would want to see something better than that (more features etc.)
Not to fussy about the price, but keep it under $1000 or I would never buy it.

For running modern software I think dual core 1Ghz cpu is the minimum.

You might want to find out what type of software people want to run on it. What kind of spec do you need to play HD movies? I might like internet radio, not so much HD movies.

It's very interesting, if you finish your final spec soon, I will actually believe you can do it.

[wawrzon]

as for the purists, ive seen a notion that even hardcore os4 fans are now for immediate x86 switch when doable. dunno why the original amiga fans should bother more. those who dont care about speed can keep their 68ks..