Electrical – CPU-Multiplier Overclocking causing (silent) data corruption

The external data-bus width doesn't always agree with the processor's internal structure. A well-known example is the old Intel 8088 processor, which was identical to the 16-bit 8086 internally, but had an 8-bit external bus.

Databus width is not a real indicator of the processor's power, though a less wide bus may affect data throughput. The actual power of a processor is determined by the CPU's ALU, for Arithmetic and Logic Unit. 8-bit microcontrollers will have 8-bit ALUs which can process data in the range 0..255. That's enough for text processing: the ASCII character table only needs 7 bits. The ALU can do some basic arithmetic, but for larger numbers you'll need software help. If you want to add 100500 + 120760 then the 8-bit ALU can't do that directly, not even a 16-bit ALU can. So the compiler will split numbers to do separate calculations on the parts, and recombine the result later.

Suppose you have a decimal ALU, which can process numbers up to 3 decimal digits. The compiler will split the 100500 in 100 and 500, and the 120760 into 120 and 760. The CPU can calculate 500 + 760 = 260, plus an overflow of 1. It takes the overflow digit and add that to the 100 + 120, so that the sum is 221. It then recombines the two parts so that you get the final result 221260. This way you can do anything. The three digits were no objection for processing 6 digits numbers, and you can write algorithms for processing 10-digit number or more. Of course the calculation will take longer than with an ALU which can do 10-digit calculations natively, but it can be done.

Any computer can simulate any other computer.

The humble 8-bit processor can do exactly what a supercomputer can, given the necessary resources, and the time. Lots of time :-).

A concrete example are arbitrary precision calculators. Most (software) calculators have something like 15 decimal digits precision; if numbers have more significant digits it will round them and possible switch to mantissa + exponent form to store and process them. But arbitrary precision expand on the example calculation I gave earlier, and they allow to multiply

\$ 44402958666307977706468954613 \times 595247981199845571008922762709 \$

for example, two numbers (they're both prime) which would need a wider databus than my PC's 64-bit. Extreme example: Mathematica gives you \$\pi\$ to 100000 digits in 1/10th of a second. Calculating \$e^{\pi \sqrt{163}}\$ \$^{(1)}\$ to 100000 digits takes about half a second. So, while you would expect working with data wider than the databus to be taxing, it's often not really a problem. For a PC running at 3 GHz this may not be surprising, but microcontrollers get faster as well: an ARM Cortex-M3 may run at speeds greater than 100 MHz, and for the same money you get a 32-bits bus too.

\$^{(1)}\$ About 262537412640768743.99999999999925007259, and it's not a coincidence that it's nearly an integer!

Not necessarily. Bonus points for knowing that an input to an FF has as setup and hold time specification, by the way.

But for many designs of FF the hold time can be 0 ns, i.e. you don't need to hold the data for ANY time after the clock edge. (When designing the FF, you can guarantee this - just make sure you use slower transistors or longer wires on the input, and faster on the clock!)

Now the clock latches the data, but that process takes some time - called propagation delay, or clock-output delay - and then the wire to the next FF adds some delay of its own. So the next FF doesn't see its input changing until AFTER this time, certainly greater than 0 ns, so this is safe. (If it isn't greater than the actual hold time you ARE in trouble!)

The setup time is less important at this stage; since the previous FF output changes just after the clock edge, it has almost a whole cycle to get here. Calculate clock cycle time - clock-output delay - wire delay - setup time and if the number is positive, that's safe too.

Setup time matters when you start adding gates or long wires between FFs; these add more delay. So when that sum becomes zero, the clock is too fast!

(There is another aspect; clock pulses arrive at different FFs at different times; for an accurate calculation you need to account for this "clock skew" in both setup and hold time calculations).

So you're not wrong; these are real issues but they have solutions. And chip design involves a LOT of these calculations (mostly automated by the tools, in FPGA design) - called "static timing analysis".