Can FPGA 060 run more than 100 Mhz?

[psxphill]

Firstly, it's not about creating an FPGA 68060, it's about creating a compatible implementation of the 68060 ISA (IIRC the 68020 ISA is a better target in terms of instructions to implement)

The advantage of going for the 68060 ISA is that Motorola removed some instructions that aren't used much, so you have work to do. You can make use of the effort people have made to make most/all software run on an 060

The 68060 MMU is simpler than the MMU used with the 68020 too.

[psxphill]

It can do bus snooping for old programs that didn't properly flush the caches or used self modifying caches. This is potentially more compatible for caching than a 68040 or 68060.

It's likely that disabling the cache will be fine for those, the problem of old games has been solved already for the real 68060.
 
Any software that people write now needs to run on a 68060 as well, so really there is no benefit in deviating from the published specification. If people want to wave their dicks at Motorola at how great a cpu they have designed, then it would be really great if they could do that after creating a 100% compatible 68060.

[psxphill]

while remaining 110% compatible (add back the dropped instructions).

You can't be 110% compatible, if you deviate then you're less than 100% compatible.
 
Unless all exceptions are generated the same as the 68060 (unimplemented instruction etc) then it's not compatible.

[psxphill]

Is it better to create a 68060 "copy" that has a limited future or an fpga CPU that can be further developed, improved in performance and possibly adopted for embedded applications as well as retro use?

It is better to create a 68060 "copy" that has a guaranteed future for retro use because it is the only accurate one.
 
People using softcores for embedded use don't have any emotional attachment so will go with whatever is the best/cheapest/etc. Starting with a 35 year old ISA is not going to help. Any traction you get today could be lost tomorrow & you're left with something that fits no purpose.
 
So I will rewrite your loaded question:
 
Is it better to create a 68060 "copy" that will be used in Amiga/Mac/AtariST fgpa for many years to come or an fpga CPU that will get abandoned when it can't keep up with other designs that aren't limited to a 1978 ISA?
 
Or do both, but create the 68060 "copy" first because that is where it will get the most use.

[psxphill]

I was just struggling to think of something else for 68k that could make use of more that 130 MIPS

First person shooters, PCTask/PCx?
 
There are probably some wild demos that could benefit as well, which usually only run full speed on WinUAE.

[psxphill]

We might today want to reconsider certain decisions

I'm sure someday someone will figure out that every time that happens the project dies, then we can finally have a 68060 cpu/fpu/mmu in an fpga.
 
Once it's done and open source then everyone can discuss whether it's worth making any changes, without using the barrier to entry as a way of keeping control.

[psxphill]

Let's consider tg68 or 68x00 cores as the "first time through" and not waste anyone's time doing that equivalent again, just to trash it and start over for the "real" design with the more complicated things later.

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.

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

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

[psxphill]

It should be possible to have self-modifying code and cache compatibility better than the 68040 or 68060 with much larger cache sizes.

It can't be better compatibility if it actually ends up running the code that was written from ram that the 68060 wouldn't, if it's different then it will always be less compatible.
 
For example on the playstation there is code that wipes itself out of ram and keeps running from the cache. Snooping would make that fail.

[psxphill]

Remember, I have an email from the manufacturer stating there is no such thing as an FE133.

I'm sure the person who emailed couldn't find any evidence of the FE133.
 
That is rather irrelevant though.