Hi Ricahrd,

Take all the time you need :)

The player's roster is real simple. Jan started all this a few months ago with his plan to model an 8051 in C. If I recall correctly, he got his program to the point where it would fetch instructions and execute a few different jumps and maybe the NOP or something similar. He also published a few hand-drawn diagrams on his website before he got occupied with other things and had to abandon his project, at least temporarily.

Subsequently, I got interested in doing the same thing, only in Verilog so I could actually implement the result on my FPGA eval board. I have been thinking about it for a few weeks now, but didn't publish anything or start talking about it on this forum until just last week. So far, all of my charts and diagrams are all contained in this PDF file.

To my way of thinking, I have in fact taken a top down approach to this. Intel's description of the 8051 instruction set is the "requirements document", if you will, along with a few unstated goals such as "I want to strike a happy balance between simple and fast," and "I don't care if my instruction timings match Intel's," and "I don't want to mess with an interface to external memory devices."

The very top level design exist only in the form of rough, back-of-the-envelope sketches, which I have not shared because they are quite cryptic and would probably prove illegible to anyone but me. I published the first refinement of those rough sketches last week, showing the major data paths along with a detailed, clock-by-clock description of how each and every instruction will work. The block diagrams are the "what", and the instruction descriptions are the "how".

That exercise proved to me that I had all the hardware I needed, but left out lower level detail about the internal memory, the SFRs, and the ALU. Based on our discussions here last week, a day or two ago I added a diagram that details the internal memory and the SFRs.

The ALU is still a black box in the diagrams, and may actually remain so forever. It seems conceptually simple enough that I am beginning to think that I should simply describe it directly in Verilog, rather than trying to draw a picture of it first. (There's no way I could have done that with the rest of the logic, first because I would have become totally confused, and second because I needed some kind of picture to work from as I made the clock-by-clock descriptions of how the instructions work.)

Summary:

Jan's project: a few weeks ago, C program + hand-drawn block diagrams.

Mine: the last few days, CAD-drawn block diagrams + register transfer level descriptions of each instruction's operation.

-- Russ