Really simple (kind of dumb) question about transfering data between registers..

Status
Not open for further replies.

BlackHelicopter

Full Member level 2
Joined
Jun 3, 2010
Messages
137
Helped
13
Reputation
26
Reaction score
16
Trophy points
1,298
Activity points
2,207
Not even sure how to ask this or why I can't seem to wrap my head around it.

When exchanging data between registers, as in the example state machine attached, how do the 'Q' outputs stay stable between state changes? For instance at the active edge of the clock, the data at the 'D' inputs are clocked into the register, therefore causing a change at the 'Q' outputs. Well since since the 'Q' outputs are fed back into the 'D' inputs how does data stay stable long enough to satisfy the setup and hold time of the inputs to the registers. Lets say for instance, a state change occurs, the data is clocked into the registers at the rising edge of the clock, and after some propagation delay (after the rising edge of the clock) the 'Q' outputs change, now what if the output of one of the registers changes fast enough that its faster than the hold time of an input to a different register, what happens then? or is that not even possible?

This question also came about when I was reading a chapter in a book (see attachments 2&3). The authors describes creating a data path using two registers which is used to add up the factorial of a value, there are two registers one for the counter and one for the sum. Well the author goes on to define the control word table, and then he then simplifies it a bit by combining two operations: the load of the 'product' register and the 'down count' of the counter. My question is, at the rising edge of the clock, the 'down counter' is going to count down and the 'product' is going to load the old previous product (which is derived from the output of the counter), what's to keep the output of the counter register from changing sooner than the hold time of the 'product' register and screwing up its value.

Does anyone understand what I'm trying to say?
 

Attachments

  • State Machine.png
    12.6 KB · Views: 105
  • Datapath Chapter screenshot 1.png
    106.8 KB · Views: 144
  • Datapath Chapter screenshot 2.png
    106.2 KB · Views: 128

property is used to fix the trigger input on the front. and delay of the data to the output. therefore, the input data is changed later than the trigger can be locked

---------- Post added at 10:11 ---------- Previous post was at 10:06 ----------

in the synchronous system, all data and control signals at the inputs change values ​​later than the front of CLK. And all the CLK input, if possible, make the most synchronous

---------- Post added at 10:14 ---------- Previous post was at 10:11 ----------

in the wrong case, the change of input signals in conjunction with the front of CLK can lead to ingress of flip-flops in any state
 
now what if the output of one of the registers changes fast enough that its faster than the hold time of an input to a different register, what happens then?

Taking the first attachement (the 3 flipflops + combinatorial logic) as example. Ideally (disregarding clock skew) these 3 FFs change state at the same instant, at the posedge of CLK. After this change, the signal propagates through wires, combinatorial logic, more wires and then to the FF input. This results in a sufficiently large delay that the FF's hold time is not violated.

As said, this was for zero skew. In real situation there can be some clock skew, so that will be taken into account when calculating how much margin there is for setup/hold.

Hope that helps...
 
Yes that does help, thanks. That makes sense now that it would have to do with the propagation delay from the combination logic and wires. I can also picture how intermittent issues could arise if there were considerable clock skew between registers like you said. So it seems like it is a valid question at times.

Thanks!
 

Status
Not open for further replies.
Cookies are required to use this site. You must accept them to continue using the site. Learn more…