| ??? 12/13/07 03:58 Modified: 12/13/07 05:29 Read: times |
#148124 - The diagrams are now updated Responding to: ???'s previous message |
Hi Jan,
Thanks for taking a look at my stuff before going to sleep! Jan said:
... especially the lack of description of the numerous intermediate registers you are using, also the meaning of elements of the diagrams. It adds to the thrill of the whole thing to try to figure out what's what... :-)
Nevertheless, it might add to the clarity if you'd distinguish addresses and data; and maybe if you'd clearly mark the muxes maybe also with the intention to add description of the steering signals in the future. Ooh. You are right. I added a bunch of explanations like you are talking about. The update is in the same place as before. But OK I am roughly in picture. Very nice work indeed. I can see the amount of scrapped paper behind. Thank you. P2 is not part of the MOVC @Ri address; it's more like a coincidence that it can be used as such. The MOVC @Ri is a 8048 legacy and is intended to be of purely 8-bit address. Some derivatives do have a dedicated "page register" for this purpose. This is interesting. Since the plan here is to have all the "external" RAM onboard the chip, there really is no P2 driving the upper 8 bits of an external address bus. So you're right, it really doesn't make any sense. I should probably just say that there is no P2. Surely no compiler would assume otherwise??? I'd not see bit operations as a separate ALU, rather, generate the proper constant (0x01, 0x02, 0x04,..., 0x80) and run the whole byte through the ALU. Anyway, that's the way how the original does it indeed (see Read-Modify-Write). I had it all in one ALU to start with, then thought it might be easier to handle the bit operations separately. As I've noted, the Internal Memory and the ALU and the BLU are just black boxes right now. I suppose this will become more clear when I get around to detailing their innards. I can't see how you pick the content of accumulator, for example in the first row (after the boring NOP). That's done via the ACC selection on the multiplexer directly under T1. Maybe it's more clear now that the diagram has some explanatory notes on it. (It's not shown yet on the diagram, but some of the registers--ACC, R0, R1, SP, etc.--have to be implemented in a way that their outputs are available at all times. They can't be buried inside a simple RAM like, say, R2-R7 can.) You certainly noted that your Clock0 column is hopelessly boring, and also that there is no program memory fetch in the last Clock of each instruction. Maybe it could be folded somehow - that's roughly what's called pipelining... Making more trouble with jumps and alike... But that is maybe for an another exercise, for now the present state is more than fine... No--for most instructions (maybe all except the jumps?), I want to go ahead and overlap the fetch of the next instruction with the last clock of the previous instruction. Although the big table doesn't really show this, Note 4 in the fine print below the table kind of hints at this. I don't think this presents a big problem for the jumps; for them the fetch of the next instruction will just have to wait until the clock after the jump is truly complete. -- Russ |
