Hammer Quote:

The real-world ARM Cortex A53 has clock speeds beyond 1.3 Ghz e.g. All Winner H6's ARM Cortex-A53 has 1.8 Ghz.

The Cortex-A53 can be found clocked up to ~2GHz @~10nm which is not impressive. It is used because it is small, cheap and relatively low power so usually isn't clocked up. There are better cores for performance where clocking up is more advantageous but more performance uses more power and generates more heat.

Hammer Quote:

68K is a Motorola product and the Commodore has no problems using 68K clones.

C= never considered using emulation of the 68k. Old low performance embedded 68k CPUs were fine because they were very cheap. They failed to use enough high performance 68k CPUs to improve economies of scale for the desktop in their pursuit to turn the Amiga into a C64 replacement. They likely considered a single chip 68k+AA+ SoC to be "feasible".

Commodore_Post_Bankruptcy.pdf Quote:

Low Cost - 68EC020 32 BIT CPU < $7 - CHIPSET Cost < $13 Single Chip with Integrated CPU feasible - 2x Performance - < $20

The first 68k Amiga SoC likely would have been based on a 68EC030@57MHz with AA+ chipset. Later they could have licensed the 68060 which would have been adequate all the way up to today with incremental and chip process improvements. If C= survived, a 3+ DMIPS/MHz in-order 68060 would still be perfect for SoCs and SBCs today.

Hammer Quote:

You haven't included R&D in the tape-out stage and wafer start cost for 68060's moderation. Economies of scale problems are real.

Sure, NRE costs are significant and need to be recouped by spreading out over the product life. Mass production is required but results in a product that is more competitive and cheaper which increases sales. There is risk involved with becoming more competitive where there is no risk with guaranteed failure from continued lack of competitive Amiga hardware. Even hundreds of thousands of THEA500 Mini units sold hasn't attracted developers because it uses noncompetitive emulation of the 68k Amiga.

Hammer Quote:

RPi has moved into Broadcom BCM2712's quad-core 64-bit ARM Cortex-A76 @ 2.4 Ghz.

The newer RPis use larger and more expensive OoO cores that generate much more heat requiring expensive chip process shrinks to reduce the heat, additional heat sinks and fans for cooling and power requirements are approaching the limits of a small SBC that may be better used for an upgraded GPU. The RISC-V VisionFive 2 SBC with in-order U74 cores and an Imagination BXE GPU has a better balanced of CPU and GPU performance and is a more practical low power SBC that does more with less.

VisionFive 2 RISC-V SBC - A Raspberry Pi Killer?
https://www.reddit.com/r/RISCV/comments/10m562c/gary_explains_visionfive_2_riscv_sbc_a_raspberry/?rdt=61635

Bruce Holt Quote:

Of course it is not a Raspberry Pi killer, and no one except Gary has ever suggested it might be. It is, however, by far the best price/performance RISC-V board you can buy at the moment, definitely better than a Pi 3 in almost everything (except SIMD), and close to a Pi 4 for normal users.

The RPi 3 has too weak of CPU and GPU. The RPi 4 CPU pretty much hits the sweet spot for a low power SBC but the GPU is weak. The RPi 5 is pushing the limits of what can be considered a practical SBC due to heat and total system cost while the GPU remains relatively weak compared to the CPU performance.

I don't expect the VisionFive 2 SBC to start out selling any RPi hardware. The hardware is impressive for a newcomer but RISC-V software is lacking. The 68k has software, including a huge library of retro games which are hot right now, but lacks hardware.

CBM prefered to not compete with Apple (and others) for the “high-end� 68k chips at the time, supplies were limited. With 68060 Motorola was primarily targeting the embedded/telecom industry with their MVME boards.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

kolla Quote:

CBM prefered to not compete with Apple (and others) for the “high-end� 68k chips at the time, supplies were limited. With 68060 Motorola was primarily targeting the embedded/telecom industry with their MVME boards.

Mostly true but in free markets supply tends to adjust to demand if possible. C= giving up the high margin high end 68k market may have had something to do with their poor reputation in the large and lucrative U.S. market and their poor marketing both of which together had negative synergies.

I believe the 68060 was originally intended to target more than the high end embedded market which wasn't large back then. When design started, I believe the Motorola 68060 design team had every intention for the 68060 to compete against the Pentium. When the 68060@50MHz was released in April of 1994, Motorola had plans for a 68060@66MHz in 4Q94 according to the April 1994 Microprocessor Report.

Motorola Introduces Heir to 68000 Line (April 1994 Microprocessor Report)
https://websrv.cecs.uci.edu/~papers/mpr/MPR/ARTICLES/080502.pdf

Along with perhaps a 6 months minor upgrade cycle, a 68060+ was mentioned in the same paper with "undisclosed architectural enhancements that increase performance 20-30% independent of clock frequency". This "undisclosed architectural enhancement" is most likely a doubling of the caches from 8kiB I+D to 16kiB I+D considering all the work they did to strip the 68060 so it would be possible unlike the fat Pentium P5. With double the caches, better code density and a deeper pipeline to allow higher clock speeds, the 68060+ was perfectly planned to be a Pentium killer. There were a few development delays and the workstation and desktop markets abandoned the 68k leaving only the embedded market so management killed the Pentium killer and invested in PPC which they had already committed to after the AIM Alliance in 1991. The decision made some sense as choosing one path and using PPC everywhere improves economies of scale but the pencil pushers didn't realize how good the 68060 design was, how important the 68k was for owning the embedded market which they surrendered with the embedded switch to PPC and how disappointing PPC was in general. They wouldn't clock up the higher performance in-order 68060 which made the weaker OoO PPC 603 look bad. Doubling the PPC 603 caches and a chip die shrink to the PPC 603e improved the situation but the 68060 could also have doubled the caches, has much better instruction cache efficiency due to better code density and the 8 stage pipeline could clock higher than the 603(e) 4 stage pipeline. Doubling the caches again to 32kiB I+D reduced the max clock speed for the high end PPC 604 to PPC 604e around that time so more caches were not a good option until silicon space became cheap enough for a L2 cache, which gave PPC a 2nd wind with the PPC G3. PPC developers were slow to give up on their shallow pipelines as they allowed for smaller cheaper simpler cores but they predictably had trouble clocking up their CPUs gaining a poor reputation from customers like Apple.

Last edited by matthey on 23-Apr-2024 at 01:52 AM.
Last edited by matthey on 23-Apr-2024 at 01:52 AM.