I'm not so sure you can't do that. Anyone with minimal training can do it if they're willing to put forth the necessary effort and apply the necessary discipline.


That's why I frequently object to the use of the words "software" and "engineering" in the same paragraph or sentence. At least in the U.S, the two still seem to be mutually exclusive.




I've seen far too many examples of what I mentioned, i.e. lots of unnecessary "features" leading to far too many "creatures."

These result from too much bottom-up rather than top-down thinking, along the lines of, "I know how to do this <meaning one feature or another> so I'll do that here ..." and not enough, "Gee ... what's required here to get the job done?"

If you've ever looked at those 1980's photomicrographs of single-chippers that were distributed, in some cases as advertising posters, by Intel, Zilog, and Motorola, among others, with their lableling of the prominent features of their chips, you may remember that there were physical features that were somewhat apparent, even if only from the relative locatoins of those features, indicating how the data flow was routed.

In the '70's, chips were designed with standard cells or with "sea of gates" orientation, and the gate count was often expressed in XOR gates, that being 4 physical gates in 3 levels of logic. That generally made the ALU the largest bit of non-memory real-estate in the chip.

You've seen me mention multiplexers quite frequently in the context of moving data from source, through ALU, to destination. Well, if you use tristate busses, the logic is reduced considerably, though the use of tristate resources is somewhat limited or even forbidden in some current FPGA families.

If you try to think about the architecture, in the context of moving data through the ALU in order to execute the instructions, and allow yourself the freedom to use the ALU to do the incrementing, decrementing, and loading of PC, SP, DP, etc, when processing address objects, I think things will fall into place. Keep in mind that data can move between a source and multiple destinations, e.g. from the ALU to PC and Address Bus as well, concurrently. Separate buses are required for moving multiple objects from source to ALU.

If you want to perform an indexed address computation in a single stroke, you have to have an adder for the index, as well as for the PCL or DP. You also have to have paths for the 16-bit DPTR or PC in addition to the 8-bit index in A or offset in Rn, to the ALU. The added complexity of the ALU doesn't add much delay, though it does add real estate.

At this point, you're dealing with concepts. I'm convinced that if you keep the concepts in mind as you design the ALU, the other constructs will make themselves evident.

RE