Understanding the clock and sequential logic

[Lindy]

This is something that I couldn't figure out... until I had a break-through last night.  I've thought about this for years, but never got it.

May I say how I came about this revelation so someone could perhaps kindly check me?

Looking at clocked chips makes sense to me, from the DFF to memory.  However, how they work together with the entire CPU  I didn't get until now.

Here is how I imagined it.  Now, I'm a programmer by profession, so I need to see things in a certain way.  I looked at a diagram of the CPU architecture, with memory and instruction decode, muxen, ALU, etc.  And I imagineed all input currents flowing up and to the points of any clocked chip (registers, PC, memory, especially) and stopping.  Until a clock tick, then the input passes to the output and optionally stored in the register depending on the load bit.

The PC output is an index into the ROM, so that takes care of the next instruction whether it be a jump or not.  This instruction is already queued up to go until the next clock tick.  Actually it is more simple than I imagined.

Is this about right?  One problem with the design in the book is that it is perhaps too minimalist and almost perfect.  I find that in my imagination it is difficult to extend it.  

I had a few ideas.  How could I read the ROM memory, or even write to it?  What about doing multiplication and divicion in the ALU?  Or delegate it to a math coprocesser.  What about I/O to simulate a disk?  Would I use CPU interrupts to handle it?

The n2tet hdl is very simple and easy to learn.  I wondered about other HDL and came across VHDL that is used to program FPGA's.  I downloaded it and started to install, but when it told me it wanted to use multiple CPU's, and it was taking forever, I decided that it was just too huge for me to "play" with at this time.

I appreciate everyones' help with this, even though I'm just doing it on my own for fun and not as a part of a university.

Kind regards,
Lindy

[cadet1620]

Lindy wrote

Here is how I imagined it.  Now, I'm a programmer by profession, so I need to see things in a certain way.  I looked at a diagram of the CPU architecture, with memory and instruction decode, muxen, ALU, etc.  And I imagineed all input currents flowing up and to the points of any clocked chip (registers, PC, memory, especially) and stopping.  Until a clock tick, then the input passes to the output and optionally stored in the register depending on the load bit.

The PC output is an index into the ROM, so that takes care of the next instruction whether it be a jump or not.  This instruction is already queued up to go until the next clock tick.  Actually it is more simple than I imagined.

Is this about right?  One problem with the design in the book is that it is perhaps too minimalist and almost perfect.  I find that in my imagination it is difficult to extend it.  

I had a few ideas.  How could I read the ROM memory, or even write to it?  What about doing multiplication and divicion in the ALU?  Or delegate it to a math coprocesser.  What about I/O to simulate a disk?  Would I use CPU interrupts to handle it?

The n2tet hdl is very simple and easy to learn.  I wondered about other HDL and came across VHDL that is used to program FPGA's.  I downloaded it and started to install, but when it told me it wanted to use multiple CPU's, and it was taking forever, I decided that it was just too huge for me to "play" with at this time.

I appreciate everyones' help with this, even though I'm just doing it on my own for fun and not as a part of a university.

Yes, this is a reasonable way to look at synchronous sequential circuits.

To be able to read ROM, you need either a "dual port" ROM -- one that has two sets of address inputs and data outputs -- or two-cycle instructions. The two-cycle instruction reads the instruction from ROM during the first clock cycle and stores it in an instruction register. The second clock cycle executes the instruction. See this post Hack II: Escaping the Harvard straitjacket.

There are also some other ideas about extending the architecture in the More Fun to Go category.

--Mark