Bad Circuits - Test Your Knowledge

[berkeman]

Hey berkeman, no comments on the previous circuits you posted (post #134 and #135)?

Sorry, I got buried at work for a bit. Yes, you have identified most of the bad things with [F] and [G] in my post #117.

[F] There needs to be hysteresis in the comparator part of the circuit (the LM741 opamp), and the output voltage levels need to be fixed to be TTL compatible. You make a good point that some signal conditioning of the input signal and clamping of the signal before the opamp would be a good idea, depending on the characteristics of the signal source. There are several ways to fix the output drive -- I'd probably go through an output PNP pullup stage to adjust the bipolar comparator output to TTL/CMOS levels. The other issue that I was looking for with the digital counter stages is that they are ripple counters (and worse yet, two in series), so the "output" number is not going to be valid after an input clock until all of the stages settle out. The "output" will be garbage during the rippling transitions, so whatever circuit this was being fed to would have to be carefully designed to accommodate this. A more real-world design would synchronize the output of the zero-crossing detector, and then use that synchronous signal to clock counters. The counters could be ripple counters, as long as they settle out in less than the internal clock period.

[G] Yeah, this is a dorked up version of the usual RS latch. The floating inputs are a mistake, and having two switches is a mistake, because what do the gates do if both buttons are pushed at the same time? The more traditional way to make a NOR latch is to pull both inputs to ground, and have a single-pole, multiple throw switch that can either pull up one input or the other. The switch needs to be a break-before-make type.

I have some pesky work stuff to take care of today, but I'll try to find something good to post tomorrow, maybe on synchronizing signals. In the mean time, it would be good to finish off the 555 circuit, if you folks have the time.

 

[ranger]

[G] Yeah, this is a dorked up version of the usual RS latch. The floating inputs are a mistake, and having two switches is a mistake, because what do the gates do if both buttons are pushed at the same time? The more traditional way to make a NOR latch is to pull both inputs to ground, and have a single-pole, multiple throw switch that can either pull up one input or the other. The switch needs to be a break-before-make type.

I have some pesky work stuff to take care of today, but I'll try to find something good to post tomorrow, maybe on synchronizing signals. In the mean time, it would be good to finish off the 555 circuit, if you folks have the time.

We will have a race condition when both of the inputs are activated simultaneously. This is basically saying that we cannot predict what the output would be.

I have another question, though not totally related to these circuits. If we take a TTL chip that has a totem pole (push-pull) output stage, why is it that it sinks current better than it sources? I assume by sourcing they mean when the output is HIGH and sinking is when the output is LOW? It still puzzles me, becuase if I look at the push-pull output stage, one transistor would be on at any given time (just ignore that very brief period when both are conducting and there is a path from +5V to gnd). When the output is HIGH, the transistor that is connected to 5V is conducting and when LOW the transistor that is connected to ground is conducting. I don't understand why the transistor connected connected to +5V cannot "source" current when compared to the one that is connected to ground.

 

[berkeman]

We will have a race condition when both of the inputs are activated simultaneously. This is basically saying that we cannot predict what the output would be.

Correct.

I have another question, though not totally related to these circuits. If we take a TTL chip that has a totem pole (push-pull) output stage, why is it that it sinks current better than it sources?

That's a good question, and probably better answered by someone else. But as I remember, the early TTL gates only used NPN transistors for some IC fabrication reason, so that makes the output drive asymmetric. The output stage is optimized for low quiescent current and clean output transitions, not for symmetry or pull-up strength. Contrast this circuit:

http://hyperphysics.phy-astr.gsu.edu/hbase/electronic/nand2.html

with the symmetric output stages shown in H&H in the section on "Push-pull output stages" (section 2.14 of the 1st edition).

With CMOS, they've used both n-channel and p-channel devices, and they generally size the p-channel (pullup) devices larger since they are weaker than the n-channel devices, so that you get symmetric drive.

 

[dlgoff]

"If we take a TTL chip that has a totem pole (push-pull) output stage, why is it that it sinks current better than it sources?"

Wouldn't it be because there's a collector resistor for the source transistor (push); causeing this asymmetric condition?

 

[berkeman]

Wouldn't it be because there's a collector resistor for the source transistor (push); causeing this asymmetric condition?

That would appear to be part of the problem as well. To fix it all, it looks like you would need to get rid of the phase splitter stage and add a PNP as the pullup stage (plus throw some other stuff in). Kind of like CMOS circuits, where the p-channel pullup and n-channel pulldown are driven with in-phase signals.

http://www.cs.umass.edu/~weems/CmpSci635A/Lecture2/L2.16.html


EDIT -- fixed broken link

.

 

[NoTime]

that is one fault yes...there is one more if you have a careful look...

Did you mean that as a fault?
In general, node marks don't seem to be all that consistently used for "T" connections, but if present then one is required for crossing lines to be connected.

Inever did much with 555s, but I only see one error that has to do with the potentiometer.
This could be corrected in the component callout.
They do make pots with stops and it has been my experience that they are not always marke as such on schematics.

 

[ranger]

That would appear to be part of the problem as well. To fix it all, it looks like you would need to get rid of the phase splitter stage and add a PNP as the pullup stage (plus throw some other stuff in). Kind of like CMOS circuits, where the p-channel pullup and n-channel pulldown are driven with in-phase signals.

www.cs.umass.edu/.../Lecture2/L2.16.html.

Berkeman, I'm getting a 404 on that link.

I've dispatched the question to one professors and I'm awaiting his response.

But I still have a question on the output stage: Let's assme the pull-up transistor is not conducting and the pull-down transistor is conducting. So since there is no path to +5V (pull-up transistor not conducting), what is the state of the collector on the pull-down transistor?
To get a visual of what I'm referring to, see H&H second edition, chapter 8; section 8.09 (IC gate circuits); Fig 8.17 (LS TTL NAND Gate).

Sorry for sidetracking this thread, I have no idea why this is suddenly bothering me. I guess its the entire source and sink thing.

 

[dlgoff]

"...what is the state of the collector on the pull-down transistor?"

Well the sink current is getting it's potential from some where (maybe the +5V). So there should be a potential on the collector depending on the load resistance of the source. If the transister is saturated, wouldn't the potential be ~0.2V?

 

[berkeman]

Berkeman, I'm getting a 404 on that link.

I've dispatched the question to one professors and I'm awaiting his response.

But I still have a question on the output stage: Let's assme the pull-up transistor is not conducting and the pull-down transistor is conducting. So since there is no path to +5V (pull-up transistor not conducting), what is the state of the collector on the pull-down transistor?
To get a visual of what I'm referring to, see H&H second edition, chapter 8; section 8.09 (IC gate circuits); Fig 8.17 (LS TTL NAND Gate).

Sorry for sidetracking this thread, I have no idea why this is suddenly bothering me. I guess its the entire source and sink thing.

Sorry about the broken link -- I used google images to find one, and didn't copy the link correctly. I think I've fixed it in my post, and here it is:

http://www.cs.umass.edu/~weems/CmpSci635A/Lecture2/L2.16.html

On your question about the pull-down transistor, dlgoff has it right. The bottom transistor will be close to saturated, and the pull-down current is just whatever the external load (the next gate's input or whatever) is supplying at that low voltage.

 

[ranger]

Ah yes, it sort of makes sense now. However (to quote dlgoff) "sink current is getting it's potential from somewhere (maybe the +5V)". It seems that it is hinted that the top of the collector (for pull-down transistor) is connected to +5V. But remember that the pull-up transistor is not conducting, so where is the pull-down transistor getting its +5V from in order to go into saturation? From the potential of the external load?

 

[berkeman]

Yes, from the external load. Just think of two of these gate schematics in series... The output totem pole of the first gate circuit is driving the input emitters of the 2nd gate.

 

[berkeman]

Okay, sorry for the delay. The answers to the previous H&H bad circuit were given in post #141.

I want to post an example of a bad circuit that deals with asynchronous signals and synchronous (clocked) processing of them. H&H doesn't have one that I see, so I searched a bit and found the one below, which should be okay for our discussion. I could sketch something up in OrCAD, but let's see if we can get through all the issues using this circuit.

This circuit is from a pretty useful paper at kplabs.org:

http://klabs.org/richcontent/Tutorial/MiniCourses/Logic_Course.ppt#98

No fair reading it until we work through this Bad Circuit. The intended use of the circuit is to bring an asynchronous signal (like a debounced pushbutton signal) into a PAL or FPGA circuit for further processing, like counting the number of events, or timing the delay between events. What issues do you see with this circuit here, and how would you fix them?

Remember, if you know the answers right away, please hold back a bit to let folks who are learning give it a try.

 

[berkeman]

Well, I've let this last circuit sit for a bit (hey, I'm pretty busy too at times at work, with little time to spend here on the PF), but we need to close out this synchronizer quiz question within the next week (even if I have to post the solution myself).

Let me help the motivation a bit. If you interview at the company I work for, or pretty much any other company in Silicon Valley (and hopefully elsewhere), you *will* get asked at least one question about synchronizing signals between different clock domains. That means synchronizing a totally asynchronous signal into a clocked domain like into a uC, or between different clock domains within one ASIC.

We were just discussing this issue in a design review meeting today at my work, trying to figure out how to handle some corner cases in a new mixed signal ASIC design. You all will for sure need to understand this technical issue in your future work, and you will for sure get asked about it when you interview, at all levels of EE work.

So for the student EEs, please read the link I provided in my question, and post your thoughts. If none of the students active in this thread post an answer by next weekend, it's okay for the working EEs to give some more explicit hints and search words.

 

[antonantal]

The intended function of the circuit would be to generate a strobe signal which is '1' at each rising edge of the system clock which is preceded by a rising edge of the "EVENT" signal?

 

[antonantal]

If so, then it doesn't work as intended. Assuming that when the "EVENT" signal goes high, it stays so more than about one period of the system clock, the circuit will behave like this:

The rising edge of the "EVENT" signal will put the output of the first D flip-flop high, then, at the first rising edge of the system clock the output of the second D flip-flop (which has it's input linked to the output of the first one) will go high. At this moment the rising edge of the "EVENT" signal has been synchronized with the system clock, and the output of the second flip-flop should go low after one period of the system clock. In order to do this, the output of the second flip-flop is linked to the CLR input of the first flip-flop in such a way that the first flip-flop is cleared when the output of the second one is '1' or "SYSRESET" is '0'.
But although after one period of the system clock the output of the second flip-flop will go low, "EVENT" is still high (because it lasts more then one period of the system clock) and the first flip-flop will go high again, causing an unwanted '1' at the output of the second flip-flop at the next rising edge of the system clock.

 

[berkeman]

There's actually a more fundamental issue with this circuit. Think about what a flip-flop looks like in terms of the gates inside it, and what kind of specifications are on a flip-flop's datasheet...

 

[antonantal]

Is it that the "EVENT" signal may not be suitable as a clock signal (it might not meet the maximum rise/fall time restrictions)?

 

[berkeman]

Is it that the "EVENT" signal may not be suitable as a clock signal (it might not meet the maximum rise/fall time restrictions)?

That's a good thought. The datasheet for a flip-flop (whether a discrete FF or a FF cell in an ASIC or CPLD or FPGA) will have several specifications that need to be met for valid operation to be ensured. Rise and fall times are part of the specs, and need to be considered, so yes, the transition speed of the incoming signal needs to be considered. If it is too slow, then a Schmidt trigger gate should buffer the signal, as we discussed in this thread way back somewhere. So your thought is a good one.

But there is still another set of specs on FF datasheets that apply to this problem, and lead to the general issue of synchronizing asynchronous signals into a clocked system (or transfering signals from one clock domain to another clock domain). Take a look at a FF datasheet, and look for other specs that have to do with timing... Once you see some specs related to timing, ask yourself how an asynchronous signal might violate those specs, and think about how you could handle that violation somehow (that last one is the trick part -- not tricky part, trick part).

 

[antonantal]

I think I finally got it. The setup time restriction might not be met at the second flip-flop. At the first flip-flop it is not the case because it's input is always at +Vcc, but the input of the second flip-flop might change at a time less than $$t_{SU}$$ before the rising edge of the system clock. This will cause the flip-flop to enter a metastable state in which the output oscillates between '1' and '0', and will take some time to settle down. This could be solved by adding another D flip-flop with it's input to the output of the second one and the clock input to the system clock. This way we give the second flip-flop a time of one clock period to settle down from the metastable state.

 

[antonantal]

I guess it also applies to FPGA circuits. I have recently worked with an FPGA circuit on a school project, which involved reading data from a PS2 keyboard. The keyboard has a clock and sends the data serially, each bit being valid on the negative edge of the keyboard clock. So I had to detect the negative edge of the keyboard clock and synchronize it with the system clock. I didn't take into account the setup time and I can recall that sometimes it didn't detect the key I pressed. At that time I thought that the keyboard was bad but now I think this was the problem.

 

[itstoast]

Whenever I read a schematic or written discription I assume that there are mistakes.

 

[berkeman]

I think I finally got it. The setup time restriction might not be met at the second flip-flop. At the first flip-flop it is not the case because it's input is always at +Vcc, but the input of the second flip-flop might change at a time less than $$t_{SU}$$ before the rising edge of the system clock. This will cause the flip-flop to enter a metastable state in which the output oscillates between '1' and '0', and will take some time to settle down. This could be solved by adding another D flip-flop with it's input to the output of the second one and the clock input to the system clock. This way we give the second flip-flop a time of one clock period to settle down from the metastable state.

Excellent! That's exactly the issue that I wanted to highlight with this circuit. When you have an asynchronous signal (like a button press, or a receive data line in a communications system) that you want to bring into a clocked system for processing, you must invest at least two FFs in series to synchronize the signal to the internal clocks.

The usual way you would do it is to bring the asynchronous signal into the D input of the first FF, and the Q output of that FF goes into the 2nd FF's D input. Both FFs are clocked by the system clock. The output of the 2nd FF is what you would use inside the clocked processing circuitry.

The issue is indeed the metastability that can be caused when the setup or hold times for the FF are violated, which can happen easily with an asynchronous input signal. So there is a finite probability that the first FF will have its output go metastable at times, but FFs are also rated by how long it is likely that the metastable state will persist. And usually, the probability that the output of the first FF will be wrong by the time the next clock comes along, is very low. That is, even if the first FF goes metastable, it is likely that its output will be correct for the next clock cycle, so the setup and hold times of the 2nd FF will be met, and it will not go metastable. But, if the clock rate is very high, and the FFs are not super-fast themselves (which shortens the metastability relaxation time), then you might need to series connect 3 FFs as the synchronizer, instead of the more typical two FFs.

Good job antonantal. BTW, there is a good discussion of all of this in the paper that I referenced with this Bad Circuit post (post #152).


EDIT -- I'll look around a bit for another good Bad Circuit to post. Work has been very hectic lately, so it may take me a couple days.

 

[berkeman]

Actually, I think I'm going to un-stickie this thread for now, and let it slip away...

It's been a good thread, but I'm pretty hammered at work right now, so I won't be able to spend much more time on the thread. Thanks for all the contributions folks!

 

[dlgoff]

Shoooot.

But thanks for being there.

 

[antonantal]

I have really learned some things here. It has been a great thread. Thanks!