RE: [vhdl-200x] FSM safe design

Some synthesis tools perform reachability analysis on state machines (including counters), and if they determine that other states are unreachable per the described logic behavior, the logic attributed to those unreachable states is optimized, whether you have a "when others" choice or not. This does not depend on whether an enumerated or explicit vector type is used for the state. Some synthesis tools will warn you if the "when others" choice is not synthesized.

There is usually an attribute (tool specific) to disable the optimization, allowing synthesis of such a "when others" choice. However, such an attribute has no effect on the RTL simulation, and the when others choice is not testable unless fault insertion/simulation is used (and probably only in gate-level simulation), or you include at least one defined but not used state in the enumerated type.

For Synplify, the appropriate method is syn_preserve = true, applied to the state register signal. This prevents their FSM compiler from taking over, and also prevents the reachability optimizations.

Then you can use syn_enum_encoding on the enumerated state type to define whatever encoding you want. Note that there is no way to access that encoding in your RTL code, but the "when others" choice will detect any value not defined in the encoding.

Andy D Jones
Electrical Engineering
Lockheed Martin Missiles and Fire Control
Dallas TX



From: owner-vhdl-200x@eda.org<mailto:owner-vhdl-200x@eda.org> [mailto:owner-vhdl-200x@eda.org] On Behalf Of Degroat, Joanne
Sent: Thursday, February 20, 2014 12:13 PM
To: vhdl-200x@eda.org<mailto:vhdl-200x@eda.org>
Subject: EXTERNAL: 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> [mailto:owner-vhdl-200x@eda.org] On Behalf Of Daniel Kho
Sent: Thursday, February 20, 2014 12:46 PM
To: vhdl-200x@eda.org<mailto: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<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.