RE: [vhdl-200x] FSM safe design

I will add some comment at this point as I am teaching this topic this semester.

My solution when the state machine is incompletely specified resulting in states that are essentially don't cares it to
Use the when others.   I some cases you can fix it to a next state but to get optimized logic I have used
when others => null;

Xilinx and Altera want cases where all the states are enumerated so you need the when others.

Joanne

From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Daniel Kho
Sent: Thursday, February 20, 2014 12:46 PM
To: vhdl-200x@eda.org
Subject: Re: [vhdl-200x] FSM safe design

These days, I would usually write the same example like this:

type my_fsm is (a, b, c);
  ...
     case my_fsm_signal is
        when b => my_fsm_signal <= c;
        when c => my_fsm_signal <= a;
        when others => if (start = true) then my_fsm_signal <= b; end if;
     end case;
which effectively makes State A a catch-all state. Still, I feel that by doing so, it makes the FSM description "look" incomplete (missing the "a" state), and adds confusion to others.
I used to do something like this before, but I believe this just adds unnecessary complexity:
if my_fsm_signal/=a and my_fsm_signal/=b and my_fsm_signal/=c then my_fsm_signal <= a;
else
     case my_fsm_signal is
        when a => if (start = true) then my_fsm_signal <= b; end if;
        when b => my_fsm_signal <= c;
        when c => my_fsm_signal <= a;
     end case;
end if;

regards, daniel

On 21 February 2014 01:26, Daniel Kho <daniel.kho@tauhop.com<mailto:daniel.kho@tauhop.com>> wrote:
All,
Adapting from Brent's, let's say we have the following typical FSM description:

< type my_fsm is (a, b, c);
> ...
>     case my_fsm_signal is
>        when a => if (start = true) then my_fsm_signal <= b; end if;
>        when b => my_fsm_signal <= c;
>        when c => my_fsm_signal <= a;
>        when others => my_fsm_signal <= a;
>     end case;
Perhaps it's a good idea to coerce synthesis tools to implicitly implement safe statemachines whenever the designer explicitly writes the "when others" clause.

I bumped into these issues as well, and my solutions at that time were to explicitly write extra logic that implements the catch-all condition (either using if-else statements, or using synthesis attributes), but I admit, these solutions are ugly as they tend to clutter the code and make the design less readable.
I would very much prefer if synthesis tools, by default, are intelligent enough to implement safe statemachines on its own.

Best regards, Daniel

On 20 February 2014 20:15, Brian Drummond <brian@shapes.demon.co.uk<mailto:brian@shapes.demon.co.uk>> wrote:
On Thu, 2014-02-20 at 00:42 +0000, Brent Hayhoe wrote:
> State machine design in VHDL can be performed in quite an elegant manner IMHO.
> That is using the provision of enumerated types.
>
> However, there is a problem which some people are still unaware of.
>
> I remember questioning various vendors about safe FSM design in the late
> nineties and only one had any sort of provision for it at that time. The
> situation has since improved.
>
> The classic VHDL problem is this:
>
>     type my_fsm is (a, b, c);
> ...
>     case my_fsm_signal is
>        when a => if (start = true) then my_fsm_signal <= b; end if;
>        when b => my_fsm_signal <= c;
>        when c => my_fsm_signal <= a;
>     end case;
> Although there are methods of adding synthesis attributes to handle this, it
> would be nice to incorporate it within the language semantics, e.g;
>
>      when others safe(my_fsm_signal <= a);
>
> Has anyone else had any thoughts regarding this issue?
I like the intent, but I wouldn't want to add reserved words or syntax
to the language to handle it. Adding an attribute "safe" or
"full_case_coverage" to the enumerated type and using a plain "when
others" case seems more appropriate.

Define a standard attribute for the purpose, establish its intent,
(namely, to suppress "redundant clause" optimisations and implement full
coverage. A warning describing the excess resources over "optimal"
solution might be appropriate) Then work with (at least some) tool
vendors to support it, and let peer pressure bring the rest on board.

If there already is a named standard attribute for the purpose, ... then
all I can say is, there isn't enough noise about it yet!

- Brian



--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.