FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > VHDL

VHDL comp.lang.vhdl newsgroup / Usenet

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 09-12-2006, 08:26 PM
Dave Dean
Guest
 
Posts: n/a
Default A general rule for State Machines?

Hi all,
I've got a question about some alternate ways to implement a state
machine - in particular, when you may be in a state for several cycles -
I'll use a deserializer as my example here.

First, suppose a boring deserializer that needs to grab just one bit:

entity test is
port (
data_in : in std_logic;
clk : in std_logic
);
end test;

architecture one_bit of test is

type states is (idle, get_data);
signal state : states;
signal data : std_logic;

begin
process(clk)
begin
if (rising_edge(clk)) then
case state is
when idle => if (go='1') then state <= get_data; end if;
when get_data => data <= data_in;
state <= idle;
end case;
end if;
end process;
end one_bit;
---------------------------------
very simple. Now, suppose we need to deserialize TWO bits. Here's two
different changes to the SM that will do this:

architecture two_bits1 of test is

type states is (idle, get_data1, get_data2);
signal state : states;
signal data : std_logic_vector(1 downto 0);

begin
process(clk)
begin
if (rising_edge(clk)) then
case state is
when idle => if (go='1') then state <= get_data1; end if;
when get_data1 => data <= data(0) & data_in;
state <= get_data2;
when get_data2 => data <= data(0) & data_in;
state <= idle;
end case;
end if;
end process;
end imp;
--------------------------------------
architecture two_bits2 of test is

type states is (idle, get_data);
signal state : states;
signal data : std_logic_vector(1 downto 0);
signal counter : std_logic;

begin
process(clk)
begin
if (rising_edge(clk)) then
case state is
when idle => if (go='1') then
state <= get_data;
counter <= '0';
end if;
when get_data => data <= data(0) & data_in;
counter <= counter + 1;
if (counter='1') then
state <= idle;
end if;
end case;
end if;
end process;
end imp;
----------------------------
In the first example, I added a second "get_data" state to allow me to get 2
bits. In the second, I added a counter, so I could stay in the one
"get_data" state for two cycles. In this small example, I'm not sure which
implementation is better.
However, when you start getting significantly larger, like this 16-bit
example:

architecture 16bits of test is

type states is (idle, get_data);
signal state : states;
signal data : std_logic_vector(15 downto 0);
signal counter : std_logic_vector(3 downto 0);

begin
process(clk)
begin
if (rising_edge(clk)) then
case state is
when idle => if (go='1') then
state <= get_data;
counter <= (others => '0');
end if;
when get_data => data <= data(14 downto 0) & data_in;
counter <= counter + 1;
if (counter="1111") then
state <= idle;
end if;
end case;
end if;
end process;
end 16bits;
----------------------------------
Here, I think a counter will be better than adding 16 extra states. If you
use one-hot encoding, you'll be using a lot of extra resources with the
additional states (right?).

Anyway, this is a fairly simple example that I hope illustrates the larger
point. Does anyone have a good rule of thumb of when to use a counter and
when to add extra states? I suppose it can depend on the particular
situation (the extra states will usually be faster) but the counter is
certainly more flexible and elegent.

Thanks,
Dave


Reply With Quote
  #2 (permalink)  
Old 09-12-2006, 10:46 PM
Paul Uiterlinden
Guest
 
Posts: n/a
Default Re: A general rule for State Machines?

Dave Dean wrote:

> Anyway, this is a fairly simple example that I hope illustrates the
> larger
> point. Does anyone have a good rule of thumb of when to use a
> counter and
> when to add extra states?


My opinion: go for the implementation that shows the least code
duplication. This makes it more robust against introduction of bugs
when the implementation is changed. Using a counter certainly would
have my preference. It just makes the code easier to maintain.

--
Paul.

Reply With Quote
  #3 (permalink)  
Old 09-12-2006, 11:59 PM
Andy
Guest
 
Posts: n/a
Default Re: A general rule for State Machines?

Anytime I need to delay more than 3 or 4 clocks, I prefer to use a
counter. Plus, the length of the delay counter can be parameterized.

case state is
when start =>
state := waiting;
delay_cnt := WAIT_DELAY;
when waiting =>
if delay_cnt - 1 < 0 then -- for integer counters only!
state := go;
else
delay_cnt := delay_cnt - 1;
end if;
when ...
end case;

Andy


Paul Uiterlinden wrote:
> Dave Dean wrote:
>
> > Anyway, this is a fairly simple example that I hope illustrates the
> > larger
> > point. Does anyone have a good rule of thumb of when to use a
> > counter and
> > when to add extra states?

>
> My opinion: go for the implementation that shows the least code
> duplication. This makes it more robust against introduction of bugs
> when the implementation is changed. Using a counter certainly would
> have my preference. It just makes the code easier to maintain.
>
> --
> Paul.


Reply With Quote
  #4 (permalink)  
Old 09-14-2006, 01:17 PM
homoalteraiensis
Guest
 
Posts: n/a
Default Re: A general rule for State Machines?

If there is no demand for hot encoded states due to speed problems, I
prefer counters, since they can be reused in more than one area of a
complex state machine. Also a counter realy indicates "wait" where
states can do anything (using 2 fsm where actions and clocking are
separated, you will have to check the state transistion part if there
are really nothing else than transions without conditions.

Reply With Quote
  #5 (permalink)  
Old 09-18-2006, 07:30 PM
Andy Peters
Guest
 
Posts: n/a
Default Re: A general rule for State Machines?

Paul Uiterlinden wrote:
> Dave Dean wrote:
>
> > Anyway, this is a fairly simple example that I hope illustrates the
> > larger
> > point. Does anyone have a good rule of thumb of when to use a
> > counter and
> > when to add extra states?

>
> My opinion: go for the implementation that shows the least code
> duplication. This makes it more robust against introduction of bugs
> when the implementation is changed. Using a counter certainly would
> have my preference. It just makes the code easier to maintain.


Agreed. As a bonus, you can generalize the code by using a generic to
set the number of bits.

-a

Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
State Machines.. and their efficiency. [email protected] Verilog 3 05-31-2005 06:26 PM
Document State Machines? o FPGA 4 04-22-2004 12:31 PM
State machines vs. Schematics Thomas Bartzick FPGA 3 04-21-2004 08:18 AM
State Machines.... stan FPGA 27 11-24-2003 10:14 PM


All times are GMT +1. The time now is 08:11 AM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved