Motorola 68060 FPGA replacement module (idea)

[freqmax]

Interrupts can be handled by letting the Amiga side setting an interrupt register in the FPGA which in turn just signal a general interrupt (like "IRQ" on C64) to the overdrive CPU. The CPU side then reads what interrupt source that triggered the event and act accordingly. The extra performance will negate any delays for this code.

On 8086 etc.. an instruction may take 3 cycles but an IRQ may take 100 cycles just to hint on the amount of wasted cycles that may occur. Not counting Push/Pop instructions.

[Heiroglyph]

Interrupts can be handled by letting the Amiga side setting an interrupt register in the FPGA which in turn just signal a general interrupt (like "IRQ" on C64) to the overdrive CPU. The CPU side then reads what interrupt source that triggered the event and act accordingly. The extra performance will negate any delays for this code.

On 8086 etc.. an instruction may take 3 cycles but an IRQ may take 100 cycles just to hint on the amount of wasted cycles that may occur. Not counting Push/Pop instructions.

But if the CPU has no external interrupts, you have to poll for a signal on a GPIO constantly, which can get costly.  Am I missing something?

[freqmax]

Choose another CPU

On the FPGA you can make any signal you need..

[Heiroglyph]

Choose another CPU

On the FPGA you can make any signal you need..

lol, I know, right?

So many CPU's are being thrown out because of IO problems though.  I'd like to maximize the options rather than being stuck with the single CPU that would ever work.

[Mrs Beanbag]

MicroBlaze softcore achieves 1.38 DMips/MHz:
http://www.xilinx.com/tools/microblaze.htm

With 500MHz FPGA, if such core could be matched by a 68k soft core, this would probably beat software emulation on 1GHz Arm.

[freqmax]

If an FPGA is used in the first place as a soft core CPU. There is no reason whatsoever to use microblaze or other architecture CPU. It would just be a huge performance penalty. How can you even get to this conclusion?

[Mrs Beanbag]

I'm not suggesting to use MicroBlaze soft core, I'm citing it as example of performance that can be achieved by a soft core.

[billt]

Interrupts can be handled by letting the Amiga side setting an interrupt register in the FPGA which in turn just signal a general interrupt (like "IRQ" on C64) to the overdrive CPU. The CPU side then reads what interrupt source that triggered the event and act accordingly. The extra performance will negate any delays for this code.

On 8086 etc.. an instruction may take 3 cycles but an IRQ may take 100 cycles just to hint on the amount of wasted cycles that may occur. Not counting Push/Pop instructions.

This could work. Capture the 68k interrupt pins while triggering an interrupt to the upstream host, host checks what interrupt value was captured, and does whatever it needs to in interpreting the 68k binaries, jumping to the 68k irq handler routine to be interpreted, etc. Took a couple minutes for that to soak in, but I'm on board with it now.

[Heiroglyph]

I'm not suggesting to use MicroBlaze soft core, I'm citing it as example of performance that can be achieved by a soft core.

That is a good point.

A couple of reasons I'm not jumping at pure FPGA:
Large fast FPGAs get really expensive.
A fast enough core hasn't been done by now, this makes me think it's excessively hard to do.
Very few people are capable of writing something that complex and efficient.  I'm not one of them.
Using an SOC gives a huge amount of devices for free, FPGA just gives a CPU.

I can help with software and smaller projects, so I'm tending to lean that direction.

If I depend on someone else to do the hardest part there's a really good chance it's not going to happen.  If I play to my strengths, I have only myself to blame if it doesn't.

[Mrs Beanbag]

I have a friend of a friend who was talking about creating a 68k  softcore for his own project, I should see if I can get involved. I'd  really like to get into this sort of thing.

CPU cores can take  less space of an FPGA than you'd think, from what I can tell. Speed is  more of a problem than space. Then again 68k is a bit more complex than  MIPS et al.

[psxphill]

No, because the BYTE value of $78563412 is $12 - just as it would be with a software only op-code interpreter.

If you're writing to cachable area then write caching means it might not even make it onto the bus before the value gets read back, even if it does make it into ram then the cpu has already cached the value that it wrote so it won't bother to read it again. There is no way you could write a little endian 68000 emulator running on a modern processor and then use an fpga to convert it to big endian.
 
You could convert a 286 processor to big endian, or a 68000 to little endian because it has no caches and reads/writes go straight to the bus. Or you could turn the caches off.
 
I don't believe you've thought it through at all.
 

That's what I was thinking also. Anything that would break is already broken with existing accelerators.

Or even running on an A3000/A4000/A1200. Most A500/A2000 accelerators had a fall back to the built in 68000, so you could argue that this would be nice for anything for those. But an A3000/A4000/A1200 doesn't even have the chance of running software that required an A500 timing.
 
WHDLOAD already has patches for a lot of those. Or you can find patched versions of some demos.
 
There might be new bugs introduced by running a 68000 at 200mhz that never showed up before, but I'm not sure how much I care about that. If it's an important enough piece of software then someone will write a patch for it.

[freqmax]

A couple of reasons I'm not jumping at pure FPGA:
Large fast FPGAs get really expensive.
A fast enough core hasn't been done by now, this makes me think it's excessively hard to do.
Very few people are capable of writing something that complex and efficient.  I'm not one of them.
Using an SOC gives a huge amount of devices for free, FPGA just gives a CPU.

I can help with software and smaller projects, so I'm tending to lean that direction.

If I depend on someone else to do the hardest part there's a really good chance it's not going to happen.  If I play to my strengths, I have only myself to blame if it doesn't.

A large enough FPGA like XC3S1600 as used in FPGA Arcade cost 68 USD at D-key. Currently it can be seen in the FPGA Arcade thread it can beat 68030 @ 20 MHz Amigas using a 16-byte cache (4.46 times A1200). With hope of 28 MHz.
Thread: http://www.amiga.org/forums/printthread.php?t=39806&pp=15&page=57
Sysinfo: http://www.yaqube.neostrada.pl/images/SysInfo28-16.gif

So XC3S1600 is more than enough and it has already been done.

The FPGA gives you any device you can imagine that can be expressed as binary gates.

I know VHDL is a bitch but so was assembler, C etc too. It's hard but the reward makes it worthwhile. The power is awesome.

[psxphill]

A large enough FPGA like XC3S1600 as used in FPGA Arcade cost 68 USD at D-key. Currently it can be seen in the FPGA Arcade thread it can beat 68030 @ 20 MHz Amigas using a 16-byte cache (4.46 times A1200). With hope of 28 MHz.
Thread: http://www.amiga.org/forums/printthread.php?t=39806&pp=15&page=57
Sysinfo: http://www.yaqube.neostrada.pl/images/SysInfo28-16.gif
 
So XC3S1600 is more than enough and it has already been done.

Except you want it to replace the 68060 that can be clocked greater than 75mhz, which is a bit of a stretch from 28mhz.

[freqmax]

More cache, different FPGA like the Actel ones can make it possible. Another approach is to use more pipelined and parallellized processing.

[wawrzon]

A large enough FPGA like XC3S1600 as used in FPGA Arcade cost 68 USD at D-key. Currently it can be seen in the FPGA Arcade thread it can beat 68030 @ 20 MHz Amigas using a 16-byte cache (4.46 times A1200). With hope of 28 MHz.
Thread: http://www.amiga.org/forums/printthread.php?t=39806&pp=15&page=57
Sysinfo: http://www.yaqube.neostrada.pl/images/SysInfo28-16.gif

So XC3S1600 is more than enough and it has already been done.

The FPGA gives you any device you can imagine that can be expressed as binary gates.

I know VHDL is a bitch but so was assembler, C etc too. It's hard but the reward makes it worthwhile. The power is awesome.

yet they make the daughterboard with an 060 which proves its rather hard to beat it with fpga. with a emu accelerator we might achieve multiple of that speed probably at the fration of cost.

im not against pure fpga. in fact i support it too, but look, minimig is too low end to get much interest, fpgaarcade constantly delayed, natami abandoned, the rest just proof of concept doesnt give much to hold to. we need something radical. we have to be shameless(ly honest to ourselves). and also try to find a way of least resistance (least complicated work we have no ressources to do (fpga)). and this is why i think of x86 or arm as host and amigaboard as slave device on pci or the like is quite revolutionary.

[Heiroglyph]

A large enough FPGA like XC3S1600 as used in FPGA Arcade cost 68 USD at D-key. Currently it can be seen in the FPGA Arcade thread it can beat 68030 @ 20 MHz Amigas using a 16-byte cache (4.46 times A1200). With hope of 28 MHz.
Thread: http://www.amiga.org/forums/printthread.php?t=39806&pp=15&page=57
Sysinfo: http://www.yaqube.neostrada.pl/images/SysInfo28-16.gif

So XC3S1600 is more than enough and it has already been done.

The FPGA gives you any device you can imagine that can be expressed as binary gates.

I know VHDL is a bitch but so was assembler, C etc too. It's hard but the reward makes it worthwhile. The power is awesome.

I'm not really excited about 4x A1200 speeds. It's still not faster than an off the shelf 680x0 that just needs glue.

I feel that if it's not 10+ times the speed of an 060@50 then it's not a success.  If you can get 20x 060/50 performance then it's time to pat yourself on the back.  UAE can do it while also emulating the whole chipset, so it is possible with the right  CPU.

That type of speed just doesn't seem doable in a reasonably priced FPGA.

Edit: Also, like I said, *I* can't reasonably do it in an FPGA.  I can do a localbus interface and I can do software.  I'm just tired of waiting for "it's not that hard" to happen and following my gut on the quickest path to get there.