«

I have a FSM with 64 states (35 used, 29 spare, or reset states, to
force known binary encoding).
I would like to bring out the 6 bit value of the encoded FSM to a port
for test purposes, so how exactly do I do that easily.

I could assign a unique 6 bit SLV to each state, but that's a bit
tedious!

TIA, Kev P.

On May 4, 5:57 am, Niv <kev.pars...@mbda.co.uk> wrote:
> I have a FSM with 64 states (35 used, 29 spare, or reset states, to
> force known binary encoding).
> I would like to bring out the 6 bit value of the encoded FSM to a port
> for test purposes, so how exactly do I do that easily.
>
> I could assign a unique 6 bit SLV to each state, but that's a bit
> tedious!
>
> TIA, Kev P.

It may be tedious, but it is the only way to do it, without creating
your FSM as an SLV to begin with. Note that the decoding logic may
affect the optimal state layout chosen by the synthesis tool.

Andy

On May 7, 8:40 am, Andy <jonesa...@comcast.net> wrote:
> On May 4, 5:57 am, Niv <kev.pars...@mbda.co.uk> wrote:
>
> > I have a FSM with 64 states (35 used, 29 spare, or reset states, to
> > force known binary encoding).
> > I would like to bring out the 6 bit value of the encoded FSM to a port
> > for test purposes, so how exactly do I do that easily.
>
> > I could assign a unique 6 bit SLV to each state, but that's a bit
> > tedious!
>
> > TIA, Kev P.
>
> It may be tedious, but it is the only way to do it, without creating
> your FSM as an SLV to begin with. Note that the decoding logic may
> affect the optimal state layout chosen by the synthesis tool.
>
> Andy

Hey Andy,
What about this if one forces the synthesis tool to do binary
encoding?
------------------------------------------------------------------------------------------------------------
type state_typ is (state_0, state_1, state_2, state_3);
signal state : state_typ := state_0;

begin -- behav

-- concurrent process
state_vec <= std_logic_vector(to_unsigned(((state_typ'pos(state ))),
state_vec'LENGTH));

-- Newman

On May 7, 1:34 pm, Newman <newman5...@yahoo.com> wrote:
> On May 7, 8:40 am, Andy <jonesa...@comcast.net> wrote:
>
>
>
> > On May 4, 5:57 am, Niv <kev.pars...@mbda.co.uk> wrote:
>
> > > I have a FSM with 64 states (35 used, 29 spare, or reset states, to
> > > force known binary encoding).
> > > I would like to bring out the 6 bit value of the encoded FSM to a port
> > > for test purposes, so how exactly do I do that easily.
>
> > > I could assign a unique 6 bit SLV to each state, but that's a bit
> > > tedious!
>
> > > TIA, Kev P.
>
> > It may be tedious, but it is the only way to do it, without creating
> > your FSM as an SLV to begin with. Note that the decoding logic may
> > affect the optimal state layout chosen by the synthesis tool.
>
> > Andy
>
> Hey Andy,
> What about this if one forces the synthesis tool to do binary
> encoding?
> ------------------------------------------------------------------------------------------------------------
> type state_typ is (state_0, state_1, state_2, state_3);
> signal state : state_typ := state_0;
>
> begin -- behav
>
> -- concurrent process
> state_vec <= std_logic_vector(to_unsigned(((state_typ'pos(state ))),
> state_vec'LENGTH));
>
> -- Newman

I don't think the 'pos attribute is synthesizable. Check your
synthesis tool documentation. Even if it does, it may affect the
optimized encoding of the states due to the efficiency of creating
state_vec.

Andy

On May 7, 2:51 pm, Andy <jonesa...@comcast.net> wrote:
> On May 7, 1:34 pm, Newman <newman5...@yahoo.com> wrote:
>
>
>
>
>
> > On May 7, 8:40 am, Andy <jonesa...@comcast.net> wrote:
>
> > > On May 4, 5:57 am, Niv <kev.pars...@mbda.co.uk> wrote:
>
> > > > I have a FSM with 64 states (35 used, 29 spare, or reset states, to
> > > > force known binary encoding).
> > > > I would like to bring out the 6 bit value of the encoded FSM to a port
> > > > for test purposes, so how exactly do I do that easily.
>
> > > > I could assign a unique 6 bit SLV to each state, but that's a bit
> > > > tedious!
>
> > > > TIA, Kev P.
>
> > > It may be tedious, but it is the only way to do it, without creating
> > > your FSM as an SLV to begin with. Note that the decoding logic may
> > > affect the optimal state layout chosen by the synthesis tool.
>
> > > Andy
>
> > Hey Andy,
> > What about this if one forces the synthesis tool to do binary
> > encoding?
> > ---------------------------------------------------------------------------*---------------------------------
> > type state_typ is (state_0, state_1, state_2, state_3);
> > signal state : state_typ := state_0;
>
> > begin -- behav
>
> > -- concurrent process
> > state_vec <= std_logic_vector(to_unsigned(((state_typ'pos(state ))),
> > state_vec'LENGTH));
>
> > -- Newman
>
> I don't think the 'pos attribute is synthesizable. Check your
> synthesis tool documentation. Even if it does, it may affect the
> optimized encoding of the states due to the efficiency of creating
> state_vec.
>
> Andy- Hide quoted text -
>
> - Show quoted text -

XST synthesizes it and does a post place and route sim.
Whether it is the optimal thing to do is another question.

-Newman

Newman wrote:

> XST synthesizes it and does a post place and route sim.

Yes 'pos and 'val synthesize ok for constrained values.
But some days, I don't like the looks of:

case my_type_t'val( to_integer(unsigned(adr))) is ...

I have run into this issue when writing code
for an interface with a predefined address slice encoding.
Let's say:

type my_type_t is (load, auto, nom, cal); -- published modes
-- 00 01 10 11 -- published values

In this case, I might write a function like
this to tidy up the mess:

function vec2mode (arg : std_logic_vector)
return my_type_t is
variable argn_v : natural := to_integer(unsigned(arg));
begin
return my_type_t'val(argn_v);
end function vec2mode;

And use it like this:

procedure update_regs is
begin
if wr = '1' then
case vec2mode(adr) is
when load => do_load;
when cal => do_cal;
when nom => do_nom;
when auto => do_auto;
when others => do_nom;
end case;
end if;
end procedure update_regs;

-- Mike Treseler

On May 7, 5:43 pm, Mike Treseler <mike_trese...@comcast.net> wrote:
> Newman wrote:
> > XST synthesizes it and does a post place and route sim.
>
> Yes 'pos and 'val synthesize ok for constrained values.
> But some days, I don't like the looks of:
>
> case my_type_t'val( to_integer(unsigned(adr))) is ...
>
> I have run into this issue when writing code
> for an interface with a predefined address slice encoding.
> Let's say:
>
> type my_type_t is (load, auto, nom, cal); -- published modes
> -- 00 01 10 11 -- published values
>
> In this case, I might write a function like
> this to tidy up the mess:
>
> function vec2mode (arg : std_logic_vector)
> return my_type_t is
> variable argn_v : natural := to_integer(unsigned(arg));
> begin
> return my_type_t'val(argn_v);
> end function vec2mode;
>
> And use it like this:
>
> procedure update_regs is
> begin
> if wr = '1' then
> case vec2mode(adr) is
> when load => do_load;
> when cal => do_cal;
> when nom => do_nom;
> when auto => do_auto;
> when others => do_nom;
> end case;
> end if;
> end procedure update_regs;
>
> -- Mike Treseler

Hi Mike,
It looked like Niv wanted/had a "sequential" state machine
implementation and wanted a state vector to output to testpoints. It
seemed that if his implementation looked something like below, the
test state vector could be added in about one line of VHDL. When I
looked at the simplified circuit through the technology viewer, the
state_vec was directly tapped off the output of the state machine flip
flops when the synthesizer was directed to use a sequential
implementation.
I have never before used the pos attribute in synthesizable code,
but had an idea and wanted to see if it would pan out. Mike, I enjoy
your posts, because I view you as a craftsman and in general, your
style is much different from mine.

-Newman


------------------------------------------------------------------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity state_test is

port (
clk : in std_logic;
reset : in std_logic;
state_vec : out std_logic_vector(1 downto 0)
);

end state_test;

architecture behav of state_test is
type state_typ is (state_0, state_1, state_2, state_3);
signal state : state_typ := state_0;

begin -- behav

-- concurrent
state_vec <=
std_logic_vector(to_unsigned(((state_typ'pos(state ))),state_vec'LENGTH));

sync_proc : process (clk, reset)
begin -- process sync_proc
if reset = '1' then
state <= state_0;
elsif clk'event and clk = '1' then
case state is
when state_0 => state <= state_1;
when state_1 => state <= state_2;
when state_2 => state <= state_3;
when state_3 => state <= state_0;
when others => null;
end case;

end if;
end process sync_proc;
end behav;

On 8 May, 14:24, Newman <newman5...@yahoo.com> wrote:
> On May 7, 5:43 pm, Mike Treseler <mike_trese...@comcast.net> wrote:
>
>
>
>
>
> > Newman wrote:
> > > XST synthesizes it and does a post place and route sim.
>
> > Yes 'pos and 'val synthesize ok for constrained values.
> > But some days, I don't like the looks of:
>
> > case my_type_t'val( to_integer(unsigned(adr))) is ...
>
> > I have run into this issue when writing code
> > for an interface with a predefined address slice encoding.
> > Let's say:
>
> > type my_type_t is (load, auto, nom, cal); -- published modes
> > -- 00 01 10 11 -- published values
>
> > In this case, I might write a function like
> > this to tidy up the mess:
>
> > function vec2mode (arg : std_logic_vector)
> > return my_type_t is
> > variable argn_v : natural := to_integer(unsigned(arg));
> > begin
> > return my_type_t'val(argn_v);
> > end function vec2mode;
>
> > And use it like this:
>
> > procedure update_regs is
> > begin
> > if wr = '1' then
> > case vec2mode(adr) is
> > when load => do_load;
> > when cal => do_cal;
> > when nom => do_nom;
> > when auto => do_auto;
> > when others => do_nom;
> > end case;
> > end if;
> > end procedure update_regs;
>
> > -- Mike Treseler
>
> Hi Mike,
> It looked like Niv wanted/had a "sequential" state machine
> implementation and wanted a state vector to output to testpoints. It
> seemed that if his implementation looked something like below, the
> test state vector could be added in about one line of VHDL. When I
> looked at the simplified circuit through the technology viewer, the
> state_vec was directly tapped off the output of the state machine flip
> flops when the synthesizer was directed to use a sequential
> implementation.
> I have never before used the pos attribute in synthesizable code,
> but had an idea and wanted to see if it would pan out. Mike, I enjoy
> your posts, because I view you as a craftsman and in general, your
> style is much different from mine.
>
> -Newman
>
> ---------------------------------------------------------------------------*---------------------------------
> library ieee;
> use ieee.std_logic_1164.all;
> use ieee.numeric_std.all;
>
> entity state_test is
>
> port (
> clk : in std_logic;
> reset : in std_logic;
> state_vec : out std_logic_vector(1 downto 0)
> );
>
> end state_test;
>
> architecture behav of state_test is
> type state_typ is (state_0, state_1, state_2, state_3);
> signal state : state_typ := state_0;
>
> begin -- behav
>
> -- concurrent
> state_vec <=
> std_logic_vector(to_unsigned(((state_typ'pos(state ))),state_vec'LENGTH));
>
> sync_proc : process (clk, reset)
> begin -- process sync_proc
> if reset = '1' then
> state <= state_0;
> elsif clk'event and clk = '1' then
> case state is
> when state_0 => state <= state_1;
> when state_1 => state <= state_2;
> when state_2 => state <= state_3;
> when state_3 => state <= state_0;
> when others => null;
> end case;
>
> end if;
> end process sync_proc;
> end behav;- Hide quoted text -
>
> - Show quoted text -

I'll give that whirl; yes my FSM is that sequential type, but idles in
s0 until a trigger arrives. (Hi ho Silver).

Ta, Niv.

Newman wrote:

> Hi Mike,
> It looked like Niv wanted/had a "sequential" state machine
> implementation and wanted a state vector to output to testpoints.

Yes. My example was a
vector to enumeration decoder.
Niv needs to go enum to vector and you have
connected the dots for him.

> It
> seemed that if his implementation looked something like below, the
> test state vector could be added in about one line of VHDL.

Yes, and as I said in my post,
I find that "one line" a little hard to
read. I prefer to break out a
function to clarify the design intent,
and to add it to my bag of tricks.

> I have never before used the pos attribute in synthesizable code,
> but had an idea and wanted to see if it would pan out.

Good work.

> Mike, I enjoy
> your posts, because I view you as a craftsman and in general, your
> style is much different from mine.

Thanks. I have yet to see two designers
with exactly the same style.
My focus is on clear design intent
and reusable functions, subtypes and procedures.

-- Mike Treseler