| ??? 09/01/07 16:00 Read: times |
#143849 - You can't have it both ways ... Responding to: ???'s previous message |
Russ Cooper said:
Richard said:
If RESET causes the IOR to be loaded with LJMP, and causes the PC to be loaded with 0x0000, then it matters not how long RESET is asserted. If the execution state machine is initialized to its first state, in which it recognizes that there is a new opcode in the IOR, it must then interpret the opcode as containing the number of code-bytes and cycles it needs to execute the instruction. That all makes sense, but the question I have (which I think is the same thing that Jan is concerned about) is this: When reset finally goes away and the processor executes your "fake" LJMP, it's going to need to get the second and third bytes of the LJMP instruction from somewhere. But where? It can't fetch them from the instruction stream in the normal fashion, so it seems that there must be some additional, special logic to supply them as well. True? If so, that seems like a bit of a kludge. If not, please explain. -- Russ Don't forget that this is a Harvard architecture machine, with separate code and data spaces. Further, you mustn't forget that the SFR and IRAM spaces are more like I/O and register space, respectively, than they are like normal memory in some respects, and that it's conceivable that separate operations code and data space could occur concurrently. Unfortunately, synchronous circuits are generally controlled with state machines. That requires, among other things, that you decide upon a sequence in advance of implementing the design. Keep this in mind ... Now, assume that when the IOR is loaded with the code bus content, in the context of a "state=0" (current instruction complete) condition, generally, is interpreted as it's loaded, thereby loading the number of states into the execution state machine and number of cycles in to the bus control state machine, based on what the opcode demands. Let's assume that RESET doesn't load a "FAKE" LJMP. Assume instead that it loads a "REAL" one, as RESET is, simply, an input to the execution state machine. LJMP tells it to retrieve two additional bytes from code space and load them into the PC. In the presence of RESET, however, it simply loads each byte from a hard-wired 0x00, which, you might say, explains why, among other things, RESET is required to be held true for at least two machine cycles. The RESET presets the IOR, and the resulting combinatorial opcode interpretation forces, sequentially, the load of PCH and PCL. Since the opcode is directly preset into the IOR, no machine cycles are required. In the presence of RESET, the bus control state machine generates its normal timing, but the data path, instead of reaching into code space, finds a hard-wired zero instead, and proceeds to load that into the PCH and PCL so long as RESET is present. Once RESET goes away, the current instruction is complete, hence, the bus control state machine causes a byte to be fetched into the IOR, from wherever the PC points, just as it would under any other circumstances. LJMP is, after all, just a LOAD PC immediate instruction. In a very real sense, once you're "into" the design of a processor core, there is no code space and there is no data space, just as there is no I/O space. There's just "space" and it's addressable by signals from the state machine(s) that control(s) the system operation. RESET causes the initialization (preset) of a number of conditions within the core. One of these is the load of the PC, or, in a more practical sense, the behavior of the execution state machine in the presence of RESET. One of the things that this execution state machine has to do is to keep the steering logic synchronized with the bus control state machine. In order to do this, it just might delay the release, internally, of RESET for two cycles, so that the PC can be appropriately loaded. I'd be surprised to find that the 12-clockers don't do this. What the other-clockers do is anyone's guess. RE |
