Yes, I've been concerned that it's easy to reach that conclusion. My main concern, however, is not for conservation of silicon resources, but for conservation of effort. Hardware is expensive, particularly if you're headed for production, since you have to ship the hardware with every product, while software is "just a $0.12 CD." Once you've decided on a set of hardware, e.g. on a specific FPGA, whether a hobby project or a production target, the cost becomes fixed, so that's not a problem any longer.

As with anything, there are multiple ways of going about doing this thing. I've looked at, though not thoroughly understood your diagrams, etc, and that, as much as anything, has persuaded me that you're overlooking a much simpler approach. OTOH, I don't want to tell you how to do your task, particularly since it's a learning exercise. The more I attempt to direct your effort, the less learning opportunity you have.

For at least three decades, the thrust in design methodology has been toward "top-down" design. When first exposed to the distinction between "top-down" and "bottom-up" design strategies, one is tempted to say, "It's obvious what's better!" but it's more subtle than that. Bottom-up design is not just a matter of saying, "Well, the boss got a good deal on JK flipflops last week, so that's what we'll use ..." as one is often told in school.

At the risk of oversimplifying, I'd have to say that "top-down" methods require that one look at the entire problem and devise a single solution that addresses all the requirements one is trying to meet. "Bottom-up" methods tempt one to look at the tools and skills one has and think about how one can use those to address the various requirements of the problem.

My comment, early on, that you can use the same ALU to operate on address objects that you use to operate on data objects seems to have forced you to believe that all I'm thinking about is saving a gate here and a gate there. While it's easy to reach that conclusion, that's not what I'm thinking at all. The fact that I pointed out that it saves logic otherwise required for those long and complex counters, which seem so simple in the context of "SP--" or "++DPTR," was more of an effort to show you that you'd then have less complexity in your hardware design. I've tried to suggest that one can view this MCU core, and, in fact, nearly
any MCU core as a set of resources demanding output, a set of resources providing input, an ALU that preforms the necessary operations on inputs and outputs, and a set of control logic that prepares and steers the logic paths between all the resources.
If you design a



This is really difficult, as I see the flaws, if there are any, as being at the very top, namely in the method with which you've approached the task. The implementation details you've mentioned have supported this concern. It seems as though you're designing an engine that does a few things and then simply "hang a bag on it" for each additional operation. This is a common "software" approach, which can be made to work quite seamlessly in software, but often doesn't work out so well in hardware. That's why I've occasionally cautioned you about attempting make the hardware internals look too much like the software externals, i.e. make the hardware track the behavior of the MCU as viewed from its instruction set and how it executes it. This is a symptom of bottom-up thinking.

One thing that you probably haven't considered, is that you could, if you wanted, structure your code memory as byte-addressable, but long-word (32 bits) wide. That allows you to access all three bytes of a long instruction concurrently, and, therefore, to execute the entire instruction in one cycle, fetching and decoding the next opcode concurrently with the execution of the current one. The same is true for two-byte instructions, which are the ones most often used, right? The consequence of this sort of operation is that your PC has to be incrementable by 1,2,3 or 4. The ALU probably has an adder/subtractor quite capable of doing that if it's extended to be wide enough. That is, however, the sort of thing with which a habitual "bottom-up" thinker (like me) has to be very careful.

Comments such as "the Harvard architecture cries out for concurrent access to code and data space..." or whatever it was you said along those lines, is another example of a "bottom-up" view, which is also reflected in the diagrams and charts you presented.

Bottom-up strategies lead to a very quick and often promising start, while top-down strategies lead to a timely completion. Bottom-up strategies can, not always, but often, lead to a "blind alley." Top-down methods will not. This is because "top-down" methods require that the design be complete before an implementation can be devised. Block diagrams with empty blocks, and charts with missing elements suggest that's not been done.



I hope I haven't just "muddied the water" with these comments, but, I'm serious about not overly driving your effort. Initially, I figured you'd had some experience with CPU design, and were just trying to start learning Verilog. Apparently, you've got to learn a bit more about rigorously structured hardware design, too. Then, too, there's the problem of devising a design targeted at FPGA, which is something I'm still trying to learn, and then there's the business of expressing that design in Verilog, VHDL, ABEL, schematics, or whatever.

Your suggestion of using clocks in a certain way suggests that you've decided, IMHO prematurely, how the core operation should be timed. If you're going to use a multi-clocked approach, I'm persuaded that the clocked elements should be pipeline registers used to speed things up, at the cost of added latency. That's why I lean toward a single-cycle solution rather than a multi-clocked one. Once you have a single-cycle solution firmly in mind, you can speed it up with pipelining.

It's like Andy has repeatedly said, "If this were easy, everybody would do it." The numerous "rubbishware" examples, in the form of partially functional, only partially complete, insufficiently documented, and nearly-impossible-to-understand cores in the public domain should have convinced you that it's not as easy as it looks.

This thing's getting a bit long, and I've had a number of interruptions ... so I think I'd best hold off on adding any more "grist for the mill."

The main thing is that I don't want to drive your project. I'm just seeing things I've seen in countless meetings over the past 40 years, where designers anxious to produce results have started coding/soldering/wiring/ordering before each and every requirement is fully spelled-out and rigorously addressed. I hope you won't fall into that trap.

RE