Stats

  • Locked Locked
  • Replies 8
  • Subscribers 93
  • Views 17220
  • 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

Encounter 8.1 vs 9.1 sdf generation

MzQuarter

Hi,

I've used Encounter 8.1 for past projects to generate sdf back-annotation for simulation and it worked great. Now we've moved to Encounter 9.1, but the exact same 8.1 encounter project reloaded in 9.1 gives different results. First of all, the middle field ("typical", my guess) is no longer present, and when I load the sdf in a simulator the delays are all taken as 0 (no delays).  Second, the delays for interconnect are different, and quite often 0. Another difference I noticed is that in 8.1 the value triplets were always the same (which I thought odd), but not in encounter 9.1.

What am I missing? I'm almost sure it's just a setting, but I can't see where or how.

Thanks.

--------------------------------------------------------------------------------
Encounter 8.1:

(INTERCONNECT I_NCS U134/A (0.0037:0.0037:0.0037) (0.0037:0.0037:0.0037))
(INTERCONNECT I_SCLK Q_TRANSACTIONCOMPLETE_REG/CKN (0.0045:0.0045:0.0045) (0.0045:0.0045:0.0045))

Encounter 9.1:

(INTERCONNECT I_NCS U134/A  (0.003::0.004) (0.003::0.004))
(INTERCONNECT I_SCLK Q_TRANSACTIONCOMPLETE_REG/CKN  (0.000::0.000) (0.000::0.000))

Parents
  • Martinage

    We made a switch in the Encounter platform from using SDF generated by the delayCal command
    and that produced by the write_sdf command.  All new development on SDF will be using write_sdf - this
    is different code that delayCal - and thus has some different - generally better behaviors.

    In bcWc mode, the software is computing two corners worth of delays - best case and worst case. In OCV mode,
    we are also computing delays twice for early vs. late delays.  The resulting SDF is just this:

         (bc::wc)  for bcWc mode  or (early::late) for OCV mode

    A typ(ical) value is never computed, and so it is never written out.  Any value we would put there would strictly be
    placeholder and would have no real meaning.  Leaving the typ SDF slot empty makes it clear to anyone looking at the SDF
    that no real Typ corner delay calculation was done.

    MMMC allows you to create more than a two corner delay environment - you can now really have bc, wc and typ
    (and others) computed.  In this case, write_sdf now gives the option to specify how to populate the min:typ:max
    SDF slots from the different views. 

    - Ed

Reply
  • Martinage

    We made a switch in the Encounter platform from using SDF generated by the delayCal command
    and that produced by the write_sdf command.  All new development on SDF will be using write_sdf - this
    is different code that delayCal - and thus has some different - generally better behaviors.

    In bcWc mode, the software is computing two corners worth of delays - best case and worst case. In OCV mode,
    we are also computing delays twice for early vs. late delays.  The resulting SDF is just this:

         (bc::wc)  for bcWc mode  or (early::late) for OCV mode

    A typ(ical) value is never computed, and so it is never written out.  Any value we would put there would strictly be
    placeholder and would have no real meaning.  Leaving the typ SDF slot empty makes it clear to anyone looking at the SDF
    that no real Typ corner delay calculation was done.

    MMMC allows you to create more than a two corner delay environment - you can now really have bc, wc and typ
    (and others) computed.  In this case, write_sdf now gives the option to specify how to populate the min:typ:max
    SDF slots from the different views. 

    - Ed

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.