Hi all, I am using Libero 11.5 SP3, including Synplify Pro. I need some help on how to synthesize safe FSMs. In synplify, in the VHDL Compiler options, there is a High reliability tab, where i can tick 'Preserve and decode Unreachable States'. Once this is ticked, I can see the RTL/Technology view with a state-error-detect box. But once i flash the design, it fails. (I have a memory check test to see this). This tick, applies to the whole design, more than 10 FSM's, and counters. Once un-ticked, the design passes the memory test. So i started looking into attibutes. So far I used the
attribute syn_safe_case : boolean; -- enables/disables the safe case option attribute syn_safe_case of RTL : architecture is true; -- turns off sequential optimizations for counters, FSM, and sequential logic attribute syn_encoding : string; -- Overrides the default FSM Compiler encoding for a state machine and applies the specified encoding attribute syn_encoding of curr_st : signal is "safe"; -- default encoding and adds reset logic
either together or on their own, they all pass the memory test. I definetely see different logic being synthesized, but cant see the state-error-detect box, anywhere. How can I know for sure that i synthesized a safe FSM? How do you synthesize yours? Thank you in advance SparkyT
SparkyT wrote: > I need some help on how to synthesize safe FSMs. Why do you need a "safe FSM"? A "safe FSM" only ensures, that no undefined state can be reached (or better: a undefined state can be reached, but it will recover from that and fall back to a "default state"). But a "safe FSM" does not guaranty that the state transistions are in the correct order!! > How do you synthesize yours? I never ever used the "safe implementation" of FSM (And i have running some thousands of FSM all around the world). You must simply know what leads to problems (clock domain crossing and unsynched inputs), and avoid things like this: http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html And try that with google translator: Beitrag "WHEN OTHERS in einer FSM" The last sentence in the last post concludes it very precisely... ;-)
: Edited by Moderator
Hi, so if I understand well, you are saying that a safe design, would allow the FSM to escape a 'lock' if an invalid state occurs after a transition, but would not help to prevent the bad transition in the first place. And since we are not talking about space applications, clock domain crossing and unsynched inputs are the real problems to solve the illegal transition, rather than the escape of the illigal state. Am I correct?
SparkyT wrote: > Am I correct? Yes, you got it. Any problem with occasional failures that I had on earth was due to any kind of sync problems, and those cannot be fixed with a "safe FSM"...
Thanks a lot for the information.