Re: [vhdl-200x] FSM safe design

Hi Brent,

On 20.02.2014 01:42, Brent Hayhoe wrote:
> 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);

Things to consider here are: a "when others" clause might not be written 
just as a catch-all for unnecessary states but as a real functionality 
for, as it says, all unmatched cases so far. I would never instruct the 
synthesis tool to consider the standard "when others" output for 
catching implementation-dependent states. Instead, a new clause, e.g. 
"when others safe", should be introduced to make this difference 
explicit, and to allow higher-level handling of this situation.

> type t_state is (state_a, state_b, state_c, state_d);
>
> runtime_error := false;
>
> case state is
>   when state_a => if start     then state <= state_b; end if;
>   when state_b => if not start thenstate <= state_a;
>                   elsif do_c   thenstate <= state_c;
>                   else              state <= state_d; end if;
>   when others  => state <= state_b;
>   when others safe => state <= state_a; runtime_error := true;
> end case;
>
> -- ...
> -- perhaps other assertions of runtime_error
> -- ...
>
> if runtime_error then
>   -- let's handle this bad case here, consistently, by resetting some
>   -- state machines, triggering a system interrupt, external reset,
>   -- and whatever is required
>   state <= state_a;
>   internal_bug <= '1';
> end if;

On the other hand, the state machine will not be the only register that 
can be harmed by bit flips, and even a flip from state_c to state_a is 
erroneous – how should you handle that? I think it’s a highly simplified 
view to consider only transitions to dead states are actually bad. Any 
inadvertent transition is bad. It’s up to the architect to identify 
relevant (groups of) registers and take care that they do not enter 
invalid states, e.g. by register triplication and voting, with 
controlling the synthesis tool about exact implementation-specific 
representation of that part of the code.

But as long as we’re designing more and more projects with cheaper FPGAs 
instead of more expensive ASICs, we’d have to deal with other effects as 
well, like inadvertent FPGA configuration changes. [granted, there are 
FPGAs which suffer less from these effects and are comparable to ASICs].

To me, the whole safe state handling debate is like considering that a 
safety belt but not seeing that this safety belt is just made of paper – 
you just don’t gain enough safety for your whole design state consistency.

– Matthias Wächter


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