Motorola 68060 FPGA replacement module (idea)

[billt]

In another thread the issue that there are too few fast Motorola 68060 CPUs around came up. But that a solution could be to join a male socket and a FPGA on top of that. Much like the 486- or pentium  overdrive solutions for the x86.

The MC68060 datasheet provides the PGA 206 pinout at page 356. And the frequency span is 0 - 75 MHz. Power (p328, p344) requirement is 3.3V +/- 5% @ 2A with 5V compatible I/O. There has not been any QFP variant on the commercial market, ever?

So this is what the FPGA has to be able to work with. Some kind of onboard DC/DC circuit will be needed. The voltages of iVDD, EVDD, PVDD and CVDD is unclear especially in a mixed 040/060 environment. So the question becomes, can a powerfull enough FPGA that implements 060 make do with 6.6 W ? and will the mechanical size be within limits? otherwise circuit board stacking may be needed.

Btw, with some additional PGA-114 (020) and PGA-132 (030) to PGA-206 adapter it could be used as a upgrade option for those CPUs too.

OT Found while searching:
a68k.de - Overclocking Amiga.pdf

As for power required vs. what the socket can be expected to supply, since this will require a pcb roughly shaped like an 060 chip, consider also including a floppy power connector... we'll likely need dc/dc converters for fpga core voltage and other things, why not for 3.3v as well? this could be a hard drive connecter or whatever to get enough power.

one could consider also trying to include 030 PGA pins as well as 040/060 all on the same module and be careful installing, but there is more chance the 030 pins would interfere with 060/040 socket or 040/060 pins interfering with other components on 030 board near the socket. some adapter.

i's use quickswitches or equivalent to get 5v tolerance on the fpga IO, so it would simply plug into an 040 socket and work, as well as simplify adapter to 030 socket to work there. thus the 060 fpga pcb is fpga + quickswitches + power. While quickswitches might affect timing, we're limited to the fastest 680x0 socket here, and that may not be a problem. but something to consider. If it is a problem on 060 like the overclocked Apollo boards, then put quickswitches on 040 and 030 adapters where they don't cause speed problems for super fast real 060 sockets.

also consider ddr3 memory on the pcb, as modern fpgas have a hardwired controller inside for our "whatever" to hook up to. super-fast main memory, or a cache or something. build up a real accelerator for your accelerator. for those that loathe ddr3, cook up something more paletable in there...

This sort of discussion is really fun!

[billt]

Why not just build an adapter with an X86 processor equipped with very fast
JIT interpretation?

that will require an fpga for bus translation at some point anyway, in addition to x86 cpu + whatever else that needs to work (memory + maybe fch/pch, etc) why not just use the fpga?

yes, this means for two very different projects. x86 with software emulation, ala Amithlon. that's a PC motherboard + fpga bridge design, and c programming of the emulator. the 680x0 softcore is a simpler pcb design and then you need to be a microprocessor architecture and computer organization (sometimes called hardware/software interface) guy to design the cpu softcore. so those interested, look up coursera and udacity for such topics, or hit up your local university computer/electrical engineering department! (coursera just finished a very cool looking computer architecture course donated by Princeton)

[billt]

the other thing this sort of thing can give us is a pathway to x86 or arm native.

x86 cpu bridged to the cpu socket gives us a classic amiga with x86 cpu. os4.x works on classic+ppc, this gives us a pathway where we already have drivers for the classic hardware, get ported to x86, then refocus to drivers for x86 peripherals.

put an arm core into fpga, or similar to pc design bridging to an arm chip, to have already supported hardware to get the cpu supported and then move on to arm peripheral drivers. i remember reading about some controversy regarding an open arm-compatible softcore a couple years ago, so i believe suvh a thing does exist.

[billt]

x86 has performance, but it has no charm. Ask yourself which you would rather go for dinner with.

You're right! My OS4 laptop is way more charming than any of my pc laptops or my iBook is. I'm really happy i can go to dinner with that instead of the others...

[billt]

Actually, I would prefer a super fast 040 over an 060 any day.  The reason?  From a programmer's stand point, the 060 requires several work arounds for the superscaler and branch prediction caches.  When I did the code for the Mac emulation, I ended up turning off half of the 060's features because code would blow up due to the Mac OS and many different Mac apps that were not compatible with a full running 060.  You have to deliberately write your code to be 060 compatible, and since the 060 didn't exist when the Mac OS was written (all of the way through OS8.x), the OS didn't support it.  How many 060 boards did you see for the Mac?  None that I am aware of... they went from the 040 to the PPC.

Can you talk about the things that needed turned off for the Mac? Whoever may end up doing the processor design may find that useful to consider while making design choices for his processor, and what might be good things for configuration settings via setpatch or similar utility. what the problems were and any explanations for them could help make something more compatible all around, while also trying to improve performance as well as the fpga environment allows.

[billt]

A practical issue is that due to the through-hole nature of the 68060 PGA socket any PCB will be occupied by solder pads from the pins. A solution is to put double row a straight pin 1.27 mm header around the PCB edges. Such that a another PCB can be mounted on top and the space be used for FPGA, DC-DC and EEPROM.

Sounds like that assumes the PCM is limited to a square footprint matching the 040/060 size. We don't necessarily need to maintain that limit. Figure out a good compromise with various existing CPU boards to avoid other components, and this thing can be bigger. Go off to one side for power and DDR3 slot. Imagine something like the Xcaliber memory board that plugged into an 040 socket and you put the 040 chip back on top, only this time the 040 is inside the FPGA, and you can toss out your old 040. (as an example)

http://amiga.resource.cx/exp/xcalibur

While an FPGA alone may fit inside the PGA matrix of an 040/060, power probably doesn't, nor would level shifters to be 5V safe. Unless perhaps there are surface mount pins that mount on the bottom of this thing only and the top side is wide open for components and routing... Not sure if that is practical though.

[billt]

The experienced users that have this much hardware/software/firmware knowledge generally do not work for free.  So, with an extremely limited market, there is really no desire to work on something where you won't at least recoup your time investment.

But a few are. That's how we got Minimig, TG68, aoOCS, Suska, Zet, OpenGraphics, etc. Check out opencores.org for a variety of things.

[billt]

actually someone is actively working on an a600 fpga accelerator

Indeed, and I've been very excited about that. It's basically what I imagine for this discussion, only with a 68000 plug on the bottom rather than 040/060. It's not exactly shaped like a 68000, it has level shifting to be 5V safe, has power and memory onboard. But very much the same idea. He's working with the TG68, which has had some issues to work out to fit onto a standard 68000 bus. I'd really like to see the Suska 68000 code in there instead, as I think it would more readily fit the standard bus than the TG68. (Though I understand that further work on TG68 core is improving that as well, in addition to enhancing to 020 compatibility)

[billt]

Sadly even a 75MHz 060 is really slow compared to modern Intel processors, so the idea of a dedicated Intel CPU adapter is probably the fastest and least expensive option.

Cheapest? It adds an Intel CPU and whatever minimal supporting chipset is required for that to run to the FPGA and whatever is required to safely connect the FPGA to the 680x0 socket. Maybe you can get a smaller and thus cheaper FPGA for a minimal PC to 680x0 bus bridge compared to putting as high-end a 680x0 softcore as can be put into an FPGA, but I don't think that will offset the price of the PC motherboard. (ie, can an x86 CPU work without a PCH/FCH chip?) Yes, I know there are some ludicrously expensive FPGAs, but I don't expect they'd be chosen for this sort of product. We should be able to fit this sort of thing into something reasonable.

Would the x86 doing nothing more than emulating a 68K be higher performance than the FPGA? That's possible.

Of the big companies I've tried to get NDAs from for various hardware projects, Intel is one of the few that said we were not worth the time to process NDA paperwork. This 68K emulator from a tiny modern PC would probably be equally uninteresting to them. A custom CPU accelerator with an X86 is unlikely with Intel. I want to see if a PCH or FCH chip would connect to a PowerPC PCI-Express slot, like in Sam460... AMD is much easier to get in with, at least for their embedded class stuff, maybe not their high-end.

I suppose you could see if a nano or pico-ITX PC would be small enough and have an appropriate bus to plug into the FPGA bridge. But that means you still have to buy that ?-ITX computer, and I'm not sure if they have a PCI slot/header/something available. It'd be silly to have USB in your CPU socket pathway...

In the FPGA CPU softcore vs x86 emulator debate, my own interest lies on the FPGA softcore side, perhaps partially as I'm just an FPGA fan and am interested in learning how to do that. Doing a bridge between the 680x0 socket and something on a PC motherboard, also inside an FPGA, is probably an easier Verilog/VHDL project compared to a CPU softcore, but doesn't interest me personally as much. So I will tend to favor FPGA softcore regardless of other benefits on the PC motherboard side of the debate, but my preference gets into somewhat subjective preference and interest areas. It just sounds more fun.

[billt]

I thought everything you needed to interface that x86 pain is in the datasheets? anyway perhaps a x86-microcontroller could do the job. But I still see that solution as flawed.
It also adds another dependency on a chip to source. With a generic HDL source you can just neareast enough powerfull FPGA to do the job. And only have one big chip to deal with.

datasheets will talk about pinouts, such as connecting cpu to PCH(north/southbridge), pci-express, pci, etc. it won't talk about how to make a new chip to hook onto the PCH bus. it's been hypothesized that the PCH chips connect via PCI-Express, similar to AMD FCH and southbridges, which is close enough to work on X1000, but isn't trivial either from the rumors I've heard. If it's close enough to PCI-Express, design or buy a controller for that, and work our any oddities yourself. or go pci, which is easier perhaps, but requires a southbridge/PCH/FCH with a pci bus to be involved. the tiniest pc motherboards like pico_itx may or may not have exposed pci or pci-express... I don't know them, and haven't yet gone looking.

[billt]

TobiFlex had the TG68 core running on an A500 about 3 years ago.

http://www.a1k.org/forum/showthread.php?t=20223

Someone called Shadowfire did something similaf as well:
http://eab.abime.net/showthread.php?t=52364&highlight=fpga

And yet we cannot buy a widget of our own.

[billt]

Can the Geode be directly interfaced via level converters to the 68060 socket?
(it seems the only one self contained so far that it won't cause a serious circuit mess)

Geode does not have a 68060 bus in its pinout, so no.

I saw a PCI bus for Geode, do an FPGA PCI to 68060 bridge. If Geode's PCI bus is 5V, then you'll need level shifters between FPGA and Geode as well as perhaps between FPGA and 680x0 socket.

[billt]

I'd rather uses an FPGA for bus translation.
Going trough the PCI bus would be seriously low.

What I mentioned did use the FPGA for bus translation, PCI bus to 680x0 bus. That's what a bridge does. (Sometimes bridges sit between two of the same bus as well, as in PCI to PCI bridge which helps give more slots total than a single bus can provide)

As someone mentioned the Geode LX, have a look at the datasheet
http://wiki.laptop.org/images/a/a1/Lx_databook.pdf

Page 21 has a diagram showing the pin groupings, basically a schematic symbol. If not PCI, what else would you connect to?

I see that the PCI bus in it is 3.3V signalling, so good there.

[billt]

so all you need is decelerator board? lets focus on something else.

Every project has to start somewhere. for someone not having an engineering background, i'm happy to see his thing booting at all, even if it's been done by others before cabling to their fpga boards. i don't understand the slowness, perhaps something odd in his bus logic to the outside of the fpga.  we can all reinvent the wheel and perhaps beat him in speed, but he's the first to get what is intended to be a classic accelerator product (not a minimig inside a 3rd party dev board or just an experiment toward the minimig goal) running that i know of, which was exactly the original topic of this thread before shifting to x86 and software emulation. imagine, if a no-nothing got an fpga to do this, then he'll likely get it doing better than this as well, given time.

if i had the time, i'd be reinventing that wheel with a Xilinx Zync chip. should be good for 68k softcore and includes an easy path to arm without additional hardware. not x86, but gives both sides of this thread something, softcore for the likes of me, and fast cpu running software for Jim and friends. and arm can be big-endian, so might save some conversion to improve emulation speed compared to x86. faster than most Geode as well! in 2012 I studied fpga design and computer architechture for master's degree. (been verilog verification engineer and soc integrator for 6 years, silicon layout monkey before than laying out fpga silicon for 8 years) currently going through videos from a more advanced architecture course. fun stuff! But not my main project when i have time for anything at all.

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