Can FPGA 060 run more than 100 Mhz?

[matthey]

I am just curious...can someone make an Amiga FPGA 060 that can run at 233 Mhz? Is it possible? How expensive would it be to make it?

I think it's possible. There are some very expensive fpgas costing thousands of dollars that should be able to do it. An Altera Stratix (high end) probably could and maybe an Arria (mid range) which is approaching affordable (hundreds to thousands of dollars). A CPU in a (low end) Cyclone III-V costing ~$50-$500 would probably not exceed 150-200MHz but I think it may be able to come close to the performance of a 233MHz 68060. Most fpgas have plenty of memory bandwidth but are limited in clock speeds. The trick is using parallel operations to take advantage of the memory bandwidth. I believe it's possible for an fpga CPU to substantially exceed the performance per MHz of a 68060. The memory bandwidth can be better, more parallel pipes/operations may be possible, bigger caches are possible, a link stack helps and ISA improvements should be good. Some things are slower in an fpga so they would need to change from the way the 68060 does them in order to have good speed. All of this would require a CPU more advanced than the TG68 and would take some time and know how to complete.

[matthey]

Personally I'd be very happy too see an FPGA card that offered similar CPU performance as my 80Mhz Blizzard (100 MIPS) while remaining 110% compatible (add back the dropped instructions). It would of course be nice to see a card with even more performance but those extra MIPS wouldn't really get much use.

Adding the extra instructions back isn't important if the emulation library is loaded before booting and it's upgradeable. The missing 64 bit MUL and DIV instructions should be added back as they are in modern hardware. It was a mistake to take them out as compilers like GCC were already making good use of 64 bit MUL to change immediate divisions into multiplies using invert and multiply with large savings. MOVEP was used by some old games (Sierra for example) but the encoding is bad (it was a kludge implemented for 8 bit support). Trapping it like the 68060 makes sense. Most of the other instructions the 68060 took out of hardware were rarely ever used on the Amiga and don't make sense to add them back.

Larger caches would normally be a problem but a modern fpga CPU would probably use writethrough caching for simplicity instead of copyback caching. 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.

I think price is more important than performance anyway, it would be awesome to see a new 060 'like' FPGA card offered for less than $200.

That price may be possible (in U.S. or Aussie dollars) but most people would want more than a bare bones fpga with faster CPU. At least 64MB of memory is appropriate. Some kind of I/O HD equivalent avoids a bottleneck and SD or CF is pretty cheap. USB and/or ethernet is nice also but it all adds to the price.

The other thing to keep in mind is that because the rest of the Classic hardware is so slow (include the bus), there really isn't much point going above 130 MIPS (100Mhz Apollo).

Come to think of it, only DosBox AGA and NetSurf AGA need more than 130 MIPS!

The ECS/AGA gfx become a bottleneck and then it makes sense to add gfx on the accelerator and/or move to a new stand alone board or motherboard replacement. A faster CPU and gfx will allow you to port more modern games and use DOSBox for older games instead of porting them .

[matthey]

250MHz FPGA chips have been available for quite a while now. That's the easy part... the hard part is reverse engineering the 060 and programming the FPGA to correctly emulate an 060 under a fairly large number of different operating conditions.

The internal clock speed of the fpga is not the same as the speed an fpga CPU will run. It will be less even with a deep pipeline.

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.

Handling more in hardware without an exception shouldn't cause a problem. The way exceptions are handled on a 68k is similar although some 68k processors generate different exceptions and the stack frames used by different 68k processors are different. A new fpga CPU would probably be enough different that some changes and incompatibilities would be necessary in Supervisor mode like the 68060 was over the 68040. 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?

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

[matthey]

matt, its been few weeks now that you said apollo core was going to be tested on vampire. no news from that front?

Gunnar said that the Phoenix core is complete (all units) as of April 16. It required significant downsizing from the Apollo which took time. Testing is taking place in simulation. There was a bring-up party (in the Vampire) planned and then delayed due to scheduling problems. I don't know if they are waiting to get together or what. I don't think the Phoenix core is working in the Vampire yet but I believe they are close. Some bugs may need to be fixed before AmigaOS works. All I can say is be patient. These guys are working in their free time. That's part of the problem with Amiga projects.

[matthey]

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.

Snooping with writethrough caches would be more Amiga compatible. Many early Amiga programs didn't flush the caches because the caches were small enough that there was no problem (not so with larger caches) or didn't flush the cash at all. This should always work properly. It's also more 68060 compatible with larger caches because the caches don't have to be manually or properly flushed and larger caches are possible with no problems that I am aware of. Your Playstation example should not happen with snooping and writethrough caches. Writing over existing code will replace it with the new code. No flushing is needing except for code that is already in the CPU pipeline. No dirty caches or inconsistency between caches and memory is otherwise possible.

i thought igor stepped down for the time being, so this is the project on part of gunnar (and whom else? submicron jens?) i take it. no wonder they still do simulation, but do they have vampire hardware at disposal? who will provide hardware instead of majsta of all goes well? kipper or some other subcontractor?

well im not impatient, i dont have a 600 anymore so practically its all the same to me. but after some years of bold claims what concerns natami core there should be something to show off in the end;)

Majsta is back to working on the Amiga with the help of the Apollo Team . He is planning to create a new Amiga accelerator with a much larger Altera fpga for the full Apollo. I'd rather not give any specifics yet as they may change.

The core fpga programmers are Gunnar von Boehn, Jens Künzer and Christophe Hoehne who have all been active recently. Igor Majstorovic (majsta) has been fairly active recently also. I am the most active non-fpga/non-VHDL programmer and have helped with 68k statistics and ISA/encoding development.