Quick Performance Overview: Higher is better
  Chip         68000  68020   68030   68040   68060   
  Clock MHz        7     14      50      40      60        
  --------------------------------------------------                                              
  Addition         1    5.5    20.5    34.8    110.2
  Shift          0.5    3.0    11.3    18.9    111.1
  Multiplication 0.1    0.5     1.8     3.7     30.1 
  

This is starting to sound pretty ambitious.

You indeed have cojones.

I fully support you, guys. This could become a completely community-controlled architecture and it has potential.

However, a full 68k design looks like a big undertaking.
So big that in fact could kill the fun of the whole project.

But it may be possible to reduce the effort starting from something already done?...

OpenCores.org

You are right, a full 68k design is not something you can do on a week end or two.

On the other hand, if you put into perspective what features our SuperAGA chipset has: with the 3D engine so powerful that it can do hundreds of millions of multiplications per second.
Building an arithmetic engine that is more powerful than every old 68k is not the problem actually.

What makes the 68k special is the quite clever address calculation that it has.
To build a very fast 68k CPU you need to implement a good EA-unit,
a load /store/ arithmetic unit and a clever decoder which cracks the 68k instructions into instructions for the units.

If you do it like this than a clockrate of over 100 MHz and more is not a problem.

Cheers
Gunnar

Don't let this delay the release of the first version though... we're still on for summer 2008, yes? :)

This is correct.
It became clear that by putting a "real 68k" into the same chip as the SuperAGA chipset will have some gmajor advantages.

For example:
A challenge for every system is caching IO memory.
If you use Disk DMA to load now code into the memory then you have always a challenge with CPUs that have a cache.
The often implemented ways to solve this are
a) to load into non cacheable memory
b) to flush your CPU cache after loading
Both option degrade the performance a lot

We realized that if we control the CPU then we can eliminate this bottleneck completely. The Amiga in a single Chip control both CPU and cache and the Disk DMA. This means we can savely DMA burst intot main memory and update the CPU cache at the same time.
This is a new way of doing this which will greatly improve performance.

Example B)
Self modifying code:
Self modifying code used to always be a compatibility problem.
The 68k CPU design always was a Harvard architecture.
This means that the 68K design demand that you DO NOT ALTER your code in anyway. If a program does this then the CPU is NOT able to notice this and crashes are guaranteed. As bigger your instruction cache gets as more deadly any violations will be.
A program which was violating the Harvard architecture requirements could have been running fine on a 68K CPU with no or little instruction crash like the 68000 or 68020.
But running such a program on a CPU with a bigger cache like the 68040 or 68060 would result into crashes.

We realized that we can fully correct this behavior.
Our CPU design will "loose" the Harvard architecture requirements - and our instruction cache will snoop on memory writes and update itself.

The result is that we can create a CPU with a huge cache for best performance - but at the same time maintain the best possible of all the existing 68k CPUs to original 68000 games!

Fabian Nunez wrote:

Don't let this delay the release of the first version though... we're still on for summer 2008, yes? :)

The development boards will come out this summer.
The dev-boards will have SuperAGA chipset and an original 68060 CPU.
The onboard FPGA has plenty of free space and can be updated later at any time.

In fact the onboard FPGA has enough space to hold the SuperAGA chipset and more than one extra 68k-Softcore.

Cheers
Gunnar

I see what you mean. And this might be a good idea.

But we should not forget that the AMIGA will go with the Natami a very big step forward.

The Natami has buildin new 2D acceleration and new 3D features.
The SuperAGA is > 100 times faster than original AGA was.
The Natami will come with more memory than classic AMIGAs had,
and the CPUs will be many times faster than the fastest classic AMIGA.

The Natami will open a new performance world for AMIGA applications.
For many of these powerful applications the A3000 will be much to slow to run them. :-)

As the Natami will be very cheap - I doubt that anyone will use a old machine anymore as soon as the Natami comes out.

Do you agree with me?

I agree in principle, but you have to remember that >90% of people running "classic amigas" are using emulation (my "main" amiga these days is UAE running on the GP2X handheld console, I like playing Cannon Fodder on the bus).  I guess that one has to break with the past at some stage and not get tied down with backwards compatibility like a certain software company, but it's something that I suspect will get asked, so you might as well have made an informed decision whether you decide yes or no :)

What about that thing bill buck mentioned about the cell that could have several different architectures on one system ( and indeed toshiba is selling a laptop with x86 and cell ). Is that still up for consideration? We could have cell and x86 cpus all on one system, bridgeboard style. The natami would suite all the computing needs anyone could ever have, given that it has, ugh, uhm 3 or 4 pci-e ports to connect the boards to, and subsequently, for say a x86 system, graphics. quad core amd phenom bridgeboard anyone? 

Did you really read this thread?

You post is confusing me as the Natami will be 100% what you wants it to be:

Maybe I explained it here badly but:
- The Natami is the original AMIGA successor.
- SuperAGA is 100% AGA compatible but 100 times faster.
- SuperAGA provides all AGA features but adds great new features in a compatible way. (Truecolor, 16 Bit audio, more 2D and 3D power)
- The Soft68k that we think about is more compatible to 68000 software than the 68040 and 68060 CPUs ever were.
- I'm sure that we can make our Soft68k to be faster than the original 68060 ever was !
- I actually believe that our Soft68k core could be made faster than Freescales Coldfire V4.

- The Softcore gives us the flexibility to add new features to the 68k CPU.
- Our design will removes some of the 68k limitations already.
- I very much believe that our "Advanced 68K design" will enable current C-compiler as GCC to create faster programs.
- We do not Altivec in 68K yet: But adding something like SSE2 or Altivec to a Softcore is actually possible.

I want to make clear that a 200-400 Mhz 68K with added Altivec can not be a CELL Killer - this should be clear. But such a chip has in my opinion plenty CPU power for most tasks that I want to do.

Cheers

Fabian Nunez wrote:

@MikeB             It makes a huge amount of sense to do it.  If there's a 68K core in the FPGA:             1. There's no need to write and maintain a coldfire.library, and no unimplemented opcode emulation slowdown

You are absolutely right.
We came to the same conclusion instead putting work into the Coldfire-to-68k compatibility environment we could simple get the real deal running.  :-)

Fabian Nunez wrote:

2. There's no need to worry either about opcodes that behave differently but don't throw exceptions - 100% CPU compatibility (come to think of it, not 100%... the FPGA 68K probably won't be cycle exact.  But then again, because accelerators were quite popular, almost no programs should depend on that)

Cycle exact is never needed on AMIGA.
AMIGA != C64.
There was never something like cycle exact on AMIGA anyway.
Different AMIGA models used different speeds of ROM/memory.
So even an A600 was never 100% cycle exact to an A1000 or A2000 anyway.

A cycle CPU is never needed on AMIGA !
What is needed is a CPU that behavios compatible to the real 68K.
The beauty of the selfmade 68k is that be made more compatible to the 68000 than even the 68020 ever was.
Maximum speed and compatibility at the same time!

Fabian Nunez wrote:

3. Because of this, there won't be a need to sell NatAmis with a patched kickstart (which is probably enough of a legal grey area that it may be actually illegal in some countries)

I think legally this is not a problem. But you are fully correct its not needed anymore at all.

Fabian Nunez wrote:

4. The NatAmi becomes completely independent of Freescale's business needs.  If Freescale were to decide that too few ColdFireV5+NatAmi chips were being sold, that's it, end of story.  With the 68K in the FPGA, that won't happen.

You are absolutely correct.
Being completely independent has some real beauty here!
Having the design in your own hands will give you a number of advantages:

- You can fix some limitations of the 68K-family.
  A limit to fix would be the awareness of changes to the Instruction-Cache.  The 68k-family can not automaticly handle loaded code. You need to flush your cache after loading new programs from disk. If you don't do this your program could crash. Some old programs/games did not did this and this is reason no 1 why these prgrams did crash on newer Amigas.
  This is the first thing that I would improve.

  Another limitation is that some addressing modes can only be used in reading and not in writing. This limitation is could be removed as well. Having all addressing modes to be always available will help compilers like GCC to generate more optimal 68k code.

I think having everything under our control has plenty of advantages:

For what they wanted to achieve with the Coldfire - the Coldfire was excellent in its design!
15 years ago when the Coldfire was created, chip size was an expensive and very limiting factor.At that time, the decision to through some of the old 68K features over board to save size was very clever and allowed them to create a fast and very cost effective chip.

Today 15 years later, the world has changed - chip size got much cheaper. While the saved chip area by "loosing" 68k-features saved 15 year ago $100 - the same chip size it today only worth 50 cent.

Today the setup is different - and today you could make other design decisions.

Fabian Nunez wrote:

5. On top of that, you lose very few of the advantages to be gained by putting the NatAmi in a ColdFire V5.

You are absolutely right!

Fabian Nunez wrote:

I believe this is the smartest decision the NatAmi team's made so far.

LOL thanks :-)

Fabian Nunez wrote:

There's only one downside I can think of (besides the obvious fact that the CPU core will have to be written), and that's that Bill Buck won't be as interested in helping if Freescale is no longer involved.  It's not a big problem though, aCube could probably be persuaded to sell NatAmis the same way it's selling MiniMigs.  That would actually be a very good thing to happen, I think - they are passionate about the amiga, and have expertise in manufacturing and selling computers.

We appreciate any help - but I'm fully confident that the Natami design will be fully finished by us own our won in time.

Cheers

I agree. The more the reliance on proprietary technologies is reduced the brighter the future for the Natami. I would urge you to concentrate on releasing the dev board and work on the HDL-68k CPU later.

I know a 68000 CPU has already been rebuilt for the Minimig, does the Natami team intend on modifying this core or starting a new one?