State Machine with single cycle pulsed outputs?

[Brian Drummond]

On Thu, 25 Sep 2008 10:29:53 -0700 (PDT), "M. Norton"
<remillard@gmail.com> wrote:

My only question is, do synthesizers respect this distinction between
variable and signal updates and generate appropriately?

Mostly.

Xilinx ISE has problems when the signals are updated in a procedure
called from the process, rather than the process body itself, but
otherwise, yes.

- Brian

 

[M. Norton]

On Sep 25, 4:29 pm, Brian Drummond <brian_drumm...@btconnect.com>
wrote:

I like the basic approach in Jonathan's example, for clarity.

I do too and might start working that into the next development,
though I think I also like the addition of a current_state signal in
addition to next_state variable.

But, it looks very readable and maintainable.

And thank you and Kevin for the RTL/synthesizing notes. It is
encouraging to have language features actually be of some concrete use
other than just syntactical scenarios. Another prod to try this out
sometime and see how it works.

Mark

 

[Andy]

On Sep 25, 12:29 pm, "M. Norton" <remill...@gmail.com> wrote:

On Sep 25, 10:05 am, s...@oxfordbromley.plus.com wrote:

Your example shows two case statements, you set output
signals in each one but there is no rationale for why the output that
you came up with called 'Running' should not be set in the first case
statement along with the other outputs 'Start' and 'Stop'

Yes there is!  That's the whole point!  Given that I've defaulted
all the outputs to false at the top of the process (often a good
idea, because in my experience FSMs tend to have fairly sparse
outputs) the outputs that are written in the "transition" case
statement will be asserted for one clock on the transition, and
the outputs that are written in the second case statement will
be asserted for the whole time the FSM is in the chosen state.

Alright, I've been following this because typically for RTL I rarely
use variables.  I have had, in the past, issues where I want signals
asserted at state transitions and, using signals, it requires some
jiggerypokery and has never been as entirely clear as I liked.  So
this is interesting stuff to see the difference.  I knew there had to
be something more clever than my edge detect ;-).

So I can see that we get the pulse asserted on the rising clock edge
for one cycle, and running also starts on the rising clock edge,
everything seems nicely synchronous.

My only question is, do synthesizers respect this distinction between
variable and signal updates and generate appropriately?

Best regards,
Mark Norton

I appreciate JB's two-case-statement approach, and for some complex
state machines, it would be very beneficial. I have from time to time,
to make the cycle-based timing work out, needed to specify an output
in every transition to a given state, and on large/complex FSMs, JB's
example is a better way, while still having registered outputs.

As to the synthesis tool's treatment of the differences between
variable and signal update behavior, yes, most tools handle it fine. I
use Synplify for most of my work, and have had only one problem, a
couple of years ago, that was quickly fixed. The way I see it, a
synthesis tool's job is to create hardware that will, on a clock cycle
basis, replicate the behavior of the RTL code. Most tools ignore the
impact of sensitivity lists, but other than that, do a pretty good
job.

To me, variables represent the most flexible way to represent cycle-
based behavior. If the behavior has a clock cycle delay, then the
hardware will too (by using a register). If not, it won't. We
typically think of any signal assigned in a clocked process as being
registered. With variables, it is the reference to the variable,
relative to when it was last written, that determines a registered or
combinatorial implementation. In JB's example, the first case
statement's reference to 'state' is registered, since state was not
previously assigned in that clock cycle (forcing storage of previous
value, accomplished with the register). References to state in the
second case statement are combinatorial, because state may have been
updated, and at least a mux is required to choose between the input
and output of the state register. Note that even in those situations
where state is not explicitly assigned in the first case statement,
the second case statement uses the same next state logic (feedback
mux) that was implemented for the first case statement.

Andy

 

[Analog_Guy]

On Sep 25, 2:07 am, s...@oxfordbromley.plus.com wrote:

On Sep 24, 5:42 pm, Analog_Guy <analog_...@hotmail.com> wrote:

Is there an easy method of creating a state machine to output control
signals that are only one clock cylce wide (i.e. upon entering a
state), no matter how long the state machine resides in that single
state?  I like to use pulsed "start" and "stop" commands to control
functionality in other processes.

This is another reason for using a state variable: this kind of thing
is elegant and easy to code.  Here's a very simple FSM with 2 states.
There's an idle (do-nothing) state, and a Run state.
When in Idle you stay there until you see the Go input
asserted; then transition to Run.  At this point you would like
a Start output asserted for just one clock, but you also have
a Running output that remains asserted all the time you're in Run.
You then wait until Go becomes false; at this point you transition
back to Idle and assert a Stop signal for one cycle.  Here's the
code (many declarations missing):

  process (Clock) is
    variable state: state_type; -- enum (Idle, Run)
  begin
    if rising_edge(Clock) then
      if Synch_Reset='1' then
        state := Idle;
        Start <= '0';
        Stop <= '0';
        Running <= '0';
      else
        -- All outputs are defaulted here.
        Start <= '0';
        Stop <= '0';
        Running <= '0';
        -- Transition actions, compute next-state
        -- and single-clock (edge detect) outputs
        case state is
          when Idle =
            if Go = '1' then
              state := Run;
              Start <= '1'; -- asserted for 1 clock only
            end if;
          when Run =
            if Go = '0' then
              state := Idle;
              Stop <= '0'; -- asserted for 1 clock only
            end if;
        end case;
        -- Now "state" contains the next-state value,
        -- use it to compute Moore (state-dependent) outputs
        case state is
          when Run =
            Running <= '1';
          when others =
            null;
        end case;
      end if;
    end if;
  end process;

No edge detectors, no extra states, just a clear
distinction between things that happen on a
state transition and things that happen when
you're in a certain state.

It works for me; YMMV.
--
Jonathan Bromley

Thanks for the response. That definately defines what I am trying to
accomplish. I'll have to do a little more reading on the
one/two/three process state machine implementations and the use of
variables. Up until now, I have used HDL Designer to graphically
define SMs (three process approach). However, now I am moving to a
fully text based approach. Thanks again for the help.

 

[Mike Treseler]

Analog_Guy wrote:

Is there an easy method of creating a state machine to output control
signals that are only one clock cylce wide (i.e. upon entering a
state), no matter how long the state machine resides in that single
state?

Maybe that is an edge detector.
For a related example see the procedure 'rising' here:
http://mysite.verizon.net/miketreseler/rise_count.vhd

-- Mike Treseler

 

[m]

On Sep 24, 9:42 am, Analog_Guy <analog_...@hotmail.com> wrote:

Is there an easy method of creating a state machine to output control
signals that are only one clock cylce wide (i.e. upon entering a
state), no matter how long the state machine resides in that single
state?  I like to use pulsed "start" and "stop" commands to control
functionality in other processes.

Just assert your control signal when you make the decision to change
states. De-assert it immediately upon entering the state. It doesn't
have to be any more complicated than that. If you want the control
signal to happen one clock cycle after entering the new state simply
run it through a F/F.


-Martin