DRegister values in CPU.cmp?

[ewh]

Hi,

It is my understanding that when the clock enters the tick state, the results get processed by the combinational logic, and that those combinational results will then be reflected by the sequential components when the clock enters the next tock state.

If this is so, suppose we have the machine operation 'D=A'.  Then in the tick state the D input pin will consume the current output of the A register.  Then when the clock enters the tock state, the D output will reflect that value.

I have a question regarding the DRegister output in CPU.cmp.  In the compare file, the value of DRegister on changes on the tick clock state:  1+, 3+, 7+, etc.  For example, it seems like the value of D should be the same in clock states 1 and 1+, but reflect the new value in clock state 2.

It seems like having a CPU which resembles the CPU.cmp, but reflects the DRegister state changes on the tock instead of the tick would function correctly in a computer.  In fact, it seems like it would take much MORE work to implement a CPU which changes on the tick (and produces a CPU.out which matches the CPU.cmp).

Am I misunderstanding something here?  Why does DRegister need to change on the tick clock state instead of the tock?

(I am asking this question here because I am a hobbyist and am working through the book on my own for fun.  I don't have a professor or other students to ask this question.)

Thanks!

[ybakos]

I'd love to discuss this further with you in this thread.

As I recall, when I first worked through that chapter, I had to think in terms of "tock-tick" rather than "tick-tock." Regardless of what we call that cycle of the clock, the point is that the typical modern computer has the opportunity to change the state of register values on every other motion of the clock.

[ewh]

Hi!  Thanks so much for responding.  I have noticed that you are the most active poster on this forum system.  This is incredibly valuable for people out there who are working through the book on their own and don't have a teacher to ask questions!

I completely agree with you that the tick vs. tock distinction is generally not too important at this level of digital abstraction.

That being said, from the results of the earlier chapters, I believe it is more "natural" for the output state of a register to only change on the tock.  Here's my argument:  the Register component is constructed from a set of Bits.  The Bit is constructed from a single DFF (along with the Load input Mux).  Since the DFF is the fundamental sequential component of the Bit, we should examine the timing behavior of the DFF.  The DFF consumes the value of its input when the clock ticks high.  Then when the clock tocks low, the value appears as the DFF's output.  Hence, I believe the Bit and Register should exhibit identical timing behavior as the DFF -- their output should only change state on the tock clock state.  In fact, Bit.cmp and Register.cmp confirm that these components only change their output state on the tock.

This leads me to believe the DRegister output column in CPU.cmp is "unnatural" with respect to Bit and Register output timing.  It is possible to implement logic inside the CPU which will produce a DRegister column which matches CPU.cmp.  However, I do not understand how the DRegister output behavior seen in CPU.cmp is more desirable than having that column change states on the tock instead.

I must be missing some very important point here.  Any sort of clarification would be extremely valuable.

Thanks very much!

[ybakos]

Hmmm, I'm not sure as of this moment, but I'll take a look when I've more time.

[ewh]

Do you have any sort of regular contact with the authors?  Would this be worth considering as a possible errata submission?

Thanks!

[ybakos]

If you believe you have an error, post it here.