Motorola 68060 FPGA replacement module (idea)

[psxphill]

Fastest I ever heard about back when I studied RAM chips was 333Mhz.

http://en.wikipedia.org/wiki/DDR3_SDRAM#JEDEC_standard_modules
 
It looks like 1066mhz is the fastest standard I/o clock speed & 266mhz for the memory clock speed, but the latency's are huge. This isn't a problem if you can prefetch and burst fill your cache. You get 64bits per transfer per module as well.
 
It doesn't sound like much, but compared to chip ram or the memory in your 90's accelerator. It is pretty quick.

[psxphill]

For randomly accessing memory your speed is 266Mhz / 16 = 16.625Mhz which is the same speed as the memory u already have on your Amiga accelerator card.

I think the latencies are based on the io bus clock, not the memory clock. So it's not 266/16, it's 1066/16. The reasons why the latencies get higher is because of the increasing gap between the two clocks. The computer is using the io bus clock, so it makes sense for it to be based on that.
 
Old ram from the 90's also has page setup times. Fast page mode and static column were equivalent to how memory is accessed now, if you were accessing data in different pages then you had the latency. Because of this the 030/040/060 can burst reads from ram a cache line at a time. http://en.wikipedia.org/wiki/Dynamic_random-access_memory#Fast_page_mode_DRAM_.28FPM_DRAM.29
 
Ram is wider now than it was, so if you were creating a 68k memory controller with DDR3 then you'd keep reading the entire page from the ram all the time there was no other memory access required. You've paid for the entire page to be read, it just needs to be transferred and that bus can run up to 1066mhz. Even if the code does random access memory often, which would make you want to stop caching other data, the page is more likely to still be open compared to old 90's memory as it's bigger (like 256 bytes).
 
http://en.wikipedia.org/wiki/Prefetch_buffer
 
Suggesting that modern ram is the same speed as old ram is wildly missing the point. It's a lot more complex to interface to, but if you could hook up ddr3 to a 68060 then it would run quicker.

[psxphill]

You only get good speed when reading/writing a bunch of bytes in a straight line.

That is exactly what cache bursting is for. It's as true now as it was in the 90's.

[psxphill]

I am curious why there is some idea of a shortage of 68060 chips? There are tens of thousands of these chips, both 50MHz and 60MHz (MC and XC versions) available from suppliers in China.

The shortage is only because we're looking for the rare versions with the bugs fixed & sellers in china are remarking chips to say they are the latest mask (71E41J) when they are not. The real ones can be clocked over 100mhz.

[psxphill]

Even though everyone who ever bought any of them was pleased with the results.

You might want to ask why mikej decided not to buy any of the remarked chips he was offered, if you think he would have been pleased.

[psxphill]

It might be a good starting point.

If this is the one then I'm not sure that you get the source for it
 
http://www.ip-extreme.com/IP/coldfire_altera_v1.shtml
 
"DELIVERABLES

• Encrypted RTL source code and Qsys component for the CFV1CORE_ALTERA
• Quartus IP license
• Integration testbench and example test programs
• Documentation "

You only get the source code if you buy the asic version.

[psxphill]

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.

Some of Intel's processor have a much simpler bus.
 
http://www.versalogic.com/support/Downloads/PDF/Intel_Atom_Datasheet.pdf
 
I wouldn't want to solder something like that though.
 
I've tried to find a datasheet for one of the more recent atoms & they do seem to be difficult to find. If Intel want to take on Arm in the mobile phone market then they'll have to make it public at some point though.
 
I think it's unrealistic to do this in an 68060 replacement module, but an A1200 accelerator design would be awesome.

[psxphill]

or an 030slot board for big box amigas. the glueboard could provide both variants.

Big box amiga's will always be a minority, but there should be no reason why they are ignored. I got rid of an A1500 recently because I'd given up on anyone producing anything for it. In the late 90's I was thinking of doing an A1200 to A2000 cpu slot adapter but I never really started. In fact it would probably by just as effective to produce adapters for all the different amiga's to allow an A1200 accelerator to be fitted.
 
You could do an a500 sidecar too.

[psxphill]

Seems http://www.majsta.com/ has come slightly further:
 
 
On 4th januari it has trouble booting. On 9th januari the FPGA seems to emulate 68010.

I think his biggest achievement is he did his own hardware first. Hooking up a development board to your Amiga and then downloading someone elses cpu core is likely to hit a plateau when you see it work. "Damn now I got to start from scratch and build my own hardware". Ok that board is not ready to be mass produced, but it can be tidied up pretty easy.
 
So yeah, awesome work.. Pity it's for a600 and I don't have one. Can someone give him an A1200 ?

[psxphill]

My 68040 core handles everything without needing the endian reversed, but I am sure it would be significantly faster without having to do that.

The standard way is to treat memory as a an array of little endian dwords and then:
 
byte: xor the address with 3
word: for aligned xor the address with 2, for unaligned either one or two accesses depending on how it's split and then shift
dword: for aligned do nothing, for unaligned you have to split it up into two aligned accesses and then shift
 
There isn't really an alternative to that & that's as fast as it gets
 
The fpga can't know when to swap as it requires knowledge about what the cpu is trying to do with the data, plus it won't even be asked about data once it's cached. So if you read memory as a dword and then as a byte, it will not work.

[psxphill]

supposing one does a movem.w (SP)+,D0-D7 for instance... urgh

movem.w is heavy without the endian, you need to look at the bitmask to determine which 68k registers need writing out and then load them from ram into x86 registers before writing them out.
 
You could probably have an aligned and an unaligned version (whether it's aligned to a word boundary is not going to change by writing another word).
 
Doesn't movem.w (SP)+ add 4 to the stack pointer for each write? at least on some processors I'm sure the stack pointer gets 4 byte aligned.

[psxphill]

The programmer's reference manual doesn't say so. It says "the address is incremented by the operand length (2 or 4)".

Ok. It's bytes that affect a7 by 2, but everything else by 1.
 
"Indirect addressing with postincrement

Assembler syntax:

• (An)+

Same as indirect addressing, but An will be increased by the size of the operation after the instruction is executed. The only exception is byte operations on A7 - this register must point to an even address, so it will always increment by at least 2. Example:"
 

How do you know if you need to swap or not ? For example a memory copy function that uses 32bit transfers but may be copying strings that may not be byte swapped ?

My only thought would be to access bytes/words & dwords at different address ranges & disable all the caches. You could implement a cache inside the fpga, although it would probably still be slower than the on chip cache because it would be limited to the fsb speed. You'd have to do it to figure out which came out better or worse.
 
Most of the time the 68k code would be doing aligned accesses, so that should show up in the branch prediction. So a test for whether it's aligned and then the xor is likely to not have much impact at all.
 
I know Mike Coates spent a long time optimising his 68k core back in the day, it was used in MAME back in the late 1990's & early 2000's. Obviously some of the optimisations are likely to be deoptimisations on recent cpu's, but the clock speed outweighs the effort required. Even musashi (the C core that MAME now uses) would probably be more than sufficient.
 
Or if someone does an ARM board instead then there is always http://notaz.gp2x.de/cyclone.php
 
My thought on using x86 (or even better x64) is that using a VM on the card could allow a bridge board style PC emulator to run at the same time as the 68k. Crazy idea I guess, but heh these ideas are all crazy.

[psxphill]

What we DON'T have is a FPGA accelerator, because we don't have a 68k core. One reason why not is it means developing both hardware and software at once, while either on their own is a task in itself, so we get stuck at an impasse. No core? FPGA accelerator=useless. No FPGA accelerator? Core=useless.

There are already open source 68k cores, the bus interface is going to be specific to the hardware you build. The problem is that nobody wants to make accelerator fpga hardware. The a600 has a prototype one, which is looking promising.
 
If someone did an a1200 one and it could run 68k code at the equivalent of 100mhz then loads of people would buy it.

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

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