Motorola 68060 FPGA replacement module (idea)

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

[psxphill]

And the FPGA on the base board isn't large enough to implement a 68060 properly.

Has that been tried? I thought it was more that nobody had implemented the FPU & MMU.

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

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

[psxphill]

Here is another sysinfo screenshot:

sysinfo is horrendously innacurate, but it's showing that it's about half the speed of a 25mhz 68040 on the dhrystones test. So it needs to be at least 4 times faster.
 
longer pipelines might do it, getting from here to there is a huge jump though.

[psxphill]

Isn't 68000 architectually too far from the 68060 in order to gain useful insight into the original 68060 ..?

Probably. However the current cpu emulation is even further away from any architecture that Motorola ever used.
 
I see it more as a way of going on the same journey that Motorola did.

[psxphill]

That's why we added SBcc, SELcc, ABS, POPCNT, etc. to the ISA and which fit and have minimal pipeline overhead (hazards) while reducing short branches. Long branches still need to jump. If we could remove 5-15% of branches (the short ones) and the overhead in the branch cache and history, the 68k would be one of the best processors at branching. Add to that a relatively short pipeline (and mis-predicted branch penalty) and 0 cycle loops and we would have much improved performance, a beautiful CPU to program and even better code density.

Trying to improve the ISA is a time sink which you'll never get payback from. The only benefit is a bit of ego boosting, but that subsides when reality hits.
 
Making the pipeline follow the predicted branch might be hard, but it's doable. Thumb drops a lot of conditional instructions from Arm.

[psxphill]

It's not a time sink if people are working together in parallel which is the way it was suppose to be when I started documenting the new 68k ISA. It's not a time sink if the new ISA attracts interest from outside of the retro crowd. It's not a time sink if the ISA is implemented and found to be a substantial improvement in power, code density, compiler support and ease of programming. You give up very little with the possibility to gain much more. There is a market for retro computing but a bigger market for a processor that can handle today's processing needs quickly with compact code as well as being compatible with old code.

You're very optimistic.
 
It's difficult to predict the future, but I can't imagine there is anyone outside of the retro community that will ever have any interest in a 680x0 cpu core. There are far too many other SOC/ASIC/FPGA solutions that have already carved up the market. There is no competitive edge against any of the other alternatives and nobody in business will care if they can run 680x0 code.
 
The majority of people want something that can run existing software and use existing compilers, adding instructions will cause market fragmentation if anyone is tempted to ever use them. A product that doesn't ship because the people behind it gets delusions of grandeur is no use to anybody.
 
Chasing rainbows is all well and good, but it's the reason that Natami failed. I'd rather see something ship for once.

[psxphill]

ARM with Thumb 2 has moved close to what an enhanced 68k would be and it doesn't have any trouble selling. I think we would be a little more powerful and easier to use while Thumb 2 is a little more power efficient.

You can't dislodge ARM, even Intel will struggle taking them on.
 
Dreaming that you can, when you can't even duplicate what Motorola was doing twenty years ago, is just going to dislodge you from achieving anything.
 
If you look at the history of AROS, you'll see there were similar problems with the AmigOS project that preceded it:
 
"Several small groups' of Amiga users on the internet coordinated their efforts to create an open-source Amiga operating system that was not controlled by a incompetent, restrictive parent company. The most popular of these was the AmigOS project, which gained brief attention in Amiga User International during 1994. However, bitter flame wars on the feasibility of such an OS tore the project apart and the dream of an open-source Amiga OS disappeared.
 
During the fourth quarter of 1995, Aaron Digulla attempted to get the project moving again, by sending an RFC (Request For Comment) to the AmigOS mailing list. He suggested that a minimum specification list should be defined, allowing the creation of a basic open source OS. Once this stage had been completed, the group could decide if multi-processing, resource tracking, and other features missing from the official AmigaOS, could be implemented. After some discussion it was decided that the group should create a portable version of OS3.1. The Amiga Replacement Operating System was born..."
 
 
Only when they stopped arguing about how to do memory protection etc and just focus on OS3.1 compatibility did the project even start to take shape.
 
Natami still has a long way to go & it's going to be expensive. FPGA arcade has avoided a lot of the problems by only adding the bare minimum.
 
Also because mikej isn't trying to create his own computer platform, he doesn't have to try to control what is put into the FPGA. Natami on the other hand needed to lock out anyone from coming along who could write better VHDL.

[psxphill]

This seems counter intuitive. Bit of a dig a Natami management I presume.

I was just highlighting the difference between how the FPGA arcade and Natami projects are being run.
 
It's not a dig and they are both within their rights to do whatever they want and however they want. As soon as I saw the debates about what instructions to add to the N68070, I knew it was doomed.
 
Real Artists Ship.

[psxphill]

You seem to care a lot about preventing any new 680x0 CPUs being built.

You are mistaken, I would love to see a 68060+FPU+MMU emulation for an FPGA.
 

How is Matt Hey going to prevent MikeJ from shipping the Replay?

I never said it would. It's exactly MikeJ's approach that will mean that it will get shipped. Natami has lost a lot of steam because of their approach and hope of it being shipped goes down all the time.
 

I keep trying to ignore your repeated insults of Matt Hey and anyone else who wants to make a faster Amiga but .... Could you just please stop with the insults?

I think you misunderstand what an insult is. Disagreeing with someone is not an insult.

[psxphill]

I read here that the 060 bus interface is too complex and that the 030 bus is better, also the 060 is less compatible with amiga software than the 030 because many instructions were not implemented, so why do we want an 060 replica, why not try to implement an 030+882 that runs as fast as an 060?

Motorola removed some of the instructions added to the 020 and some of the FPU instructions to save space, that could be used for making it run quicker.
 
By only supporting the 060 instructions then you've saved space in the FPGA and the time taken to implement them.
 
The compatibility will be the same as a real 68060 & people have had nearly 20 years to come up with patches and workarounds for that.

[psxphill]

That's rather longer than I expected.

page 3-1
 
http://cache.freescale.com/files/32bit/doc/ref_manual/MC68060UM.pdf
 
The first 4 stages are for fetching and assigning the instruction to an integer unit. The next 4 stages are the dual integer unit, then the last two stages are completing the instructions.
 
It's quite a simple design.
 
It doesn't evenly distribute instructions between integer pipelines, it only uses the second integer pipeline when the first is running an instruction that can be run at the same time. Whether it can will depend on the instruction as not all can even be run on the second pipeline and the registers involved. If the instruction in the primary pipeline changes a register used in the next instruction then the next instruction also has to be put on the primary pipeline.
 
I don't know if the pipelines will get starved if you're continuously using both integer pipelines for instructions that only take 1 clock cycle to execute. It's not something that you can achieve in real world examples, however as a 32bit value can contain two instructions then it might be possible. There isn't much explained as to how this works though. They do say it's "capable of sustained execution rates of < 1 machine cycle per instruction of the M68000 instruction set". But if it could sustain 2 instructions per machine cycle then I would have thought they would have claimed that.

There is a document (http://cdn.preterhuman.net/texts/underground/phreak/68060Info.txt) that explains the pipelines in more detail, I don't where the pdf is as the pictures are missing in the ascii version. It might be this: http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=289639 but I'm not paying for it :-)
 
The branch executing in zero cycles doesn't seem to be very well documented. I can't tell whether they are over-exaggerating what it does or not. My original thought was that the branch is in the primary pipeline and the secondary pipeline has the target or next instruction (depending on what is predicted). This doesn't actually cause it to execute in 0 cycles when looking at the pipeline as a whole, but when looking at the branch on it's own it does have a 0 cycle overhead.
 
What is odd is that they claim different for predicted correctly taken and predicted correctly not taken
 
"If the BC indicates that the instruction is a branch and that this branch should be predicted as taken,
the IAG pipeline stage is updated with the target address of the branch
instead of the next sequential address. This approach, along with the
instruction folding techniques that the BC uses, allow the 68060 to achieve a
zero-clock latency penalty for correctly predicted taken branches.
If the BC predicts a branch as not-taken, there is no discontinuity
in the instruction prefetch stream. The IFP continues to fetch instructions
sequentially. Eventually, the not-taken branch instruction executes as a
single-clock instruction in the OEP, so correctly predicted not-taken
branches require a single clock to execute. These predicted as not-taken
branches allow a superscalar instruction dispatch, so in many cases, the next
instruction executes simultaneously in the sOEP."
 
So it would imply that the branch doesn't hit the execute stage of the pipeline, but then the document goes on to say it does.
 
"The 68060 performs the actual condition code checking to evaluate the
branch conditions in the EX stage of the OEP. If a branch has been
mispredicted, the 68060 discards the contents of the IFP and the OEPs, and
the 68060 resumes fetching of the instruction stream at the correct location.
To refill the pipeline in this manner, there is a seven-clock penalty for a
mispredicted branch."
 
I guess it comes down to how you interpret this from the first quote:
 
"allow the 68060 to achieve a zero-clock latency penalty for correctly predicted taken branches"

[psxphill]

There is also a translation from 16 bit variable length CISC to a fixed length 16 bit RISC in there. I don't think Motorola released the encoding format of their internal fixed length RISC making it difficult to duplicate.

Is there any evidence to show they remap the opcodes at all? They might just store each opcode +operands within the fixed width fifo.
 
Maybe the early decode just figures out how long each instruction is and whether the next instruction is valid to go in the secondary pipeline.

[psxphill]

So there is a a kind of selection process such that instructions that doesn't depend on sequent instructions could be done in parallel while the rest is single pipeline?

Yeah, you can't execute in parallel if the first instruction modifies a register that the second uses: for example
 
MOVEQ #0,D0
TST.W D0
 
The secondary pipeline can't execute all instructions either. Floating point instructions can only be dispatched from the primary pipeline for instance.
 
From the description it would seem that it checks in the DS stage whether it can be executed in parallel, which implies there is one fifo for both execution units. I'd have thought that would make it tricker than a fifo for each pipeline, but the documentation is what you'd have to go on for a pure clone.
 
The manual is largely vague on the FIFO:
 
"The instruction is pre-decoded for pipeline control information"
 
"The MC68060 variable-length instruction system is internally decoded into a fixed-length representation and channeled into an instruction buffer.


 
There are 96 bytes for the FIFO. Someone claims it's 16 entries of 6 bytes each, but the longest instruction is 10 bytes and there is no way you're going to squeeze an MOVE $10000,$20000 instruction into 6 bytes. It's more likely to be 6 entries of 16 bytes or 4 entries of 24 bytes. I can't find anything that suggests that instructions are split into multiple "micro ops", like Intel does.
 
The 68060 cannot execute out of order and doesn't do anything complex like register renaming that Intel did on the Pentium pro. It really is the simplest design for dual issue that you can possibly do.
 
There is no reason why you have to 100% duplicate the functionality exactly. However if there is documentation available then it might make sense to do it the same as they probably spent a while designing it, so it's probably good.

[psxphill]

What's a "Link stack" ..?

It might be what the later coldfire has, which is an on chip stack which allows the target of an rts instruction to be predicted.
 
As well as writing to the a7 stack, the jsr stores the program counter in the on chip stack. When the rts instruction is fetched it assumes the next instruction is the value off the on chip stack. If when it executes the value is different then it flushes the pipeline.
 
At the moment the rts basically blocks the pipeline until it executes, which is why it's such a slow instruction.
 
It's only a four entry stack though and as I don't think it can support re-fetching lower return values, then it's probably not that great apart from simple subroutines being called from a loop.
 
An 060 MMU in an FPGA isn't going to take a huge amount of space. An FPU on the other hand probably will.
 
In the manual it says it transfers 16 bits for the opcode and 2 x 32 bit operands from the fifo, which is 10 bytes and sounds pretty much like the 68000 instruction set converted to fixed length. So it might be 8 instructions of 12 bytes each, with 2 bytes used for "pipeline control". For whatever this means in the manual: "The instruction is pre-decoded for pipeline control information"