Motorola 68060 FPGA replacement module (idea)

[bloodline]

Once upon a time there was a maybe more advanced one than that but ARM had it disposed of. If you look hard enough you might find it in some shady corner of the netiverse, but that was news over 10 years ago...

Here is an implementation of the ARM2 ISA... It's old but would make a great starting point for any CPU project!

http://opencores.org/project,amber

[freqmax]

The ARM corporation is extremely aggressive when it comes to ARM implementations in any form. Beware! I think they have some sneaky patents on some 10 or so instructions. This is also a reason I prefere MIPS or perhaps OpenSPARC.

[Plaz]

I took bloodline's reference as a point of study of how to do another cpu project, not necessarily an ARM.

I haven't messed with VHDL in an uncountable number of years. Someone please point me to a good reference where I can retrain some brain cells on some tools needed here.

Plaz

[matthey]

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.

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. That's what ARM and x86 did. They evolved and now they are successful. Building a 68020 compatible CPU comes first, but even then it's smart to plan ahead to make future enhancements easier.

Making the pipeline follow the predicted branch might be hard, but it's doable. Thumb drops a lot of conditional instructions from Arm.

Yes, but they were using predication (unusual for a CPU) that only offers a small advantage in some specific hardware. The smaller the block of predicated instructions and the simpler the instructions the better. Most original ARM ISA instructions could be conditional which worked ok but was dropped with the Thumbs because it was not good for code density which they were going after. The ARM block predication instruction was for multiple instruction predication but ARM went to OoO processors where it didn't work as well. The conditional instructions proposed in the 68kF ISA should work nicely while being a small simplification improvement over a more generic CMOV like x86. They would work well on a Superscaler CPU with a short pipeline and a cheap branch predictor (or no branch predictor) which the 68k is likely to have. There would still be some optimized code that would not want to use them at times. This includes highly predictable branches that are executed often and very tight loops where a highly predictable branch could be used instead. Note that some instructions like ABS (absolute value) have no drawbacks yet remove a branch that can be difficult to predict and SELcc can remove 2 branches in some cases. I would like to do some testing in an implementation before finalizing the ISA.

[bloodline]

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. That's what ARM and x86 did. They evolved and now they are successful. Building a 68020 compatible CPU comes first, but even then it's smart to plan ahead to make future enhancements easier.



Yes, but they were using predication (unusual for a CPU) that only offers a small advantage in some specific hardware. The smaller the block of predicated instructions and the simpler the instructions the better. Most original ARM ISA instructions could be conditional which worked ok but was dropped with the Thumbs because it was not good for code density which they were going after. The ARM block predication instruction was for multiple instruction predication but ARM went to OoO processors where it didn't work as well. The conditional instructions proposed in the 68kF ISA should work nicely while being a small simplification improvement over a more generic CMOV like x86. They would work well on a Superscaler CPU with a short pipeline and a cheap branch predictor (or no branch predictor) which the 68k is likely to have. There would still be some optimized code that would not want to use them at times. This includes highly predictable branches that are executed often and very tight loops where a highly predictable branch could be used instead. Note that some instructions like ABS (absolute value) have no drawbacks yet remove a branch that can be difficult to predict and SELcc can remove 2 branches in some cases. I would like to do some testing in an implementation before finalizing the ISA.

Sounds interesting, you might want to start a new thread about optimising and evolving the 68k ISA... As any discussion here might get confused with talk about FPGA implementations

[matthey]

Sounds interesting, you might want to start a new thread about optimising and evolving the 68k ISA... As any discussion here might get confused with talk about FPGA implementations

There is this thread on amigacoding.de:

http://www.amigacoding.de/index.php?topic=273.msg635;topicseen#msg635

There is also a lot of good techy discussion on the Natami forum where the ideas started. You can do searches there for about any CPU term and find something interesting.

[wawrzon]

perhaps it would be sensible to start multiple threads on amiga coding de according to dirrerent party of the approach and parts the project can be divided into, like:
1. fpga 68k implementation
2. arm/x86 68k emu
3. pci2amiga interface

the only thing is that the other site has probably not the traffic and attendance one of regular amiga sites has.

[freqmax]

The fundamental problem with this and other sites is that threaded discussion management is missing. Usenet is the ****

[wawrzon]

just at some point if and when basic decissions are taken, the thread will have to be split anyway, otherwise we will get lost.

[Hattig]

Maybe "amiga hardware designs" should be a new subforum of the hardware discussion forum.

[Heiroglyph]

Sorry for throwing yet another diversion into the thread.

I don't think the PCI to Amiga warrants a separate thread unless someone makes tangible progress.

It's probably just an option for cpuXtoAmiga like FPGA 060 replacement is a subset of 680x0 accelerator.

[Iggy]

Maybe "amiga hardware designs" should be a new subforum of the hardware discussion forum.

Good idea.
We could have threads for separate ideas there.
The problem is, all three approaches appeal to me.

FPGA (for entire system, CPU, or chipset).
X86 or ARM emulation (of CPU only, an FPGA might be used for the chipset).
OR....A fast, real 68K (LC and EC chips really interest me) - 100 Mhz anyone?

[billt]

I took bloodline's reference as a point of study of how to do another cpu project, not necessarily an ARM.

I haven't messed with VHDL in an uncountable number of years. Someone please point me to a good reference where I can retrain some brain cells on some tools needed here.

Plaz

My favorite, and I wish he had a Verilog "port" of this one:
http://www.amazon.com/RTL-Hardware-Design-Using-VHDL/dp/0471720925/ref=la_B001ITRMEY_1_3?ie=UTF8&qid=1358352110&sr=1-3

and:
http://www.amazon.com/FPGA-Prototyping-VHDL-Examples-Spartan-3/dp/0470185317/ref=la_B001ITRMEY_1_2?ie=UTF8&qid=1358352110&sr=1-2

http://www.amazon.com/Embedded-SoPC-Design-Processor-Examples/dp/111800888X/ref=la_B001ITRMEY_1_5?ie=UTF8&qid=1358352110&sr=1-5

And verilog "ports" of a couple of these as well:

http://www.amazon.com/FPGA-Prototyping-Verilog-Examples-Spartan-3/dp/0470185325/ref=pd_sim_b_3

http://www.amazon.com/Embedded-Design-Processor-Verilog-Examples/dp/1118011031/ref=pd_sim_b_2

Note that these won't really talk as much about some things one needs to know for an FPGA softcore sort of project, such as number representation and such, particularly floating point stuff. I'm currently checking out this one too (Verilog, but should be easy to understand and use toward VHDL projects too):

http://www.amazon.com/Computer-Arithmetic-Verilog-HDL-Fundamentals/dp/1439811245/ref=sr_1_1?s=books&ie=UTF8&qid=1358352361&sr=1-1&keywords=verilog+arithmetic

[freqmax]

Personally I prefer Verilog. But it lack som capabilities, I think it was in regard to level triggering etc. So VHDL is it.

Btw, those links are books , not hw.

[billt]

Personally I prefer Verilog. But it lack som capabilities, I think it was in regard to level triggering etc. So VHDL is it.

Btw, those links are books , not hw.

I also prefer Verilog, but am now comfortable enough with VHDL to go either way.

He asked for references to retrain his brain since he hadn't used VHDL in so long... So book links seemed appropriate.

[wawrzon]

Maybe "amiga hardware designs" should be a new subforum of the hardware discussion forum.

remember you will not get people like jens shoenfeld contributung to threads on this site. also the likes of toni wilen might help. if not amiga-coding.de then eab might be better place for brainstorming.