Administrator
|
Just my thoughts. Your suggestions are not unreasonable, but I don't know to what degree they align with the authors' goals. There are numerous places where they could expound on the beauty and simplicity of their design, but they appear to have refrained from that in general. I think the reason is that the project is so vast in scope that they have to keep it laser focused on just what needs to happen for this project -- notice that the set of basic chips doesn't even include a 2-input NOR gate because it turns out it just isn't needed for the project. So I suspect they would be reticent to add that just in the interest of keeping the material is lean as possible.
On the c-bit notation, I think the intent there is to have 'c' mean nothing more than a generic control signal, not that there is a one-to-one mapping between a bit in the instruction and a particular control signal in the design. But I agree that, at first blush, it seems like that might be what is being said (especially since, for many of them, that's what it turns out to be). Perhaps better would be to use to different letters or even to explicitly enumerate the control signals in the design with a subscript. That would not only suggest an obvious naming convention for signals in the implementation, but would also make it much easier to refer to the various signals in the text.
I would recommend that they add a part, say InstructionDecode, at the top level that takes in the instruction word and the flag bits from the ALU and produces each of the control signals. I think that would be a better match to the level of abstraction at that level of the design compared to having a bunch of glue-logic parts sitting there.
|