Motorola 68060 FPGA replacement module (idea)

[Bobo68]

Could it be possible implement cpu and gpu to FPGA? Something like ... Cirrus Logic GD5446 or S3 Virge?

whether their design is opened?

[bloodline]

I think Jim Drew is suggesting that the FPGA only swaps the bus when the CPU makes a request larger than a byte.

[Heiroglyph]

Sure you can.  In fact, the FPGA would only swap certain instructions where this is required.

The swap is only required because the byte order is backwards (Endian issue).  So, if you fetch a long word from memory using something like mov.l $12345678,d0 that memory location will appear backwards to an x86 and would have to be swapped.  The swap occurs during the opcode emulation, and using some hardware means to perform the swap (like the bus wired backwards momentarily) would eliminate having to do it in software.

The problem with JIT is that it is not cycle exact, so it breaks a LOT of programs.  This is where the FPGA would come in handy as it could be used to throttle the instruction cycle speed so it is correct for a given desired performance level.

Maybe I'm considering a different path, but with an emulated CPU, you'll still be byte swapping for every local memory (non-Amiga bus) read and write.  

Not taking advantage of inexpensive memory that's local to the real CPU would cut down performance dramatically so I assume you'd want this.

Given the comparatively slow Amiga bus, wouldn't swapping only on the local accesses and letting an FPGA byte swap Amiga accesses introduce unnecessary checks in the code and extra complexity in the FPGA?

It would seem to me that using the same macro, etc. to swap accesses throughout the JIT would keep the code cleaner and be less likely to introduce careless errors.  It just seems like premature optimization.

And I'm not sure cycle exact is really a problem except for badly written software that would already have broken under 020 and 030.

[Mrs Beanbag]

Sure you can.  In fact, the FPGA would only swap certain instructions where this is required.

The swap is only required because the byte order is backwards (Endian issue).  So, if you fetch a long word from memory using something like mov.l $12345678,d0 that memory location will appear backwards to an x86 and would have to be swapped.  The swap occurs during the opcode emulation, and using some hardware means to perform the swap (like the bus wired backwards momentarily) would eliminate having to do it in software

I hope you mean move.l #$12345678,D0. But look at Psxphill's example. Supposing you do
move.l (A0),D0
move.b (A0),D1

which byte of (A0) ends up in D1? Given that (A0) is now cached.

Let A0 point to an address that contains $12345678. FPGA swaps it to $78563412. Second line then reads $78 instead of $12!

If this were such a trivial problem to solve, "endianness" wouldn't even be a thing.

[Heiroglyph]

Here is some interesting data on SPI and USB: http://www.totalphase.com/support/kb/10057/

[Heiroglyph]

So if those are too slow, then what about PCI?

PCI is faster than the Amiga bus both in clock and throughput and has the same bus width.  It should just be a matter of timing and translation.

We've recently seen the Prometheus PCI open sourced so there is a ZorroIII to PCI interface that works and only needs 1-2 CPLDs.  It could be even simpler since there aren't multiple PCI devices, it would be a target not a host and you wouldn't need to multiplex the address and data lines.

The DMA problem in the Prometheus design is a moot point since it only happens between multiple PCI cards and I'm not sure that DMA to and from the Amiga side is strictly needed.

What can DMA into addresses above 24bits?  In what cases would our super fast CPU require DMA down to the Amiga side?  It will be waiting on the slow bus regardless.

ZorroIII is very close to the 68k/030 bus we're trying to adapt to, so changes would be minimal and fairly obvious.

As long as the SOC you want supports PCI or PCI-e with an off the shelf bridge chip, that's still a very inexpensive solution with a pretty clear path.

[Mrs Beanbag]

PCI(e) could be very good, an adapter that essentially converts the Amiga 1200 chipset into a graphics/sound card, and an accelerator that is essentially a tiny motherboard.

Personally I don't see the motivation for trying to squeeze all the data down a serial interface of any kind, when we have naturally parallel devices at both ends.

[Heiroglyph]

PCI(e) could be very good, an adapter that essentially converts the Amiga 1200 chipset into a graphics/sound card, and an accelerator that is essentially a tiny motherboard.

Personally I don't see the motivation for trying to squeeze all the data down a serial interface of any kind, when we have naturally parallel devices at both ends.

The problem there is that the majority of cheap SOCs don't have PCI.

That precludes for example using the SOC that is in the inexpensive devices like the raspberry pi.

I'm just not seeing any other available connection that could be viable.

[Georg]

Emulators can "lay out" the emulated memory in whatever way they like as long as the emulation makes it look "normal" to the emulated machine.

A normal emulator like UAE will use:

emulated address 0: <--> address hostmem + 0
emulated address 1: <--> address hostmem + 1
emulated address 2: <--> address hostmem + 2
emulated address 3: <--> address hostmem + 3
emulated address 4: <--> address hostmem + 4
emulated address 5: <--> address hostmem + 5
emulated address 6: <--> address hostmem + 6
emulated address 7: <--> address hostmem + 7
[..]

But theoretically it can also use:

emulated address 0: <--> address hostmem_end - 0
emulated address 1: <--> address hostmem_end - 1
emulated address 2: <--> address hostmem_end - 2
emulated address 3: <--> address hostmem_end - 3
emulated address 4: <--> address hostmem_end - 4
emulated address 5: <--> address hostmem_end - 5
emulated address 6: <--> address hostmem_end - 6
emulated address 7: <--> address hostmem_end - 7
[..]

or:

emulated address 0: <--> address hostmem + 3
emulated address 1: <--> address hostmem + 2
emulated address 2: <--> address hostmem + 1
emulated address 3: <--> address hostmem + 0
emulated address 4: <--> address hostmem + 7
emulated address 5: <--> address hostmem + 6
emulated address 6: <--> address hostmem + 5
emulated address 7: <--> address hostmem + 4
[..]

Such tricks can help avoiding byte swaps but there are also some disadvantages like when the emulated machine wants to read something from disk which likely ends up using something like fopen/fread of host, which of course use normal memory layout. So after load you will need to fix up loaded stuff to match emulated layout (swap or mem reverse).

[JimDrew]

I hope you mean move.l #$12345678,D0. But look at Psxphill's example. Supposing you do
move.l (A0),D0
move.b (A0),D1

which byte of (A0) ends up in D1? Given that (A0) is now cached.

Since it is A0 itself that is byte swapped, the correct value for the lower byte will be returned.

Let A0 point to an address that contains $12345678. FPGA swaps it to $78563412. Second line then reads $78 instead of $12!

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

Again, I think the FPGA would end up slowing down the process when you had a fast x86.  I am not sure where the break even point would be - that would depend on how fast you could clock the FPGA.

Endian is really not that big of a deal when doing a 68K emulation.  It's just an extra process.

I guess you guys have to decide if you want 100% compatibility or not.  If you do, you absolutely must have a cycle exact emulation.  There are quite a few programs that require it.  You could also deliberately set emulation thresholds.  For example, you could set the speed/emulation type to be Amiga 500 (68000), Amiga 3000 (16MHz or 25MHz 030), Amiga 4000 (25MHz 68040), etc.  This way you could run those euro demos in Amiga 500 mode that won't work on anything else.  

[JimDrew]

Emulators can "lay out" the emulated memory in whatever way they like as long as the emulation makes it look "normal" to the emulated machine.

Yep.  My first version of the Pentium emulation for the Amiga used the PC memory map backwards.  This was so no byte swaps were necessary for the opcode emulation.  However, when it came to disk, DMA, screen stuff, etc.  It was a nightmare having to swap everything.  After a lot of testing I went to a forward memory map and that ended up being faster in the long run because of the reduced swapping needed for the video alone.

[Mrs Beanbag]

Since it is A0 itself that is byte swapped, the correct value for the lower byte will be returned.

What do you mean, A0 is byte swapped? How do you byte swap an address register? What address does it point to, the most significant byte of our longword, or the least significant byte? It can't point to two different addresses.

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

But the number is not $78563412. The number is $12345678. The byte value of that is $78.
A byte access wouldn't know anything about the other three bytes. The $12 is stored at (A0). The $12345678 is stored at (A0). If you swap it in memory, the address register no longer points at the most significant byte.

If there is a string in memory, such as "abcdefgh" does it get swapped to "dcbahgfe"? But the pointer to the start of the string still points to "a"?

Supposing we have a longword access at 2(a0), then what?

[JimDrew]

I think Jim Drew is suggesting that the FPGA only swaps the bus when the CPU makes a request larger than a byte.

I missed this post - That is correct.

[JimDrew]

Supposing we have a longword access at 2(a0), then what?

2 is added to the value of A0 and swapped.  This is no different than how we do it with software emulation.  An FPGA can certainly do anything that can be done in software.  Instead of the FPGA handling the entire CPU core, it would be handling the memory bus accesses and off-loading the CPU emulation itself to the primary (x86) CPU.

[Mrs Beanbag]

I missed this post - That is correct.

But the CPU is not making any request on the bus if the data is in the cache.

Also how would you distinguish between the virtual machine memory, and the memory required for the emulator itself (including its program)? You would not want to swap the emulator's program code around.

[Heiroglyph]

It's not bit swapped, the high byte is in a different place but the bits of each byte are still in the same order.

03 E8 vs. E8 03

You do have to be aware of the size of the data though.  Reading/writing a sequence of bytes vs a sequence of words for example.

A sequence of byte data could be 03 E8 03 E8 and would not need swapping, you're reading each in order.

A sequence of word data would still be 03 E8 03 E8 but you need to know to swap based on the intended size so that it correctly reads as E8 03 E8 03.

Loading a register should swap on the read, so A0 would already point to the right location.  Once the data is in a register it's already swapped as needed based on the instruction used to read it.  Transfer between registers wouldn't need a byte swap.