Latching Start Circuit using Flip Flops

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