Can FPGA 060 run more than 100 Mhz?

[AmigaClassicRule]

Sorry I opened this discussion. If this was youtube and by the amount of hits I got from opening this topic I would have being rich by now :-P.

[billt]

Lets not. If you can't guarantee that every piece of software that works on 68060 will work on this and vice versa then it's pointless. The actual implementation is irrelevant to that, so you can debate that until the heat death of the universe if you want, just as long as the ISA is exactly the same.
 
You seem intent on wasting everybody's time, so I'm out.

I think that's a bit rash, it's a very technical topic and deserves some technical discussion and debating ideas. Just because I think I'm right and you thing I'm wrong doesn't mean there aren't good things to be said in the middle somewhere for both of us.

If all you want is exactly 68060 instruction set, then either add missing instructions to tg68 or something, maybe wait for Suska's 68k30 and start from there, and make it fit an 060 socket. If that's good enough for you, then you and like-minded people can work on that as one project.

Anyone interested in a more advanced design can work on that as another project.

[ElPolloDiabl]

Back further 100% compatibility was covered. Some people would prefer a cut down model to improve speed. If you have a cut down model, just put down 95% compatible.
Being a retail product they will aim for 100% compatibility.

[A6000]

Why is 100% compatibility so important?
The A1200 could not run some A500 software, this was seen as a small price to pay for a better Amiga, and people expected the incompatible software would be eclipsed by new software that took advantage of the more powerful hardware.
Whilst there are fewer people to (re)write the software now, it is still beneficial to sacrifice some compatibility for a processor that is better in some way or simply available.
At this stage in the Amigas' life we should start learning to program it, as other retro computer users are learning to program their machines, it is the only way new software is going to be written for these machines.

[FrenchShark]

Hello,
here are my thoughts about the subject.
First, I think we must have a partially micro-coded CPU instead of a fully hard-wired one.
I have done that with the J68 68000 core and I can achieve a higher clock rate (90 MHz on a Cyclone III, 300 MHz on a Stratix II).
The IPC is quite bad (90 MHz J68 is equivalent to a 30 MHz 68000) but this is mostly due to the instruction decoding not done in parallel and the lack of an address ALU for the EA computation.
Pipelining is good but create a lot of hazards in the pipeline.
Another approach is to create a barrel processor running at 200 MHz with 4 threads.
Then, we need a SMP Exec...
Regards,
Frederic

[Iggy]

Hello,
here are my thoughts about the subject.
First, I think we must have a partially micro-coded CPU instead of a fully hard-wired one.
I have done that with the J68 68000 core and I can achieve a higher clock rate (90 MHz on a Cyclone III, 300 MHz on a Stratix II).
The IPC is quite bad (90 MHz J68 is equivalent to a 30 MHz 68000) but this is mostly due to the instruction decoding not done in parallel and the lack of an address ALU for the EA computation.
Pipelining is good but create a lot of hazards in the pipeline.
Another approach is to create a barrel processor running at 200 MHz with 4 threads.
Then, we need a SMP Exec...
Regards,
Frederic

I've always wondered what a more capable FPGA could do, but the Stratix II is a little too high end for my wallet. Plus its got a lot of capabilities that seem wasted on a 68K emulation project (like the DSPs).
If you REALLY wanted to get extreme, how about Stratix III L?

[FrenchShark]

I've always wondered what a more capable FPGA could do, but the Stratix II is a little too high end for my wallet. Plus its got a lot of capabilities that seem wasted on a 68K emulation project (like the DSPs).
If you REALLY wanted to get extreme, how about Stratix III L?

You can get preatty cheap Stratix I/II NIOS evaluation boards out of ebay.
I have 3 of them : one 1S40, one 2S60ES and one 2S60 ROHS. The last one I got only cost me around 40 bucks (regular price 6 years ago was $1000).
With a friend of mine, we did the cloning of the Atari Jaguar using this board.
Today, the Cyclone V must be as powerful as the Stratis II (ALM architecture with 6-input LUTs).

Price/performance wise, the Lattice ECP3 is not bad either. Plus, it has a DSP block with a dynamic ALU mode that can be very useful in CPU design.

Regards,
Frederic

[Iggy]

You can get preatty cheap Stratix I/II NIOS evaluation boards out of ebay.
I have 3 of them : one 1S40, one 2S60ES and one 2S60 ROHS. The last one I got only cost me around 40 bucks (regular price 6 years ago was $1000).
With a friend of mine, we did the cloning of the Atari Jaguar using this board.
Today, the Cyclone V must be as powerful as the Stratis II (ALM architecture with 6-input LUTs).

Price/performance wise, the Lattice ECP3 is not bad either. Plus, it has a DSP block with a dynamic ALU mode that can be very useful in CPU design.

Regards,
Frederic

Thanks, I have been focused on the Cyclone series as I was under the impression that it was the best value.
I'll have to check those out as a Stratix II evaluation board could be quite useful.

[ElPolloDiabl]

That IPC seems pretty normal for most CPUs. Only the 060 and early PowerPC line got 1 instruction per clock cycle.
How does cache affect performance?

[psxphill]

Whilst there are fewer people to (re)write the software now, it is still beneficial to sacrifice some compatibility for a processor that is better in some way or simply available.

If you start with that mindset you actually just waste your time debating what compatibility you're willing to sacrifice. With the structure of 100% compatibility you have a non moving target that you will reach quicker and likely come up with more novel ways of solving.
 
You instantly sidestep second system effect http://en.wikipedia.org/wiki/Second-system_effect, because you're not adding any new features.
 
You also waste less time at the other end having to patch up existing software. Most software has already been patched up to work on the 68060.
 
It doesn't mean you can't have a novel method for decoding/despatching instructions etc. Just that whatever the end result is performs identically for all software that is out there (not just Amiga but Mac or Atari and anything that might be using illegal instruction traps for their own purposes).
 
Anything else is wasted effort. You're not going to be producing the next big CPU for embedded markets, that ship sailed years ago.

[A6000]

If you start with that mindset you actually just waste your time debating what compatibility you're willing to sacrifice. With the structure of 100% compatibility you have a non moving target that you will reach quicker and likely come up with more novel ways of solving.
 
You instantly sidestep second system effect http://en.wikipedia.org/wiki/Second-system_effect, because you're not adding any new features.
 
You also waste less time at the other end having to patch up existing software. Most software has already been patched up to work on the 68060.
 
It doesn't mean you can't have a novel method for decoding/despatching instructions etc. Just that whatever the end result is performs identically for all software that is out there (not just Amiga but Mac or Atari and anything that might be using illegal instruction traps for their own purposes).
 
Anything else is wasted effort. You're not going to be producing the next big CPU for embedded markets, that ship sailed years ago.

Compatible with what?
68000, 68020, 68030, 68030+68882, 68040, 68060 or PPC, if you want compatibility with macs they are now using intel processors.
Does faster execution speed break compatibility?

[FrenchShark]

Compatible with what?
68000, 68020, 68030, 68030+68882, 68040, 68060 or PPC, if you want compatibility with macs they are now using intel processors.
Does faster execution speed break compatibility?

Cache breaks compatibility but if you go with unified cache with snooping, self modifying code is even possible (to a certain extent : you have to take into account the instruction prefetch and the pipeline depth).
If the Amiga chipset is implemented inside the FPGA, you can even snoop DMAs and keep cache coherency over Chip RAM.
Due to the way Exec detects CPU, you can have a core with 68000 exception frame and '020 user instructions (long branches, bitfields, 64-bit MUL/DIV and extra EAs).
Regards,
Frederic

[Iggy]

@ Frederic,

I'm having trouble locating Stratix II based developments boards (and most commonly available Cyclone IV boards are crap).
Stratix II and Cyclone III chips are still quite available (at decent prices for the larger chips).
I like the performance benefits of what you have suggested, but it seems like Altera wants to push higher end apps into the Stratix III or higher (and I am not that impressed with the Cyclone V value vs performance ratio).

So, where did you find the dev. boards you have mentioned?

[psxphill]

Compatible with what?
68000, 68020, 68030, 68030+68882, 68040, 68060 or PPC

It's a 060 thread and I have mentioned 68060 repeatedly.
 
"Most software has already been patched up to work on the 68060."
 

if you want compatibility with macs they are now using intel processors.

How would you like me to differentiate between the different mac models in the future, so that in an 060 thread when all the conversation is about 060 you won't get confused that we might be talking about a PPC/X86/X64.
 

Does faster execution speed break compatibility?

It shouldn't, but it would be something that would only turn up during testing.
 

Cache breaks compatibility but if you go with unified cache with snooping, self modifying code is even possible (to a certain extent : you have to take into account the instruction prefetch and the pipeline depth).

Adding snooping to detect self modifying code will make it incompatible. How are you going to run software that overwrites itself in ram but keeps executing from cache?
 

Due to the way Exec detects CPU, you can have a core with 68000 exception frame and '020 user instructions (long branches, bitfields, 64-bit MUL/DIV and extra EAs).

If you think that is acceptable to base a design on that knowledge then I hope you're never allowed to influence an 060 in FPGA design.

[FrenchShark]

@ Frederic,

I'm having trouble locating Stratix II based developments boards (and most commonly available Cyclone IV boards are crap).
Stratix II and Cyclone III chips are still quite available (at decent prices for the larger chips).
I like the performance benefits of what you have suggested, but it seems like Altera wants to push higher end apps into the Stratix III or higher (and I am not that impressed with the Cyclone V value vs performance ratio).

So, where did you find the dev. boards you have mentioned?

On ebay, you have to check regularly.
Right now there is a Stratix III board for a quite decent price (given the performance of the chip):
http://www.ebay.fr/itm/Altera-Stratix-III-EP3SL150F1152-FPGA-Development-Board-/301153136861?pt=LH_DefaultDomain_0&hash=item461e2030dd.
But keep in mind that you need a full version of Quartus II to run synthesis for this chip.
It looks like you are right about the Cyclone V performance : even with the ALM, it is slower than the III.
This document proves it : http://www.altera.com/literature/ds/ds_nios2_perf.pdf
Regards,
Frederic

[matthey]

Cache breaks compatibility but if you go with unified cache with snooping, self modifying code is even possible (to a certain extent : you have to take into account the instruction prefetch and the pipeline depth).

Self-modifying code should work with snooping but would be slow. The caches only need to be invalidated if using writethrough caches (writethrough caches are probably not much slower than copyback caches with the fast memory and high memory bandwidth). It should be possible to have self-modifying code and cache compatibility better than the 68040 or 68060 with much larger cache sizes.

If the Amiga chipset is implemented inside the FPGA, you can even snoop DMAs and keep cache coherency over Chip RAM.

Yea, there are several issues with the Amiga chipset that should be solvable with the chipset and CPU in the same fpga. Maybe even multi-threading/SMD would work with a little trickery. It's easy to duplicate an fpga core.

Due to the way Exec detects CPU, you can have a core with 68000 exception frame and '020 user instructions (long branches, bitfields, 64-bit MUL/DIV and extra EAs).

This is basically the way the Phoenix core in the Vampire will work although some of the 68020 features don't fit in the Cyclone II of the Vampire. There is no 64 bit MUL/DIV (although 32 bit longword versions were added) and it's missing most if not all bitfield instructions and most if not all double indirect addressing modes. The specs may change.

By the way, the IPC of Phoenix will be limited by only 1 integer pipe but should be close to 1. Simulation has showed that much more is possible with more pipes (each pipe can be stronger than the 68060). I don't think there is any way that more than 3 integer pipes would be useful. The instruction fetch becomes large, there are too many memory accesses between 3 instructions and the CPU clock speed slows down some with each pipe. Even 3 pipes may not be an advantage although a few tricks may make this possible without OoO execution .