one hot machine without elsif

[Brad Smallridge]

I have a state machine done with one flag for each state. Most of the states
are sequential accomplished with a default assignment:

signal state : std_logic_vector(0 to 61);
begin
state<='0'&state(0 to 60);

There are some variations to the sequential flow. Elsewhere I assign data
paths to these states like this:

if state(33 to 36)>0 then
mem_out<=a;
elsif state(37)>0 then
mem_out<=b;

The elsif are a bit long and have an unnecessary priority logic to them as
state(33 to 36) trumps state(37) although I can be very sure that the states
are mutually exclusive by design.

I am of the understanding that a series of "if end if" statements would only
serve to put the priority on the last "if end if" statement and therefore
would still have priority logic.

So my question is how to get rid of the priority logic? If I have to resort
to a case statement, how do I code this succinctly with this long state
vector? And is there some other way to do it, perhaps with a variable?

Brad Smallridge
AiVision

 

[Dave Pollum]

I have a state machine done with one flag for each state. Most of the states
are sequential accomplished with a default assignment:

signal state : std_logic_vector(0 to 61);
begin
state<='0'&state(0 to 60);

There are some variations to the sequential flow. Elsewhere I assign data
paths to these states like this:

if state(33 to 36)>0 then
 mem_out<=a;
elsif state(37)>0 then
 mem_out<=b;

The elsif are a bit long and have an unnecessary priority logic to them as
state(33 to 36) trumps state(37) although I can be very sure that the states
are mutually exclusive by design.

I am of the understanding that a series of "if end if" statements would only
serve to put the priority on the last "if end if" statement and therefore
would still have priority logic.

So my question is how to get rid of the priority logic? If I have to resort
to a case statement, how do I code this succinctly with this long state
vector? And is there some other way to do it, perhaps with a variable?

Brad Smallridge
AiVision

The "if end if" logic should not produce "priority" logic. You can
always code a simple example, synthesize it, and then look at the
results with the synthesizer's RTL viewer.
-Dave Pollum

 

[jtw]

I have a state machine done with one flag for each state. Most of the
states
are sequential accomplished with a default assignment:

signal state : std_logic_vector(0 to 61);
begin
state<='0'&state(0 to 60);

There are some variations to the sequential flow. Elsewhere I assign data
paths to these states like this:

if state(33 to 36)>0 then
mem_out<=a;
elsif state(37)>0 then
mem_out<=b;

The elsif are a bit long and have an unnecessary priority logic to them as
state(33 to 36) trumps state(37) although I can be very sure that the
states
are mutually exclusive by design.

I am of the understanding that a series of "if end if" statements would
only
serve to put the priority on the last "if end if" statement and therefore
would still have priority logic.

So my question is how to get rid of the priority logic? If I have to
resort
to a case statement, how do I code this succinctly with this long state
vector? And is there some other way to do it, perhaps with a variable?

Brad Smallridge
AiVision

| The "if end if" logic should not produce "priority" logic. You can
| always code a simple example, synthesize it, and then look at the
| results with the synthesizer's RTL viewer.
| -Dave Pollum

Why not? The sequence of statements (in a process) below:

If x > a then
y <= j;
end if;
if x < a then
y <= k;
end if;
if x = a then
y <= m;
end if;

is equivalent to

if x = a then
y <= m;
elsif x < a then
y <= k;
elsif x > a then
y <= j;
end if;

which is clearly priority encoded. The synthesis tool may, when all
conditions are mutually exclusive, implement a balanced tree.

JTW

 

[goouse]

| The "if  end if" logic should not produce "priority" logic.  You can
| always code a simple example, synthesize it, and then look at the
| results with the synthesizer's RTL viewer.
| -Dave Pollum

Why not?  The sequence of statements (in a process) below:

   If x > a then
       y <= j;
   end if;
   if x < a then
       y <= k;
   end if;
   if x = a then
       y <= m;
   end if;

is equivalent to

   if x = a then
      y <= m;
   elsif x < a then
      y <= k;
   elsif x > a then
       y <= j;
   end if;

which is clearly priority encoded.  The synthesis tool may, when all
conditions are mutually exclusive, implement a balanced tree.

JTW

Hi JTW,
sorry to say, that your example is definitely not priority encoded,
because there is no possible priority in it.
x and a can have only one value at a time, so there will always only
be only one match.
The resulting hardware in both cases is a magnitude comparator (=,<,>)
for x and a connected to a mux for y.

Of course if/elsif can create prioritiy encoded hardware, but does
only if necessary.

if u = a then
y <= m;
elsif v = b then
y <= k;
elsif w = c then
y <= j;
end if;

Here it is possible that all three conditions match at the same time.
Now the synthesis tool is forced to create some hardware that disables
the lower priorized paths.

Have a nice synthesis
Eilert

 

[goouse]

I have a state machine done with one flag for each state. Most of the states
are sequential accomplished with a default assignment:

signal state : std_logic_vector(0 to 61);
begin
state<='0'&state(0 to 60);

There are some variations to the sequential flow. Elsewhere I assign data
paths to these states like this:

if state(33 to 36)>0 then
 mem_out<=a;
elsif state(37)>0 then
 mem_out<=b;

The elsif are a bit long and have an unnecessary priority logic to them as
state(33 to 36) trumps state(37) although I can be very sure that the states
are mutually exclusive by design.

I am of the understanding that a series of "if end if" statements would only
serve to put the priority on the last "if end if" statement and therefore
would still have priority logic.

So my question is how to get rid of the priority logic? If I have to resort
to a case statement, how do I code this succinctly with this long state
vector? And is there some other way to do it, perhaps with a variable?

Brad Smallridge
AiVision

Hi Brad
when you really get priority logic, it is because you are using
different slices of your state vector.
You may use a case statement instead (and some constants to make it
readable:

small example:

signal state : std_logic_vector(0 to 5);
constant : Bit_0 : std_logic_vector(0 to 5) := "100000";
constant : Bit_1 : std_logic_vector(0 to 5) := "010000";
constant : Bit_2 : std_logic_vector(0 to 5) := "001000";
constant : Bit_3 : std_logic_vector(0 to 5) := "000100";
constant : Bit_4 : std_logic_vector(0 to 5) := "000010";
constant : Bit_5 : std_logic_vector(0 to 5) := "000001";

case state is
when Bit_0 to Bit_3 => mem_out <= a;
when Bit_5 => mem_out <= b;
when others => mem_out <= (others => '0');
end case;

Have a nice synthesis
Eilert

 

[Tricky]

May I ask why your are explicitly declaring the states? why are you
not using an enumerated type?

Otherwise, if you keep with the 1 hot method, why not extract the
range and just or the bits in the state type to mux the mem_out value?

use ieee.std_logic_misc.all; --With VHDL-2008 you dont need this

signal a_select : std_logic;
signal b_select : std_logic;

subtype aout1 is natural range 13 to 16;
subtype aout2 is natural range 24 to 26;
sybtype bout1 is natural range 31 to 36;

....

a_select <= or_reduce( state( aout1'high downto aout1'low) & state
( aout2'high downto aout2'low ) );
b_select <= or_reduce( state( bout1'high downto bout1'low) );

--Or in VHDL 2008 standard:
a_select <= or state( aout1'high downto aout1'low) & state( aout2'high
downto aout2'low ) ;
b_select <= or state( bout1'high downto bout1'low);

mem_out <= a when a_select = '1'
else b when b_select = '1'
else (others => '0');

This still implies priority, but your state type is 1 hot already, so
everything is mutually exclusive.

small example:

 signal state : std_logic_vector(0 to 5);
constant : Bit_0 : std_logic_vector(0 to 5) := "100000";
constant : Bit_1 : std_logic_vector(0 to 5) := "010000";
constant : Bit_2 : std_logic_vector(0 to 5) := "001000";
constant : Bit_3 : std_logic_vector(0 to 5) := "000100";
constant : Bit_4 : std_logic_vector(0 to 5) := "000010";
constant : Bit_5 : std_logic_vector(0 to 5) := "000001";

case state is
  when Bit_0 to Bit_3 => mem_out <= a;
  when Bit_5          => mem_out <= b;
  when others         => mem_out <= (others => '0');
end case;

Have a nice synthesis
  Eilert

Fixed:

case state is
when Bit_0 | Bit_1 | Bit_2 | Bit_3 => mem_out <= a;
when Bit_5 => mem_out <= b;
when others => mem_out <= (others => '0');
end case;

 

[Brad Smallridge]

May I ask why your are explicitly declaring the states?

Why are you not using an enumerated type?

That's just the way it developed. I started with a diagram
of where the memory writes should go and where the reads
should go and numbered these clock cycles.

Otherwise, if you keep with the 1 hot method,
why not extract the range and just or the bits
in the state type to mux the mem_out value?

a_select <= or_reduce( state( aout1'high downto aout1'low) & state
( aout2'high downto aout2'low ) );
b_select <= or_reduce( state( bout1'high downto bout1'low) );

Ugly.

case state is
when Bit_0 | Bit_1 | Bit_2 | Bit_3 => mem_out <= a;
when Bit_5 => mem_out <= b;
when others => mem_out <= (others => '0');
end case;

This might work if there were some function
to generate 61 states, and I knew that the
synthesizer would reduce it to one hot logic.
What I see here is a huge amount of logic.

Brad Smallridge
AiVision

 

[Brad Smallridge]

My recommendation is that you use an enumerated type based

statemachine and learn the tool switches to get it to be a one-hot.
Usually most attempts to code a one-hot loose the intent of
decoding only one bit per state.

Why is that? In ModelSim I can expand my state vector and
jump to any state I want. ISE will push wait states into
an SLR but all the states that are used are visible.

-- default all outputs and only set the opposite
-- value in the state - otherwise you definitely
-- have priority.
PortRdy <= '0' ;
LoadDor <= '0' ;
SelHold <= '0' ;
m1TxStb <= '1' ;
CountEnable <= '0' ;
TxNext <= "0000" ;

-- Decode READY State
if TxState(READY) = '1' then
PortRdy <= '1' ;
if (FifoRdy = '1') then
m1TxStb <= '0' ;
LoadDor <= '1' ;
TxNext(SETUP) <= '1' ;
else
TxNext(READY) <= '1' ;
end if ;
end if ;

-- Decode SETUP state
if (TxState(SETUP) = '1') then
. . .
end if ;

-- Decode SETUP state
if (TxState(PRE_HOLD) = '1') then
. . .
end if ;

-- Decode SETUP state
if (TxState(HOLD) = '1') then
. . .
end if ;
end process ; -- TxPortSmProc

I don't see how this gets rid of the "if end if" issue.
Are all these "if end if" in different processes. Or is
it that you don't have any non-state assignments in your
state procedures?

Brad Smallridge
AiVision

 

[Mike Treseler]

Ugly.

I agree with Tricky.
Unless you rewrite the code using an enumeration,
there are no pretty options.

-- Mike Treseler

 

[Brad Smallridge]

I agree with Tricky.

Unless you rewrite the code using an enumeration,
there are no pretty options.
-- Mike Treseler

I am not sure what I gain from enumeration.

I'm not happy with VHDL for not having a easy
method for turning off these logic chains. And
case is only good for single signals.

I think I'll take this to the FPGA group who
may be more sensitive to synthesis issues.

Brad Smallridge
Ai Vision

 

[KJ]

I am not sure what I gain from enumeration.

Enumeration will imply mutually exclusivity, in your original post you
said "although I can be very sure that the states are mutually
exclusive by design"...'very sure' is not really the same thing. You
may already be aware (but in case you're not), the individual cases do
not have to represent the actions of a single enumeration. As an
example...
case xyz is
when This | That => -- Do things when 'This' or 'That'
when Some_Other_Thing => -- Do when 'Some_Other_Thing'
...
end case;

I'm not happy with VHDL for not having a easy
method for turning off these logic chains. And
case is only good for single signals.

In order to express logic that you can be "very sure that the states
are mutually exclusive by design" but the case statement doesn't quite
do it for you, the other method is to express it in a sum of products
form.

From your original post...
if state(33 to 36)>0 then
mem_out<=a;
elsif state(37)>0 then
mem_out<=b;

If you know for darn sure that the two conditions being tested are
mutually exclusive, then you can express this as
mem_out <= To_Std_Logic(state(33 to 36)>0) and a
or To_Std_Logic(state(37)>0) and b;

I've taken some liberties here just to clarify the point. First
'To_Std_Logic' would be a function that simply converts a boolean to a
std_logic signal. Second, as written here 'a' and 'b' would be
std_logic although I know you're probably more interested in vector
types. But you can also override the 'and' function with one of the
form

function "and" (L: std_logic; R: std_logic_vector) return
std_logic_vector

Or, if you don't want to override "and" you could create another
function that takes in a std_logic and a vector, zeroing out or
passing through the bits based on the value of the std_logic
parameter.

The basic idea I'm trying to get across is that structuring your
equations in the sum of products form allows for arbitrarily complex
conditions to be evaluated and applied and does not create any
priority encoding logic of any sort. If the conditions you specify do
not happen to actually be mutually exclusive (i.e. 'very sure' was
wrong) all that happens is that two of the 'or' terms fire (which of
course will likely corrupt the output) but that's because you erred in
assuming that things were mutually exclusive when they really were
not.

I think I'll take this to the FPGA group who
may be more sensitive to synthesis issues.

I think you'll get better answers here myself.

Kevin Jennings