# Help with designing falling edge detector using a state machine

Using a state machine, I designed a circuit that detects the falling edge of a signal (working with positive edge clock), but my circuit has one more not gate than the circuit shown in this document:

Here is what I did:

1. Drew the waves, with trig being the input signal and pulse being the output signal.

2. Drew a mealy state machine.

3. Made a table which describes everything:

4. Wrote the Boolean expressions for Q_next and pulse (a karnaugh map was not necessary for pulse).

5. And finally, the circuit:

I also wrote a VHDL code and a testbench and I see it is working (will attach if necessary, don't want to make the post too long).

So, this works, but I think one big mistake here is that I'm assuming the signal trig starts at '1'. I mean, if it were to start at '0' (and my initial state is S0), then pulse would be '1'. But, if I were to add another state, it would add a second FF.

So, what did I do wrong that I have an extra not gate?

Well since your circuit does perform its intended function, I'd say by definition you didn't do anything "wrong". But I think solving this problem with a state machine is unnecessarily complex, and a more intuitive approach does yield the circuit shown in your link.

Rather than a "state machine" approach I'd say it's far better to use a "plain English" approach -- clearly define what your circuit needs to do, then implement that description in circuitry.

• A Falling Edge Detector needs to output a '1' pulse whenever the input makes a high-to-low transition.
• To put this in more logic-friendly terms, a Falling Edge Detector needs to output a '1' whenever the current value of the input is low, and the previous value of the input is high.

If you look at the Cypress circuit, that's exactly what it's saying: there is an AND gate which fires when the present value is low and the previous value is high.

We can also translate your circuit into "plain English" and see that the output is '1' when the present value is low and the previous-value-of-the-inverted-input is also low. With a bit of reasoning you can see that this is the same thing, just expressed in a more complex fashion.

Style Points: having any signal, input or output, last for less than one full clock cycle is a Cardinal Sin of good synchronous logic design and should be avoided at all costs. Having these types of asynchronous signals means that you cannot guarantee proper setup/hold times for the downstream logic, and so you can encounter erratic behavior that is practically impossible to track down and fix. I'm really surprised that Cypress let this into a document that they published.

EDIT

@Eran asked if would be okay to run the async signal into the FF enable pin, as he's seen on multiple sites. This still violates the principles of good synchronous logic design, and yes I would go so far as to say that all those sites are wrong.

When designing synchronous digital logic circuits (really anything involving clocked flip-flops) it is best to be VERY religious about having all signals being properly clocked to avoid having to deal with intermittent, weird failures. If you're dealing with signals from the outside world which aren't synchronized to your clock, then run them through a synchronizer (typically two FFs in series) to line them up to your clock. This will minimize the chance of metastability, but it can never be eliminated.

A nice overview is here: https://web.stanford.edu/class/ee183/handouts/synchronization_pres.pdf. Direct quote from that document: "Synchronization failure is deadly and difficult to debug." So yes it's best to be methodical from the outset and avoid the need to debug it.

For "hobbyist" designs people probably just choose to live with these and hit the RESET button occasionally. For professional, robust designs good synchronous logic design principles are a must.

• Thanks for your answer, it gave me a new perspective on how to approach these kind of questions. But, is there any way you could show me if there was some mistake in what I did, or a better way to do that (not including the plain English approach of course)? Maybe my state machine was wrong? Commented Feb 23, 2019 at 9:55
• Also, about your last comment (style points) - if that differentiated signal is inputted into the enable pin of a FF, is it still wrong? Because I saw those circuits in a lot of sites. Commented Feb 23, 2019 at 9:57
• Ignore my request to show me what I did wrong, someone already answered this. Would just appreciate an answer on my last comment, thanks! Commented Feb 23, 2019 at 16:00
• @Eran see my edit above. Commented Feb 23, 2019 at 19:43

It’s simply a matter of state numbering. Invert your state designation and you will have the exact same circuit.

Note that the state number selection is completely arbitrary.

You can see this just by doing some “schematic algebra” moving the inverter before the FF does not change the behavior of the circuit, and it leads to an obvious simplification.

• Wow, I can't believe this worked. Is there some way I could have known this before I started designing this? It's just very weird that naming states in a different way results in less logic gates... Commented Feb 23, 2019 at 11:16
• @Eran I don’t remember coming across any formal methodology for this and this seems to be an active area of research (ac.els-cdn.com/S1474667016324417/…). It’s something that simply comes from experience. I call it schematic algebra, you can just move components around using the rules of logic. In this case, it’s rather trivial to see that moving the inverter before the FF did not alter the circuit. Commented Feb 23, 2019 at 11:25