I'm not at all convinced it's beneficial to expend time and resources on grying to make an old 8-bit MCU work like a more evolved architecture. Perhaps, but with a little more effort put into the ALU and program counter, the thing might just generally speed up by another 10%. Branch prediction wouldn't increase the overall performance by that much would it?

I'll take a look at the T51 version you worked up and see where it might benefit. This may take some time, however. I find it interesting that you moved from the original author's optimized rate of 16 MHz to 80 MHz. That's where I'll probably spend a bit of time.

I've been looking at the 6502 architecture for a small-but-mighty MCU core for FPGA use. The reason is that, when the 6502 came out, it bought market share by costing about 25% of what competing CPU's cost. It turns out that was a simple silicon-by-the pound matter, however, since the chip was about 25% the size of the comparable MC6802.

One reason, of course, IMHO, is that the CPU is designed with transparent latches rather than clocked registers, which means three gates rather than six (or fourteen, if you believe XILINX' interpretation of what a D-flipflop is) and because they seem to have used the ALU to perform address arithmetic as well as data arithmetic. This allowed a very complex ALU to be used, thereby saving the gates needed for long synchronous counters. They also were said to have built the internal memory (registers) using dynamic cells, which saved a few transistors as well, but that's not an option we have in FPGA technology.

There's also the matter of the decimal arithmetic operations when the ALU is in decimal mode. I think one can easily implement that by maintaining a separate set of registers, the content of which is always kept decimal adjusted, thereby making it quick enough to allow the arithmetic to take place as fast in decimal mode as in binary.

I figure that if this core bought such a market share with its small size, it should be equally stingy with FPGA resources, allowing for a smaller array. That, in turn, will allow more resources to be dedicated to internal memory and specialized I/O.

Back in the late '70's, the 6502's were fast enough to "blow the doors off" the competing CPU's, with the possible exception of the IIL 8X300, which was a lot more trouble and expense, and was fast only because, like the GI PIC16 and the 804x and 805x it used a Harvard architecture but much faster than its MOS competitors.

RE