Stats

  • Locked Locked
  • Replies 3
  • Subscribers 65
  • Views 1765
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

FSM_NoDeadlock - Explored (IFV)

Buvna

Hello,

I've been using the IFV tool for quite sometime now and I notice that when I run FSM assertions under AFA, No deadlock assertions remain explored while the others pass easily. Is there anyway to improve this?

Thanks 

Parents

  • Hi,

    from the IFV "Whats New":

    Updates to deadlock state

    In this release, the deadlock state property has been enhanced to check that the FSM cannot take any transition to the same state under any possible input combination.

    This deadlock state is supported by all engines and results in an improved performance.

    For complete information, see the section titled, "FSM Checks" in Chapter 10 of the Formal Verifier User Guide.

    What is implicitly explained here is the fact, that any input, that can control the outgoing transition of a FSM state, is now allowed to stall the FSM in 13.1, resulting in a noDeadlock failure. It is now required from the user to analyze and decide if that scenario is possible in the intended system context or not. If not, the user may add a fairness constraint like "eventually! !stable(<input>) and reduce unfairness manually.

    Joerg.

Reply

  • Hi,

    from the IFV "Whats New":

    Updates to deadlock state

    In this release, the deadlock state property has been enhanced to check that the FSM cannot take any transition to the same state under any possible input combination.

    This deadlock state is supported by all engines and results in an improved performance.

    For complete information, see the section titled, "FSM Checks" in Chapter 10 of the Formal Verifier User Guide.

    What is implicitly explained here is the fact, that any input, that can control the outgoing transition of a FSM state, is now allowed to stall the FSM in 13.1, resulting in a noDeadlock failure. It is now required from the user to analyze and decide if that scenario is possible in the intended system context or not. If not, the user may add a fairness constraint like "eventually! !stable(<input>) and reduce unfairness manually.

    Joerg.

Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.