DFF/clock necessity

9 messages
Open this post in threaded view
|

DFF/clock necessity

 Hello and thanks for the book! But clock explanation in this chapter is, imo, too superficial, and leaves too many questions: 1. Remembering something is time dependant - but why? If logisim doesn't lie to me, and i doubt it does, you can build bit gate without clock. 2. This is basically continuation of my first point: why dff is needed at all in bit gate, which works just fine without it? 3. "On the other hand, there is no difficulty in feeding the output of a sequential chip back into itself" - again, why? I don't see how you can feed output back without using additional gates like mux, and this can be done just as well with combinatorial chimps (also, i don't see relation between  two chips in figure 3.4: i'm pretty sure that if we pull that dff out of sequential chip, it (chip) will be combinatorial and will work).
Open this post in threaded view
|

Re: DFF/clock necessity

 Administrator Vfffzx wrote 3. "On the other hand, there is no difficulty in feeding the output of a sequential chip back into itself" - again, why? What happens if you feed the output of a Not back to its input? in=0 so out=1 -> in=1 so out=0 -> in=0 so out=1 ... (It is like the feedback squeal at a concert when the speakers are so loud that the performer's microphones re-amplify the speakers.) The clock in a sequential circuit stops this oscillation. I don't see how you can feed output back without using additional gates like mux, and this can be done just as well with combinatorial chimps (also, i don't see relation between  two chips in figure 3.4: i'm pretty sure that if we pull that dff out of sequential chip, it (chip) will be combinatorial and will work). Try these two circuits in Logisim. What happens in the lower circuit when 'in' is set to 1? 1. Remembering something is time dependant - but why? If logisim doesn't lie to me, and i doubt it does, you can build bit gate without clock. 2. This is basically continuation of my first point: why dff is needed at all in bit gate, which works just fine without it? See this play-hookey.com page for a good introduction to sequential circuits. The Bit you made in Logisim was probably what is called a D Latch—with 'in', 'load' and 'out'. To store data, the 'load' must go high and then low. (While 'load' is 1, out=in.) Any circuit that has feedback is a sequential circuit. The sequential circuits used in the Hack computer are synchronous sequential circuits because they all rely on a clock. In the Hack computer all the synchronous circuits are connected to the same clock signal. Early computers were built with non-synchronous circuits like Latches, and and the control pulses had to arrive at the right place in the right sequence and at the right time. As computers got more complex and faster, this sort of individual pulse management became too complex. Designers moved to synchronous circuits. Why didn't they use synchronous circuits to begin with?  DFFs require about twice as many vacuum tubes (valves) as Latches which meant twice as much power needed and heat generated which required larger cooling equipment which needed even more power! --Mark
Open this post in threaded view
|

Re: DFF/clock necessity

 Thank you for the answer. Do i understood correctly, that DFF main purpose is to synchronize (by delay) and not to remember?
Open this post in threaded view
|

Re: DFF/clock necessity

 Administrator Vfffzx wrote Do i understood correctly, that DFF main purpose is to synchronize (by delay) and not to remember? Yes, that is correct in synchronous designs like the Hack computer. In this course DFFs are used exclusively to build memory-based parts, but in the real world they help solve many timing related problems involved in interfacing between various devices that run at different clock rates or have different timing requirements. For example in this post a DFF is used in the interface between a Hack Computer and Logisim's Keyboard component. --Mark
Open this post in threaded view
|

Re: DFF/clock necessity

 In reply to this post by cadet1620 cadet1620 wrote Try these two circuits in Logisim. What happens in the lower circuit when 'in' is set to 1? In Code: The Hidden Language of Computer Hardware and Software Charles Petzold is using a fead-backing NOT gate to create clock signal. It's too fast for the computer he's building there (it's as fast as 1 gate propagation time and you need much slower clock for a CPU), so he's slowing it down by using a counter. Logisim and many other simulators don't support this kind of feedback loop.
Open this post in threaded view
|

Re: DFF/clock necessity

This post was updated on .
in a quick scan through Code I only saw self-connected Nots in two places in chapter 14, both in theoretical context. Is there another place?

In the real world you need 3 Nots in series to make this work reliably.

Real digital ICs are, at heart, analog circuits. Functionally a Not gate is a very high gain inverting amplifier. It's output (transfer function) can be approximated as
Vout = C (1 - Vin)
where C is a large constant. The actual transfer function is non-linear and depends on the type of logic.

When you connect the output of a Not gate to itself, you have created an analog computer that is solving for Vout = Vin. The idealized transfer function above has the solution Vout = Vin = 0.5. Real world parts settle to somewhere between 0 an 1.

7400 series TTL tolerates this mid-level voltage, but for 4000 series CMOS, this is really bad news because both of the output transistors are turned on at the same time and a large amount of current flows through the gate and can result in burnout.

(4000B series added output buffers after the gates. The output buffers are effectively 2 inverters in series so there are 3 inverters in each of the Not gates in the part. Connecting a 4049B's output to it's input may work as an oscillator since it is physically 3 inverters in series.)

Even though you can get 3 Not gates to reliably oscillate, you would not want to use this in real design. The propagation delay for ICs varies from batch to batch so the oscillation frequency will as well. In the real world, for frequency determination you need to include at least a resistor and a capacitor in the circuit, or better yet, a crystal.

The other major problem is that because the oscillation period (1/f) is close to the propagation delay of the ICc, the output is more like a sine wave than a square wave.

3-Inverter oscillators
top: 4000 series CMOS
bottom: 74LS00 series TTL

(Use your browser's "view image" to see the full sized images.)

These slow rise times are good enough to feed a TTL flip-flop or counter, but I've never tried it with CMOS which generally has problems with slow rise times.

--Mark

Open this post in threaded view
|

Re: DFF/clock necessity

In reply to this post by ivant
(Since I had my 'scope and proto boards out...)

Speaking of questionable circuits, here's one I remember from a product I worked on in the early 80s. There was a need to capture some data twice as fast as originally designed, so all the systems needed to be reworked at minimal expense.

The solution was a "dead bug" rework to the boards—glue a chip upside down onto another chip and wire to the pins that are sticking up in the air. The chip that was used was a 4 Gate Xor used like this:

You can make this circuit in Logisim and hook the output to a counter's clock and the counter will increment whenever the input clock changes, even though the final Xor's output does not appear to change.

 74LS86 Xor-based edge detectorupper trace: input clock lower trace: double rate output pulses

(Use you browser's "view image" to see the full size image.)

--Mark
Open this post in threaded view
|

Re: DFF/clock necessity

 In reply to this post by cadet1620 cadet1620 wrote in a quick scan through Code I only saw self-connected Nots in two places in chapter 14, both in theoretical context. Is there another place? He defines the NOT oscillator in chapter 14. Later in the chapter he creates a frequency divider from a series of edge-triggered DFFs. He connects the NOT oscillator to the divider and then to a 16-bit counter to measure its frequency. Then, in chapter 17 he uses the counter, along with the oscillator, to serve as instruction counter in one of his designs, and this oscillator is used as a clock signal generator afterwards, without explicitly mentioning it. But you are right, of course. In chapter 18, he moves from relays to semiconductors and he writes this: Charles Petzold wrote You'd probably want to use a better oscillator as well. While you can certainly connect the output of a TTL inverter to the input, it's better to have an oscillator with a more predictable frequency. Such an oscillator can be constructed fairly easily using a quartz crystal that comes in a little flat can with two wires sticking out. These crystals vibrate at very specific frequencies, usually at least a million cycles per second.
Open this post in threaded view
|

Re: DFF/clock necessity

Charles Petzold wrote
... While you can certainly connect the output of a TTL inverter to the input, ...

Petzold's a good writer and I love Code and highly recommend it. In fact, I currently don't have a hard copy because I gave it away to a kid in my neighborhood who is showing an interest in hardware.

But he isn't a hardware guy. This is an error. If you connect a TTL inverter output directly to its input you get a steady output voltage of about 1 V.

Here's a 'scope shot of what actually happens at the moment the output is connected to the input while the chip is powered.

 Upper trace: input Lower trace: output vert: 1V/div. horiz: 50ns/div.

It takes about 100ns for this "analog computer" to solve Vout = Vin.

Notes:
The input has a pullup resistor to +5v so that it isn't floating before the out-to-in connection is made.
All voltages displayed in the screen shot are 1/10 actual value since I am using 10:1 high impedance probes.

--Mark