Oh, the gross picture is simple - it's none different from the pictures in the "bible" and elsewhere - an address sequencer, opcode decoder, ALU, internal RAM and a handful of SFRs and, later, peripherals.

And, of course, I am aware of the groups of instructions - that's exactly why I was doing the cheatsheets a few years ago.

Also, I know I am supposed to add certain elements - such as the accumulator or other SFRs - and I roughly knew how would I "plug" them in beforehand, I just did not declare that out aloud. Note for example, that I had an adder in the program counter path even at the very first stage, where a simple counter would suffice, as I knew that I will need it for the sjmp/conditional jumps and the MOVCs.

But the devil is in the details. I can't see how could I draw a more detailed picture until I try (and retry). Let me draw a parallel with your FPGA-work: you certainly had the gross picture of the counter in your head even before you wrote the first Verilog line - yet it took you two or three attempts to find out some of the vital hows and whys.


What I am doing "behind the curtain" is a set of "timing" drawings, where I try to figure out (in no formal way) how can I steer the data for the individual instructions so that they will arrive where they are supposed to, in time (I don't know if anybody would be interested in this sort of "documentation" - as I said, they don't follow any established form, and are hand-drawn). As I am working with a more intuitive then real data for the individual delays, this "model" might be way off any possible real implementation; but I can't verify that at the moment.


JW