Latching Start Circuit using Flip Flops

MR -- you might get something useful from my 'blog "First Experiments with the ValentF(x) LOGI-Pi", specifically section "Experiment 2".  That section has a design for a 4-bit binary counter with reset and hold, written in Verilog.

As clem57 says, for CPLDs and FPGAs you probably want a clocked state machine with an oscillator providing a clock.  Usually oscillators are really fast, so you'll need to divide down to something reasonable.  My example has a 50 MHz oscillator, since that's what comes with the LOGI-Pi.  But you can make something a lot slower, perhaps with an LMC555 timer.

The actual counter update is very simple in Verilog:

always @(posedge Mclk or posedge reset)

if (reset) K <= 0; else if (clk4Hz) K <= K+up;

This says if the 50MHz master clock Mclk has a positive edge (rises) or the asynchronous reset has a positive edge, execute the if statement.  If reset is high, clear the counter state K to 0, otherwise if clk4Hz is high (it pulses for one cycle every 1/4 second) update K to K+up where up is the counter enable (connected to a push button).  The + operator is addition: logical OR is the | or || operator from C.  If reset=0 and clk4Hz=0 leave K as it is.

The vendor's synthesizer does the logic minimization so you don't ever see K-maps or excitation tables and all that great theory from your undergrad days.

You do need to be concerned about switch bounce.  I ignored it in my example because K only updates at 4 Hz and the chances of updating K exactly when you press or release a button is so slight that you probably won't see it in practice.  In a serious circuit that controls something real like solenoids you do need to be concerned.

Hope this helps!

The CPLD is clocked at 10MHz using a VCO which I need because I plan to run a timer and so forth... but I don't really want the state machine to be paused by removing the clock source, instead I want to control it via start and stop buttons, in addition to having it automatically stop when it reaches its last state. I'm not sure what Clem means when he says a full logic reset is needed to restart - that sounds like something I want to avoid because I want to pause then continue, not pause then restart... or maybe I'm misunderstanding   but I will take a look at the reference you made, John.

Here's some VHDL which might give you some ideas. Life's too short to simulate this in the Quartus horror (when you've got something better which I have) so you'll need to bite that bullet yourself. It seems to mainly work (ie all the bits I tested worked !).

It uses 39% of the logic in your 160 ff CPLD so you may be needing to use a bigger one.

Get back to me about the bits that don't make sense.

All comments and criticisms of my VHDL style welcome (from whatever source). Please note (in said style) the single process not obviously Mealy or Moore state machine -works for me and Synplfy gets it.

MK

Here's some VHDL which might give you some ideas. Life's too short to simulate this in the Quartus horror (when you've got something better which I have) so you'll need to bite that bullet yourself. It seems to mainly work (ie all the bits I tested worked !).

It uses 39% of the logic in your 160 ff CPLD so you may be needing to use a bigger one.

Get back to me about the bits that don't make sense.

All comments and criticisms of my VHDL style welcome (from whatever source). Please note (in said style) the single process not obviously Mealy or Moore state machine -works for me and Synplfy gets it.

MK

Thanks for taking the time do dot his Michael. I have not tested the code yet because I plan to work the ideas into my project but it seems to me that with a minor modification to enable automatic abort from state2, this will work...

1.) I am not clear on this line: sm_timer <= (others => '0'); I think we are saying that we assign (others => '0') to sm_timer and that all bits will be 0 because we set nothing else i.e. we did not say something like ('1', '1', others => '0') which would yield '11000'?

2.) Are you using the button_count to check that buttons have been in the same state for some time to act as a debouncer?

4.) Explain why we don't need to reset the timer to zero: Okay, here is my stab... the state machine will process state1 and state2 every 1ms (because although sensitised to the main clock, we use an if statement to process the state machine every 1ms). Because we will only move state when sm_timer reaches "111111", then the next time into the state machine this unsigned sm_timer has wrapped to 0 and so when we finally arrive at state2, sm_timer is 0. the process being clocked means that all these assignments happen at the same time and so we know that the sm_timer will wrap in state1 and we will also assign state2 when in state1 - therefore on the next clock cycle we will be in state2 with sm_timer at 0.

Hi,

1) The (others => '0') is a good way of setting  a register to zeros and avoids all that tedious counting of how many zeros you've typed, 8 isn't so bad but 96 can get very tiring

2) Yep, button_count is for debounce

3) I think you've got it - it often causes brain fade - the thing is that although we've passed the line that adds 1 to the sm_timer it doesn't actually happen until after everything else that clock cycle.

The state machine itself is just a demo of how it can be done - you can easily add more states or make them do something useful.

Have fun.

MK

  the code provided by Michael worked for me after I changed the logic states for the switches (the bits needed negating for my board). I will next move onto making the state machine stop at the end of its cycle. I was hoping to post a small video to demonstrate the behaviour but it seems there is something wrong with the video upload Or is it just me?

Did I miss something? Where is the logic for the state machine? Does it use a clock?

Clem

Edited: Ok see it now as attached.

Clem Martins wrote:

 

Did I miss something? Where is the logic for the state machine? Does it use a clock?

Clem

Edited: Ok see it now as attached.

I couldn't see the attachment when viewing the discussion in the "Inbox and Activity" page.  I had to open the discussion in a new tab (or window) to see the attachment.

oldmanraskers wrote:

 

4.) Explain why we don't need to reset the timer to zero.

I didn't look at the code for MK's specific example, but here's a general principle:  When you design a finite state machine (FSM), it's always a good idea to have it "self-resetting", that is, if it initializes into an invalid state or somehow gets into an invalid state due to gremlins you want to be sure the state update logic quickly gets into a valid state so your design doesn't lock up and require manual reset.

This may require you to do some extra analysis to make sure your invalid states don't lock up, and you may need to add some extra logic to get it to do the right thing.  When I design FSMs for FPGAs, I always do the state assignment (i.e., state encoding) by hand because I have no confidence that the synthesizer will do the right thing.  I also avoid "one hot" coding, because it's way too easy to end up with zero FFs set (not in any state) or with multiple FFs set (in several states at once).  "One hot" coding is great if you have to wire-wrap your state machine by hand using 7400-series logic.  When you have a nice synthesizer that does your logic minimization for you, dense coding works out quite nicely.

Verilog lets you #define symbolic names for your states, which keeps the source code understandable.

JMO/YMMV

Here's the simulation I did and the testbench that drove it. Simulation in Aldec ActiveHDL, The 1mS time was reduced to 100uS to reduce the simulation cycles.

There is an attachment as well as the embedded picture !

MK

Hi John,

I don't think we'll ever agree on this so I'm not trying to convert you

When I design FSMs for FPGAs, I always do the state assignment (i.e., state encoding) by hand because I have no confidence that the synthesizer will do the right thing.  I also avoid "one hot" coding, because it's way too easy to end up with zero FFs set (not in any state) or with multiple FFs set (in several states at once).  "One hot" coding is great if you have to wire-wrap your state machine by hand using 7400-series logic.  When you have a nice synthesizer that does your logic minimization for you, dense coding works out quite nicely.

With the tools I use and the state machine template I prefer there is no visibility at the VHDL level of the flip flops. Synplify (for those who don't know that's the software I use to translate the VHDL into gates for an FPGA) generally uses one hot although you can force it not to. I don't because it's never failed me (in dozens of designs) yet.

I always code to deal with the invalid states (although Synplify optimizes it out because with one-hot you can't get there) and I agree it's essential to initialize correctly.

I don't have  a VHDL lint equivalent (they exist but not cheap) but I think the thing I would like most is warning about un-initialized things.

MK

Michael Kellett wrote:

 

I don't think we'll ever agree on this so I'm not trying to convert you

My one experience with one-hot coding was when I was first designing with FPGAs.  The particular design used a clock edge to set a flip-flop, and that clock came from a fiber optic receiver.  It simulated beautifully, except that I was aghast that simulation technology hadn't improved in the decades since I had last used someone else's simulator.

When I got the board back, the FPGA worked perfectly -- at first.  Then I tried pulling and inserting the fiber optic cable a few times and found that sometimes the circuit went dead.  It turned out that sometimes when I pulled the cable I'd get a short clock pulse -- long enough to clear the hot flip-flop but too short to set the next flip-flop, so I'd end up in an invalid state that I couldn't recover from without reset.

Yes, it was a clock pulse-width violation, but the simulator couldn't catch it -- a simulator only simulates the test cases you've thought of, and not the many ones you didn't think of.

So I switched to a self-resetting dense coding, which also saved a bunch of LUTs.  I also decided that using other people's simulators was pretty much a waste of time and I rarely use simulation.   I don't expect anyone to agree with me on this eccentricity.  They're welcome to write test benches for my Verilog and try to find bugs I've missed.

JM(eccentric)O / YM(will most likely)V