Stats

  • Locked Locked
  • Replies 2
  • Subscribers 90
  • Views 5800
  • 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

About Encounter Warning 'TA-549'

archive

hi All:

I get the following message when run timing analysis:

--> WARNING: Pin 'msd_ddr_phy/ddr_sstl/dll_ato_io125/AE' is driven 'ZERO' and
             'X' simultaneously, preserving 'X.' .
--> WARNING: Pin 'msd_ddr_phy/ddr_sstl/dll_dto_0_io121/OJ' is driven 'ZERO' and
             'X' simultaneously, preserving 'X.' .


Why? Does it relate to constant propagation? where comes the 'X'?


Originally posted in cdnusers.org by eminemshow
Parents

  • If there a different drivers on a net, and they are not driving the same signal state (0,1,X) on to the
    net, then system has to resolve which state the signal is in in order to propagate forward.

    The Warning you see indicates that there is such a conflict - in the case between a X (unknown) state and 0 (ZERO)
    state. The timer resolves this "conservatively" by keeping the X. All signals have a state value of X in the timer
    unless some explicit state assertion is made (set_case_analysis), and propagated forward.

    Other tools (PT I think) resolve the above scenario to ZERO rather than X. There is a CTE global to provide a similar
    resolution policy:

    set_global timing_resolve_driver_conflicts {conservative | aggressive}

    default: conservative

    (Note: for some reason this global is not in the current doc set. We'll look into getting that added)


    Originally posted in cdnusers.org by ejm
Reply

  • If there a different drivers on a net, and they are not driving the same signal state (0,1,X) on to the
    net, then system has to resolve which state the signal is in in order to propagate forward.

    The Warning you see indicates that there is such a conflict - in the case between a X (unknown) state and 0 (ZERO)
    state. The timer resolves this "conservatively" by keeping the X. All signals have a state value of X in the timer
    unless some explicit state assertion is made (set_case_analysis), and propagated forward.

    Other tools (PT I think) resolve the above scenario to ZERO rather than X. There is a CTE global to provide a similar
    resolution policy:

    set_global timing_resolve_driver_conflicts {conservative | aggressive}

    default: conservative

    (Note: for some reason this global is not in the current doc set. We'll look into getting that added)


    Originally posted in cdnusers.org by ejm
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.