Where is DFF clock input?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Where is DFF clock input?

tyler1313
In Bit.hdl, DFF is used with one input and output.
PARTS:
    DFF(in=muxout, out=ffout, out=out);

However, everywhere I look and even in the Nand2tetris book, there is supposed to be a clock input as well. Why is the clock input missing from Bit.hdl? The reason I ask is that I want to build the entire hack computer but I cannot do that without knowing where all of the inputs/outputs are going and there seem to be some missing from the built in chips such as the DFF chip. Also curious how this computer works in the hardware simulator if some chips are missing inputs or outputs.
Reply | Threaded
Open this post in threaded view
|

Re: Where is DFF clock input?

ybakos
tyler1313,

The clock input is inferred, since it is composed of a DFF, which has a built-in implementation. See chapter 3, and also the bottom of slide #2 here: https://docs.wixstatic.com/ugd/44046b_f594de40a9fc49daaceddc60d44812cc.pdf

Reply | Threaded
Open this post in threaded view
|

Re: Where is DFF clock input?

WBahn
Administrator
In reply to this post by tyler1313
The underlying reason that there is no clock on the DFF is that this simulator can't simulate it directly, and so it has to be inferred.

If you were to build, say, and RS latch using two NAND gates, the simulator would go bonkers because it has no concept of propagation delays through the gates -- it effectively assumes zero propagation time. So on every (inferred) clock cycle it lets the logic propagate through the gates until it stops changing. But if some of the gates have outputs that feedback into earlier gates in that path, it may never stop changing (or might stop after an unpredictable number of cycles). In a real circuit, the propagation delays result in the circuit latching in a stable result following a clock edge. But simulating that behavior requires a much more detailed simulation model for the gates and a much more sophisticated simulator and it opens some cans of worms as far as ways that students could go off the rails and do so in a course often taught by instructors that don't have a lot of experience dealing with these real world issues. So the authors simply left it out and impose a constraint on the logic you implement which forbids combinatorial logic from feeding back into itself (without being registered via a DFF that their simple simulator can use to break the feedback path so that the system can't oscillate).