state machine reset

Hi all,

I'm new to vhdl and trying to reset a state machine to state 0 when
the incoming signal x changes state. How can I combine the two
processes below and not resulting in multiple sources error?

process (clk, rst)
begin
if rst = '1' then
state <= s0;
elsif rising_edge (clk) then
state <= next_state;
end if;
end process;

process (x0, x1)
begin
state <= s0;
end process;

Thanks...

yiipee@gmail.com wrote:
> process (x0, x1)
> begin
> state <= s0;
> end process;

process (x0, x1)
begin
next_state <= s0;
end process;

Presumably there is other logic in your process you're not showing us.

-Jeff

well... I didn't show the part of state assignment. I need to design a
2-bit counter that will reset to s0 if x0 and x1 change their state.
Here is the complete code what I have but it's not working.

process (clk, rst)
begin
if rst = '1' then
state <= s0;
elsif rising_edge (clk) then
state <= next_state;
end if;
end process;

process (sel0, sel1)
begin
state <= s0;
end process;

process (state)
begin
case state is
when s0 =>
y <= '1';
next_state <= s1;
when s1 =>
y <= '1';
next_state <= s2;
when s2 =>
y <= '1';
next_state <= s3;
when s3 =>
y <= '0';
next_state <= s3;
end case;
end process;

corrected the code as below:

> well... I didn't show the part of state assignment. I need to design a
> 2-bit counter that will reset to s0 if x0 and x1 change their state.
> Here is the complete code what I have but it's not working.
>
> process (clk, rst)
> begin
> * *if rst = '1' then
> * * * state <= s0;
> * *elsif rising_edge (clk) then
> * * * state <= next_state;
> * *end if;
> end process;
>
> process (x0, x1)
> begin
> * *state <= s0;
> end process;
>
> process (state)
> begin
> * *case state is
> * * * when s0 =>
> * * * * *y <= '1';
> * * * * *next_state <= s1;
> * * * when s1 =>
> * * * * *y <= '1';
> * * * * *next_state <= s2;
> * * * when s2 =>
> * * * * *y <= '1';
> * * * * *next_state <= s3;
> * * * when s3 =>
> * * * * *y <= '0';
> * * * * *next_state <= s3;
> * *end case;
> end process;

On Aug 14, 12:16*pm, yii...@gmail.com wrote:
> corrected the code as below:
>
>
>
> > well... I didn't show the part of state assignment. I need to design a
> > 2-bit counter that will reset to s0 if x0 and x1 change their state.
> > Here is the complete code what I have but it's not working.
>
> > process (clk, rst)
> > begin
> > * *if rst = '1' then
> > * * * state <= s0;
> > * *elsif rising_edge (clk) then
> > * * * state <= next_state;
> > * *end if;
> > end process;
>
> > process (x0, x1)
> > begin
> > * *state <= s0;
> > end process;
>
> > process (state)
> > begin
> > * *case state is
> > * * * when s0 =>
> > * * * * *y <= '1';
> > * * * * *next_state <= s1;
> > * * * when s1 =>
> > * * * * *y <= '1';
> > * * * * *next_state <= s2;
> > * * * when s2 =>
> > * * * * *y <= '1';
> > * * * * *next_state <= s3;
> > * * * when s3 =>
> > * * * * *y <= '0';
> > * * * * *next_state <= s3;
> > * *end case;
> > end process;- Hide quoted text -
>
> - Show quoted text -

Hi
Still in above code, many things are missing... what is sel0/1? in
state s3 again next state is s3..
any way i guess u can write
process (clk, rst)
begin
if rst = '1' then
state <= s0;
elsif rising_edge (clk) then
if change_state(sel0/sel1) then --not sure what you mean by
change state ..whether 0-> or 1-->
state <= s0;
else
state <= next_state;
endif;
end if;
end process;

regards
Sandeep

On Aug 13, 6:03 pm, yii...@gmail.com wrote:
> Hi all,
>
> I'm new to vhdl and trying to reset a state machine to state 0 when
> the incoming signal x changes state. How can I combine the two
> processes below and not resulting in multiple sources error?
>
> process (clk, rst)
> begin
> if rst = '1' then
> state <= s0;
> elsif rising_edge (clk) then
> state <= next_state;
> end if;
> end process;
>
> process (x0, x1)
> begin
> state <= s0;
> end process;
>
> Thanks...

I think one of the things that is confusing you is the way you
separate the sequential process from the combinatorial process. There
is no real reason to do that. It seems that this is a coding style
that is often taught in school, but seldom used in practice. I have
never found a reason to code this way and this is the way I started
out coding. It didn't take me long to change to using a single
process to describe state machines, counters and such.

So instead of using logic to define next_state, just replace
next_state in the sequential process with the statements from the
combinatorial process. It should look like this...

process (clk, rst)
begin
if rst = '1' then
state <= s0;
elsif rising_edge (clk) then
state <= s0;
if change(sel0, sel1) then
state <= s0;
else
case state is
when s0 =>
y <= '1';
next_state <= s1;
when s1 =>
y <= '1';
next_state <= s2;
when s2 =>
y <= '1';
next_state <= s3;
when s3 =>
y <= '0';
next_state <= s3;
end case;
end if;
end process;

Your code won't work because you are assigning state in two
processes. That is like tying the output of a flip-flop and a gate
together. You can't have two outputs on the same signal (unless one
is tri-stated).

This is a counter that can be reset at any point in the cycle. It
will count up to three and wait. But it can be reset in state 1, 2 or
3. Is that your intent or do you mean for it to count to 3 and *then*
wait for a reset? If the reset comes early when the machine is in one
of the other states, do you still want it to reset or continue to
state 3?

Rick

On Aug 14, 7:22 am, rickman <gnu...@gmail.com> wrote:
> On Aug 13, 6:03 pm, yii...@gmail.com wrote:
>
>
>
> > Hi all,
>
> > I'm new to vhdl and trying to reset a state machine to state 0 when
> > the incoming signal x changes state. How can I combine the two
> > processes below and not resulting in multiple sources error?
>
> > process (clk, rst)
> > begin
> > if rst = '1' then
> > state <= s0;
> > elsif rising_edge (clk) then
> > state <= next_state;
> > end if;
> > end process;
>
> > process (x0, x1)
> > begin
> > state <= s0;
> > end process;
>
> > Thanks...

Put the inputs in the sensivity list of the third process and delete
the second process. Then you have one sequential process for the
states that only depends on clk and rst and one combinational process
that depends on the current state and the inputs. Also called 2-
process FSM in my textbook.

>
> I think one of the things that is confusing you is the way you
> separate the sequential process from the combinatorial process. There
> is no real reason to do that. It seems that this is a coding style
> that is often taught in school, but seldom used in practice. I have
> never found a reason to code this way and this is the way I started
> out coding. It didn't take me long to change to using a single
> process to describe state machines, counters and such.

Yes, 2-process state machines are very popular in teaching. Things get
structured and it is probably easier to correct the student works this
way :-) Maybe it is also more correctly reflecting the formal
definitions of Moore and Mealy machines and academic work must always
be of high academic quality regardless of its industrial usefulness.
Do professors actually write code?

The textbook that I have for reference does give tribute to the 1-
process FSM as it is quicker in simulation, but the designer has to
take care in which state outputs are asserted.

--
Svenn

Svenn Are Bjerkem wrote:

> Yes, 2-process state machines are very popular in teaching.

Maybe it is too much trouble to update
those lecture notes on the yellowed parchment

> Things get
> structured and it is probably easier to correct the student works this
> way :-)

It does provide a wider range of errors to correct.

> Maybe it is also more correctly reflecting the formal
> definitions of Moore and Mealy machines and academic work must always
> be of high academic quality regardless of its industrial usefulness.

Either model could be demonstrated on one process.
The question is, why demonstrate such a small
subset of what is possible?

Like mechanical cash register theory,
these models should be presented as a historical footnote,
not as a viable standard for logic description.

> The textbook that I have for reference does give tribute to the 1-
> process FSM as it is quicker in simulation, but the designer has to
> take care in which state outputs are asserted.

I have to do that in any case.

-- Mike Treseler

rickman schrieb:
>
>
> process (clk, rst)
> begin
> if rst = '1' then
> state <= s0;
> elsif rising_edge (clk) then
> state <= s0;
> if change(sel0, sel1) then
> state <= s0;
> else
> case state is
> when s0 =>
> y <= '1';
> next_state <= s1;
> when s1 =>
> y <= '1';
> next_state <= s2;
> when s2 =>
> y <= '1';
> next_state <= s3;
> when s3 =>
> y <= '0';
> next_state <= s3;
> end case;
> end if;
> end process;
>
Oha, this should pose some problems with synthesis. change(sel0, sel1)
can't be synthesized, and y converts maybe to a latch if you don't
reset. An "end if" is missing and next_state should be better a variable

My proposal:

process (clk, rst)
variable next_state : <sx_type>;

begin
if rst = '1' then
next_state := s0;
state <= s0;

elsif rising_edge (clk) then
if sel0 != sel0_old or
sel1 != sel1_old then
next_state := s0;

else
next_state := state;

case state is
when s0 =>
y <= '1';
next_state := s1;

when s1 =>
y <= '1';
next_state := s2;

when s2 =>
y <= '1';
next_state := s3;

when s3 =>
y <= '0';
next_state := s3;

when others =>
Null;

end case;
end if;

state <= next_state
end if;
end process;

Best regards

Wolfgang

On Aug 14, 3:48 am, Svenn Are Bjerkem <svenn.bjer...@googlemail.com>
wrote:
> On Aug 14, 7:22 am, rickman <gnu...@gmail.com> wrote:
>
> Put the inputs in the sensivity list of the third process and delete
> the second process. Then you have one sequential process for the
> states that only depends on clk and rst and one combinational process
> that depends on the current state and the inputs. Also called 2-
> process FSM in my textbook.

That still leaves the logic in the second process out of the
equation. Textbooks are for teaching, but often they don't teach the
best approach. FSM design is a very good example. Very few engineers
code a 2 process FSM in HDL. In the real world there is virtually no
advantage.


> > I think one of the things that is confusing you is the way you
> > separate the sequential process from the combinatorial process. There
> > is no real reason to do that. It seems that this is a coding style
> > that is often taught in school, but seldom used in practice. I have
> > never found a reason to code this way and this is the way I started
> > out coding. It didn't take me long to change to using a single
> > process to describe state machines, counters and such.
>
> Yes, 2-process state machines are very popular in teaching. Things get
> structured and it is probably easier to correct the student works this
> way :-) Maybe it is also more correctly reflecting the formal
> definitions of Moore and Mealy machines and academic work must always
> be of high academic quality regardless of its industrial usefulness.
> Do professors actually write code?


> The textbook that I have for reference does give tribute to the 1-
> process FSM as it is quicker in simulation, but the designer has to
> take care in which state outputs are asserted.
>
> --
> Svenn

On Aug 14, 3:48 am, Svenn Are Bjerkem <svenn.bjer...@googlemail.com>
wrote:
> On Aug 14, 7:22 am, rickman <gnu...@gmail.com> wrote:
>
>
>
> > On Aug 13, 6:03 pm, yii...@gmail.com wrote:
>
> > > Hi all,
>
> > > I'm new to vhdl and trying to reset a state machine to state 0 when
> > > the incoming signal x changes state. How can I combine the two
> > > processes below and not resulting in multiple sources error?
>
> > > process (clk, rst)
> > > begin
> > > if rst = '1' then
> > > state <= s0;
> > > elsif rising_edge (clk) then
> > > state <= next_state;
> > > end if;
> > > end process;
>
> > > process (x0, x1)
> > > begin
> > > state <= s0;
> > > end process;
>
> > > Thanks...
>
> Put the inputs in the sensivity list of the third process and delete
> the second process. Then you have one sequential process for the
> states that only depends on clk and rst and one combinational process
> that depends on the current state and the inputs. Also called 2-
> process FSM in my textbook.
>
>
>
> > I think one of the things that is confusing you is the way you
> > separate the sequential process from the combinatorial process. There
> > is no real reason to do that. It seems that this is a coding style
> > that is often taught in school, but seldom used in practice. I have
> > never found a reason to code this way and this is the way I started
> > out coding. It didn't take me long to change to using a single
> > process to describe state machines, counters and such.
>
> Yes, 2-process state machines are very popular in teaching. Things get
> structured and it is probably easier to correct the student works this
> way :-) Maybe it is also more correctly reflecting the formal
> definitions of Moore and Mealy machines and academic work must always
> be of high academic quality regardless of its industrial usefulness.
> Do professors actually write code?
>
> The textbook that I have for reference does give tribute to the 1-
> process FSM as it is quicker in simulation, but the designer has to
> take care in which state outputs are asserted.

Anyone who understands both HDL and state machines will find it
trivial to implement both Mealy and Moore FSMs. The one is just a
clocked process with outputs assigned only on state transitions and
the other is a clocked process for the state transitions and
combinatorial logic (either a process or concurrent statements) for
the outputs.

Many people use a modified Mealy (or is it Moore?) machine because it
is the simplest to code and all outputs are registered giving highest
clock speed.

Like I said, I don't typically use any of these. Being rooted in the
days of twiddling bits with a soldering iron and SSI logic, I tend to
think in terms of the logic and then code the HDL to describe the
logic. After all, that's what the D in HDL is for, right? So my FSMs
tend to be ad hoc and vary a lot. Often they are just counters.

Rick