Bad Circuits - Test Your Knowledge

[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!