View Single Post
Old 04 November 2015, 19:48   #99
Registered User
Join Date: Jan 2010
Location: Kansas
Posts: 873
Originally Posted by Samurai_Crow View Post
Beating an ASIC with an FPGA is difficult. I estimated that a 500-600 MHz core based on 68k would be enough to wipe the floor with my PPC 750FX at 800 MHz due to RISC core inefficiency associated with the Load/Store architecture. Since the PPC doesn't use opcode fusion like the Apollo core, the FPGA might catch up with lower clock speeds than even 400 MHz!
I agree that the Apollo core is potentially much stronger at single core integer performance than most old and low end RISC processors but how much is difficult to estimate.

1) Is the Apollo core in an FPGA or in a real ASIC?
2) Does the Apollo core have a good compiler and instruction scheduler?
3) What kind of caches and memory are used?
4) What kind of algorithms are used?

I believe an FPGA Apollo core could outperform, at the same clock speed, most Thumb 2 ARM processors (where power efficiency is more important than performance) in single core performance. PPC is generally stronger but ARM has been closing the gap with deeper pipelines, OoO and recently a new ISA. The G3 PPC processors are old, simple and power efficient shallow pipeline designs (limits clock speed) but do have some advanced features like reservation stations and large caches (needed for PPC performance). The Apollo core in FPGA could retire more integer instructions per cycle, would be considerably faster per cycle at multiply and would not suffer from RISC load/store bubbles but a good compiler with instruction scheduler is still imperative to take advantage of the 3 integer units and 3 op code fusion without OoO.

Originally Posted by Samurai_Crow View Post
Using a modular eASIC-style ASIC could get the speed up to what we need if the demand is high enough. Some obstacles are that the core has to be debugged first. Also, since the Apollo core drops some 68k functions that are not legal to use on the Amiga chipset systems, the chip would need to be an SoC with its AGA++ core integrated to make the expense worthwhile of doing the die layout. (The reason I think that is the case is because the Apollo core is only user-mode ISA compatible with 68k. There are other 68k systems that it won't work with.)
Some of the pseudo ASICs are affordable in small unit quantities but it is not clear how much of a performance advantage there would be. I have my doubts after reading up on some of them. A real ASIC Apollo/Amiga SoC is probably the way to go if it could be afforded but (one time) NRE costs would likely be $250,000-$1,000,000. This would probably require production of 10,000 to 100,000 units per year to make the per unit costs affordable and pay for the NRE costs in a reasonable amount of time. This is why I approached embedded companies for non-Amiga use sharing.

Originally Posted by Samurai_Crow View Post
IF that all happens, it'll be interesting to see how it stacks up against the PPC and more importantly, how well the AGA++ core can mop the floor with an older Radeon card. My MicroA1 has a Radeon 7000 chip on the motherboard and it isn't upgradable. (If the AGA++ graphics core can go far enough to compete with my sister's old Radeon X700, I'll probably ditch PPC for good! The PPC already can't keep up with my Core2 Duo-based Mac.)
Amiga FPGA graphics "mop the floor" compared to real AGA graphics but I doubt Amiga ASIC graphics would be much, if any, faster than your older Radeon graphics card. An Amiga ASIC production process would be older to hold the cost down and the Amiga technology is not optimized for high speeds. However, 2D performance has reached the point of diminishing returns and gains are barely noticeable. An Amiga 3D design would need to be developed or bought with either likely many years behind new commodity graphics cards. There would be a small advantage of using integrated graphics and graphics memory without going through a bus.

Last edited by matthey; 04 November 2015 at 19:53.
matthey is offline  
Page generated in 0.07714 seconds with 9 queries