one hot machine without elsif

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

Brad Smallridge

On Feb 16, 5:10*pm, "Brad Smallridge" <bradsmallri...@dslextreme.com>
wrote:
> 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

Dave Pollum

"Dave Pollum" <> wrote in message
news:f4f96b31-d418-4194-ab66-...
On Feb 16, 5:10 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com>
wrote:
> 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

jtw

On 17 Feb., 05:42, "jtw" <wrigh...@hotmail.invalid> wrote:
> "Dave Pollum" <vze24...@verizon.net> wrote in message
>
> news:f4f96b31-d418-4194-ab66-...
> On Feb 16, 5:10 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com>
> wrote:
>
>
>
> > 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

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@twinmail.de

On 16 Feb., 23:10, "Brad Smallridge" <bradsmallri...@dslextreme.com>
wrote:
> 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

goouse@twinmail.de

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;

Tricky

>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

Brad Smallridge

Brad Smallridge wrote:

> Ugly.

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

-- Mike Treseler

Mike Treseler

> 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

Brad Smallridge