| ??? 08/29/07 17:56 Read: times |
#143735 - finite state machine Responding to: ???'s previous message |
Jan Waclawek said:
... and some infrastructure (program startup, output prints - this will be expanded certainly).
As can be seen in the code, I'll try to keep it as Pascalish as possible... :-) The syntax you choose will make less difference than the fundamentals of your architecture. I believe you'll find that, in the course of working through this, there'll be a lot of rethinking, resulting in a three-steps-forward, two-steps-back measure of progress. All the "processor" will "happen" in the tick() loop. I'd guess that a lot depends on whether you treat it as a 12-clocker or a one-clocker, or something in between. That will determine how many "ticks" you have to process. Think for a moment about the old MCS6502 ... it had a single two-phase, non-overlapping clock, and performed data/register arithmetic on one phase and address/index arithmetic on the other. The data accesses occurred on the phase on which it did the address arithmetic. That way, the ALU could perform both sets of operations. In turn, this meant that the program counter, rather than having to be a long synchronous counter, could simply be a register pair, and those registers, rather than having to be clocked elements, could be level-triggered latches, which meant one AO gate rather than six simple gates per bit. That was the reason that the MCS650x series was able to "buy" market share when it did, since it was 25% the physical size of its competitors. After all, the semiconductor industry sells silicon by the pound ... First, reset is asserted, and one tick is "run" (maybe in the future the reset will last for longer?). This, at the moment, clears the program counter. Then, the machine ticks infinitely until ESC is pressed. This will provide an excellent environment in which to explore the effects of different sorts of reset conditions. One, for sure, that you'll want to examine, is a sequential clear and preset of all the internal states, and another you'll want to compare is the hard-reset provided by presetting all the internals into a predetermined state and stopping everything while reset is active. You might even want to examine what happens when you arrest the clock during RESET. Who knows? ... it might shed some light ... The program counter, although it would seem that it can be a simple counter, is in fact a demultiplexer, selecting between various sources of the "next address" (here, the incremented address and zero, but in the future, jump address will come here, too), and a latch which keeps the current program counter value.
The address output for the ROM comes from a demux, too; this is to address the MOVC instructions in the future (for now, there is a short only). Code byte is fetched from the ROM and latched - to be decoded and/or processed otherwise etc. Apparently, this does not solve the question "how does it know which is the code and which are data" yet... to be continued... JW I think I've mentioned this before ... the reset initializes the internal sequencer (FSM) and you'll see, quite clearly, that if you interpret the combined nRD and nPSEN signals as a single address bit, and think of the memory map as a combined object, with the SFR-space as "I/O-space" and thereby the direct accesses to that portion of addressable space as I/O instructions, and the IRAM as an internal register file, the workings of a finite state machine become quite simple. As with any modern computer, when, in its sequence, it encounters a data object determines whether it's interpreted as an opcode. After all, the opcode is only part of an instruction, though it may be entirely contained within one byte. RE |
