Why we need the DFF to build the Register

[geraldli]

In this chapter. It says we can use DFF to construct a 1-bit register.

The final circuit has input(in, load) and output(out).  It’s easy to be implemented

My question is, why do we need DFF to construct the 1-bit register?
As far As I know, the dff works depending on clock pulse.

However, it’s possible to construct a 1-bit register without the clock input(I actually simulate this and it works. But I don’t know how to upload an screenshot here). It works under the same rules:
if load==1 then out=in
if load==0 then out is unchanged

It seems the clock pulse is unnecessary if all we want is a simple register.  The DFF with clock is much more complex.

Can any one help to explain the reason of using clock-based circuit  here?

[ivant]

This is true in general, but not for the hardware simulator developed for the N2T course. It is simplified and cannot handle cycles (unless they are "broken" by the provided DFF).

You can create a flip-flop without clock. But what would it mean to create a  register without a clock? It is supposed to emit the value from the previous input, that is out[t] = in[t - 1]. How would you know when to get these values without a clock? It is in the specification in the form of t.

In the real world (not simulators) it takes time for something to happen. Changing the signal from 0 to 1 for example isn't instantaneous. It will move through values, which are digitally not valid, it may fluctuate several times before it stabilizes to a value, which we interpret as a digital 1. Each gate needs some time for its inputs to stay stable before it can produce a correct and stable output. This output is often an input to another gate, which also needs its inputs stable, and so on. You can calculate these times for circuits as well, by finding the slowest path for the signals to propagate from the inputs to the outputs.

In a purely combinational circuit you can just wait for the outputs to stabilize and call it a day. But once you introduce state things become harder. Suppose one of these circuits is a 1-bit memory of some sort. You want it to remember the value in its input when it's the correct one. Too early or too late and it might not even be a valid value. The clock is used to synchronize these and to "instruct" the register to remember the value when it's valid. The propagation times of the circuits dictate the minimum and maximum allowed clock speeds.

P.S. I'm a software guy and my knowledge about electronics is very rudimentary. I'm sure there are much more considerations when you develop real hardware.

P.P.S. To include an image, just click on "Insert Image" button in the edit form.

[geraldli]

Thanks for the reply.

The "stabilizes" thing might be the reason. I do agree hardware design is much easier with clock.

However. I still don't think the clock is something that we "must have" when design the register.

From the link here, we can see there exists asynchronous sequential logic. It's possible to design the
out[t] = in[t - 1] without clock:
https://en.wikipedia.org/wiki/Asynchronous_circuit.
https://en.wikipedia.org/wiki/Sequential_logic.

So my understanding is:
1. The sequential logic can be done without clock. Whenever circuit can holds previous state with an inner memory,  the sequential logic can be done.
2. It's much easier to implement the sequential logic with clock in electronics aspect. It's the main choice in today's industrial design.
3. As for register, since the function of which is just to remember the inputs, the clock here looks like a compromised choice.

[WBahn]

geraldli wrote

In this chapter. It says we can use DFF to construct a 1-bit register.

The final circuit has input(in, load) and output(out).  It’s easy to be implemented

My question is, why do we need DFF to construct the 1-bit register?
As far As I know, the dff works depending on clock pulse.

However, it’s possible to construct a 1-bit register without the clock input(I actually simulate this and it works. But I don’t know how to upload an screenshot here). It works under the same rules:
if load==1 then out=in
if load==0 then out is unchanged

It seems the clock pulse is unnecessary if all we want is a simple register.  The DFF with clock is much more complex.

Can any one help to explain the reason of using clock-based circuit  here?

The problem you are going to have in using such a register is getting the load signal to assert and deassert at just the right time relative to inputs to ensure that you always capture the right value. This will be aggravated by the fact that the output of your register will change at a time dependent on when the inputs change and the outputs will be the inputs for other registers, thus affecting when they change. The end result will quickly be a highly unstable and unreliable circuit.

You can certainly design asynchronous state machines, but there are demons in those waters.

Where I worked we had several people that routinely designed asynchronous logic because it was "easy" to design. But they didn't take the kind of care that was required to do it right and killed a few chips as a result. After finding one of these failure points in a design I finally convinced them to adopt a "fully synchronous unless there's a damn good and well-documented reason to do otherwise" policy. That served use well for a number of years until we had to do a design in which we had to suppress the clock during certain noise-sensitive portions of the processing but still needed sequential logic to work.

So since I had been the person that pushed so hard for the "that shalt not use asynchronous logic" rule, I got tasked with designing the asynchronous logic for the chip since now we had a damn good reason. The result was a latch circuit that had forward and backward handshaking built in and that worked quite well, but it was NOT easy to design or verify the basic building block.

It was rather ironic that I, the champion of fully-synchronous logic design, became the only person in the company that was allowed to do asynchronous designs for several years.