This suggestion sort of went against my intuition when Andy first made it, and when I first started the 8051 core project, I found that I actually needed to think in terms of building blocks like multiplexers and adders and registers in order to develop the overall picture in my head and on paper. Without the pictures, I would have been completely lost at that stage.

However, when I actually started implementing the thing, I found myself naturally following Andy's advice for certain parts of the design, but not all of them. For example, the code memory and internal memory both show up as distinct chunks of code in the Verilog model that correlate obviously with the corresponding parts of the block diagram.

On the other hand, there isn't any one place in the Verilog model that you can point to and say, "this is the ALU." Instead, the specification of the ALU is distributed among a large number of statements that describe what it does individually for each of the many instructions that use it.

I was pretty happy with all this until today when I started thinking about how to manage the carry, auxiliary carry, and overflow flags that are generated by the 8051's add and subtract instructions. Suddenly it seems like I need to be thinking at a much lower level than I have been, perhaps even to the point of explicitly cascading a series of one-bit adders so I can access the carry signals between the individual bits.

Or maybe there's some magic trick. I'm not sure. Jon, how does your simulator handle this? Jan, did you get to this point with your C model? Anybody else have any hints?

-- Russ