Motorola 68060 FPGA replacement module (idea)

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

[psxphill]

If the FPGA performed the swap instead of doing it in software, I would hope that it would be cached!

I think we're having trouble understanding what you're suggesting, because you can't just convert a little endian processor to big endian using an FPGA.
 
The following code detects whether it's running on big or little endian.
 
int num = 1;
if(*(char *)&num == 1)
{
printf("\nLittle-Endian\n");
}
else
{
printf("Big-Endian\n");
}
 
The code could be running entirely from the processors code cache on a 386 or later, so you can't snoop the bus for op code fetches.
 
The write to the stack will be cached in the processors data cache on a 386 or later, so between the writing of the 4 byte int to reading it back you have no way of reversing the bytes for when it's read back.
 
The difference between big and little endian is not just a case of swapping bytes. When reading a dword as a word for instance you don't swap bytes, you only swap words.
 
I'd be interested in if you could explain how you'd solve the problem without disabling the code & data caches. You could use a processor without caches, the 286 was the latest but you might as well just emulate that if you have an FPGA.

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

[matthey]

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.

+1

[wawrzon]

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?

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

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

[wawrzon]

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

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

[psxphill]

By using the PGA-208 68060 socket one can use it on FPGA Arcade and A4000.

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.
 
An A4000 maybe, although I think a new dedicated accelerator is going to be more useful there. Especially in terms of ram cost and bandwidth.

[Mrs Beanbag]

I think if we've got some fast CPU running 68k emulation or otherwise, it would be a shame not to make its raw power available to the user in some way.

I also had the idea a while back also to approach the problem from the opposite end... make an Amiga graphics card (preferably AGA, for me) for PCs. The PC would then only need to emulate the 68k.

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

[billt]

I also had the idea a while back also to approach the problem from the opposite end... make an Amiga graphics card (preferably AGA, for me) for PCs. The PC would then only need to emulate the 68k.

Inside Out board made with Minimig-AGA, once Yaqube and friends have that finished up.

[bloodline]

@ 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