New 68060 accelerator idea

[alexh]

Originally Posted by jimbob

Just an idle question but what's been the problem with creating a good 020 softcore. I thought 68k series was pretty well documented. So is it "just" lots of hard work, or undocumented wierd stuff, or some fundamental problem with using current/affordable FPGA?

I sometimes hear "Everyone is working on it". But in reality I believe no-one is actively working on it. Why? Because they have heard that "everyone is working on it"?

The original author of TG68k (and it's .C extension) was Tobias Gubener aka Tobiflex. The last time he actively worked on it in public was ~2013.

Unfortunately the source code has no home... It was hosted on opencores.org but that repository has not been updated in a long time and is missing several updates by Tobiflex posted to forums.

And yet it has hundreds of homes... it was adopted by many SoC cores which use the 68k and so it has been put into 10's of GIT/GoogleCode/... so which one is the latest? Where do you start?

Both Jaqube and Mike from FPGArcade were supposed to be working on their own 68020 synthesisable cores but I have seen nothing.

The Apollo team are closed source but seem to be concentrating on advanced features and their core is now "68EC040" according to Majesta. But I don't know if they fixed all the stack-frame and exception stuff that wasn't implemented last time they posted updates.

http://www.majsta.com/

Either way they are closed source. Unlikely but not impossible they would share with a new developer. They seem to have embraced Majesta.

[eXeler0]

@alexh its your choice to see the glass half empty all the time instead of half full, but to me there is more work being done on new and/or improved 68k softcores than ever before.
MikeJ said he worked on his own core but AFAIK the FPGA arcade is currently still using T68.
Anyhoo, according to Gunnar, the Apollo-core team inndeed has an FPU but it hasnt been added to the core yet. But considering we're at EC040 already, Im optimistic.
Does it really matter if its closed source? If the alternative is a super expensive real 060 the licensing the Apollo-core should be cheap in comparison...

[ppcamiga1]

68060 is underpowered, overpriced not worth of use crap.
Classic amiga is not interesting because is to sloow and classic amiga realy need something faster.
Some accelerator with something faster than 68k and it must be Big Endian processor.
PowerPc is ideal for classic amiga, but if it will be easier to do MIPS is also welcome.
Ofcourse there is no reason to put 68k processor on accelerator card, risc with jit will be faster than any 68k.

[ptyerman]

In that scenario you might as well just use your PC with UAE. Lot cheaper and faster! I (and many others) like the classic Amiga for what it is and like to push them to the maximum A new fast 68k (real or preferably FPGA) accelerator is something I and others would be very interested in.

[SKOLMAN_MWS]

ARM can work also in big endian.

[kolla]

AlexH: good point, I have yet to see for example OS3.9 (including using Reaction software, prefs etc) running on FPGA, or AROS/68k for that matter.

[rarefaction_]

Originally Posted by SKOLMAN_MWS

The resulting newer DSP on 56000 core. But I better put next to 68k low cost MPC5200B (PPC 603e) and integrate with WarpOS.

[ Show youtube player ]

http://ebay.com/itm/MPC5200CVR400B-F...-/111170594041

MPC5200B I/O System on Module



PPC + FPGA (68k) + 128MB DDR / 64MB Flash
+ USB 1.1, Ethernet, ATA 1.0, CAN, UART, I2S

That's a very interesting module...

btw guys I really appreciate your input and discussion of emulation vs the real thing!! keep it going it's really great to get a sense of what the scene is really lusting for.

On the PPC front, as the guys from A-EON announced they are using the QorIQ series of 64 bit dual and quad core PPC chips in the new series of high end systems.

https://en.wikipedia.org/wiki/QorIQ#P5

If I did incorporate PPC I would want it to have some serious balls. It would be a lot of fun to have a trapdoor mounted card that brings the humble A1200 that kind of horsepower and expansion with nothing else required but a modern high current PSU.

I do understand the metaphor of it 'strapping a jet engine to a vw bug', but that's what hardware hacks are all about - and it's not like it's going to be overly expensive...

sure it's easier grabbing a couple of older hex core xeons for 300 bucks each and an used super micro dual cpu board for $100 and having 24 threads of modern usable grunt... but where's the fun?? where's the challenge??

it's just going to take a lot of hours/days/months/years to realise and in the end it might just end up being a massive learning experience in all of my favourite fields of study and passion. That's what it's all about for me. I just want to learn, make things work, nut things out until they do work, burn a few things out and blow them up from time to time.. but that's what we as systems engineers and electronic engineers live for!

[rarefaction_]

Originally Posted by Yakumo9275

with a wishlist like in the original post, Id rather see something like a new mobo like GBA1000 but with some fpga juice acting as the aga chipset, then your not constrained by trying to stick a power 7+ module in the trapdoor (I doubt the op has even seen a power 7+ module...).

I was exaggerating... I meant something more along the lines of a P5040 ..just something modern..

[eXeler0]

Originally Posted by rarefaction_

8>< ------
it's just going to take a lot of hours/days/months/years to realise and in the end it might just end up being a massive learning experience in all of my favourite fields of study and passion. That's what it's all about for me. I just want to learn, make things work, nut things out until they do work, burn a few things out and blow them up from time to time.. but that's what we as systems engineers and electronic engineers live for!

I like your attitude ;-)

[pandy71]

Originally Posted by BigFan

How is this supposed to work on/in any amiga model with 68k-only code in ROM ????
It would require to boot the alien cpu from its own boot code. That is, the machine is independant, hampered by the attached amiga model. Silly!
You better stick with emulators on cheaper machines.

Small FPGA to translate 68k bus and support some code translation + software - why you think that modern 1GHz++ CPU will be slower than 100MHz 68060? Similar concept to Transmeta...
Boot - no problem - imagine that emulated 68k keep system board in RESET state which is released when main CPU is ready to emulate 68k...
Thx to HW you fully control 68k bus, supporting all critical time things correctly... rest purely to software emulation - not sure what kind of speed is offered by cheap RPi2 ARM but i can imagine 1 core dedicated purely to 68k emulation should be sufficiently fast to be comparable to 68060 - side to this you have 3d GPU + RTG

Basilisk II seem to work on RPi so on faster RPi II emulating only CPU should be faster - side to this it is without JIT (no JIT for ARM) but JIT can be created so everything will be faster... [ Show youtube player ]

[ptyerman]

Again your talking more or less of a PC and UAE. What's the point?

[h0ffman]

All ANYONE wants is a fast, well ram endowed 68060 with FPU from the A1200!

and at a good price.

[britelite]

Originally Posted by h0ffman

All ANYONE wants is a fast, well ram endowed 68060 with FPU from the A1200!

and at a good price.

Exactly, a replacement for the aging Blizzard 1260, without any additional bells & whistles that are going unused anyway

[Jope]

Originally Posted by britelite

Exactly, a replacement for the aging Blizzard 1260, without any additional bells & whistles that are going unused anyway

I tend to agree. 060 + lots of RAM + RTC.

[modrobert]

eXeler0,

I think alexh is being realistic rather than pessimistic, and his comments describes the current situation, not the potential future.


"Thread",

Even if you can design a state machine in VHDL/Verilog that behaves like a 680x0 CPU it is not easy to make it 100% compatible. Are the instructions really tested to use the same number of clock cycles as the original CPU? How about combinations of certain instructions over time, is the state of all current flags exactly the same when compared (not just the affected ones according to manual, but from actually observing and comparing with original CPU over time)? Does each pulse for a given instruction look exactly the same on the actual bus pins when checking the signal with an oscilloscope, or does it only match as far as the logic level states are concerned?

I think the Amiga related CPU cores needs to be open source, it's just too much work for any single person (or team) to test this properly, public collaboration and scrutiny is clearly an advantage in this case. It benefits everyone, including those who sell designs where the specific core is included. Instead of having a bunch of "half ass" closed source CPU cores which are incompatible in a feeble attempt to gain market advantage.

BTW:

Sun Microsystems was brave enough to release their UltraSPARC T1/T2 64bit CPU designs open source, I hope Freescale (or Motorola?) can do the same with the 680x0 family eventually.

[Vot]

Originally Posted by modrobert

I hope Freescale (or Motorola?) can do the same with the 680x0 family eventually.

I wouldn't hold your breath waiting for that to happen.

[BigFan]

68k and cpu32 cores are still used in embedded market. Why would or should they open source it?

If one thinks all 68k related design has to be opened, then go for a dispute with apollo team.
No, i don't think this is a good idea, and it leads to nowhere. There aren't enough engineers to continue development nor companies interested in doing masks, diffusing and assembling real cores.
This is not as easy as writing code.

VHDL code for fpga is not the same as using toolkits for ic in real production. Don't mix it.

[alexh]

Originally Posted by modrobert

Even if you can design a state machine in VHDL/Verilog that behaves like a 680x0 CPU it is not easy to make it 100% compatible. Are the instructions really tested to use the same number of clock cycles as the original CPU? How about combinations of certain instructions over time, is the state of all current flags exactly the same when compared (not just the affected ones according to manual, but from actually observing and comparing with original CPU over time)? Does each pulse for a given instruction look exactly the same on the actual bus pins when checking the signal with an oscilloscope, or does it only match as far as the logic level states are concerned?

It's funny you said this. One of the MiST developers has created an Archimedes core for the FPGA. He started with the AMBER for the ARM2, an open source re-creation of the ARM2. However compatibility was very bad. So what the guy did was take a cycle accurate software model of the ARM2 from an Archimedes emulator and turn it into a DPI model (that's a model which plugs into a HDL simulator). Controlled random data was loaded into both the DPI model and the HDL and the state of both compared every cycle. It fixed LOTS of bugs and the MiST core is now quite usable. I applaud this developer. Nice work.

If the WinUAE 020 emulation has neared cycle accuracy then a HDL core could be compared.

BUT... TG68k.C (and presumably Apollo) are not cycle accurate. They are only bit accurate (or are trying to be). This is how they get their speed improvements over a real 680x0.

[pandy71]

Originally Posted by alexh

It's funny you said this. One of the MiST developers has created an Archimedes core for the FPGA. He started with the AMBER for the ARM2, an open source re-creation of the ARM2. However compatibility was very bad. So what the guy did was take a cycle accurate software model of the ARM2 from an Archimedes emulator and turn it into a DPI model (that's a model which plugs into a HDL simulator). Controlled random data was loaded into both the DPI model and the HDL and the state of both compared every cycle. It fixed LOTS of bugs and the MiST core is now quite usable.

Strange - people demands 68060 fastest as possible and at the same time cycle exact - where is point of this?

[alexh]

Erm, I was just demonstrating where someone had verified their HDL using an interesting method. The Archimedes (and probably the Atari ST) need cycle accurate CPU's more than the Amiga because they used cycle accurate (and bit accurate) effects in their software.

Cycle accuracy isn't as important on the Amiga as it's chipset is somewhat decoupled from the CPU and because we have had so many different processors over the years software doesn't rely as much on cycle accuracy.

As I said, not being cycle accurate is how the TG68k and Apollo get (some) of their speed.

But bit-accuracy is essential for everyone. And a good verification technique for bit-accurate CPU's is also essential. Constrained random data coupled with functional coverage are very useful for CPU verification. But you need a good model.