AVR Freaks

Mmmmm! Dooooh!

I’d suggest the basis for understanding processor design is the ‘finite state machine”. This is the basis for the CU (control unit) that pulls all the levers to make things happen. So to understand processor operation/design you need to fully understand the concept and implementation of a finite state machine.
As the others have mentioned, there’s a few secrets that are in the AVR that Atmel don’t quite explain. How the multiplier works is one, another is how it reads and writes the registers in one clock is another. One can only assume that they synthesize extra clocks or delays to make it happen. One thing to remember is everything in hardware takes a finite amount of time.

In terms of processor design and implementation, the 6502 has had an enormous amount of reverse engineering done on it. It might be worthwhile starting there and relating that knowlege back to the AVR. Other avenues might be looking at the design and implementation of old processors like the pdp8 and ibm1401.

That was not the book I used ! but I don't know where my VLSI books are.(it was in 86-88)

For one project we used solo1000, (that was it was a university product later I have seen solo1400 for sale).

Back to the AVR

There are two different "main" version of the core.

The original version where I assume that the registers are placed on the memory bus.

And the xmega design (that newer tiny's also use), where they (I assume) are placed in the core logic (or an internal 2. bus). 

Benefit LD can be 1 clk, but the registers aren't memory mapped (some data sheets still seem to have cut and paste errors like they don't, and now it even seem that they try to hide memory mapping on the older chips!)

I am not convinced.  You might want to go and look at the data sheet for a "plain" ALU like the 74181 (?) - the operations typically include "none."

So I picture the AVR core as having the ALU with a couple of "source operand" buses, a "result destination", and an "operation code", all set up by the control unit.

An "ADD r3, r1" instruction causes the old contents of r1 and r3 to be placed on the source operand bus, sets up the ALU to do the add, and then stores the result in r3.

But the key thing to note with this theory is that a "MOV r3, r1" instruction STILL USES THE ALU.  It just sets the the "operation" to "source operand B, unchanged."  (give two bits A and B, "A" and "B" are both valid results of "logical operations.")  (or, sometimes, "mov" might be "add 0")

If this model holds true, them the multiplier is a separate bit of hardware that "taps" some of those buses, and "MUL r5,r6" causes the control logic to tell the multiplier to start multiply the values from the source operands, and then (on the second cycle?) works like an IN or LD instruction to R0/R1  (or maybe it gets the first half of the result in a the first cycle, and only needs the second cycle to store to the second register.)

This is all just guessing, of course.  But you see this happen on other CPU designs, where extra "functional units" (not the ALU itself) get tacked on in the various data paths, as long as the control logic can figure out somewhere to get bits to control it.   Multiply units, divide units, barrel shifters...  Not to mention designers getting creative with the instruction set ("increment is adding 0 with a carry-in!", or see the "constant generator" on MSP430.  Multiply&add instructions.   Or "we have XOR in the ALU, and a separate shifter, so we could combine them into a CRC-assist instruction!")  Getting carried away with this sort of thing in microcode (where you can more-or-less generate as many new control bits as you want) was one of the things that lead to RISC...

Right.  The difference between most RISC processors (ARM 32bit, MIPS, PPC, and SPARC, anyway) and earlier machines is that the instruction usually contains the destination register separately, while on (AVR, 68k, x86, PDP11) the destination is always also one of the source registers.  Things like that cause lightbulbs to go off in my head: "aha; so THAT'S how this thing works."  (also, the time spent trying to write microcode for a bitslice.)

Maybe they added a 16 bit data path between the registers. Couldn't they have done the same to the program counter, so that ijmp would only take one cycle?

edit: I mean, ijmp is "movw PC, Z".

Just to make it clear, even if the AVR make one instruction pr clk, it will use both edges of the clk, so the internal logic actually the 2 "clocks". 

No they ran out of instructions!

or have a mode where the H flag (rarely used )  in SFR is used as a 16 bit flag so 

ADD R26, R10

will behave as :

ADD R26, R10

ADC R27, R11

Or something like that

because of old code you can't recycle opcodes, but you add features as long it boot compatible

same why did they make a NOP instruction, something like mov r0,r0 would have been fine (as I remember there are 256 nop instructions or perhaps they are used now)

This remind me of a 4 bit controller (SAM47) I have used, there are something like 48 instructions that isn't used, and those can be programmed as combinations

of any (almost) two instructions, that could really compress the code size, (which also improve the reach of jumps etc. )