• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Custom IC Design
  3. Instance terminal mapping within IC5.10.41.500.x.x running...

Stats

  • Locked Locked
  • Replies 4
  • Subscribers 125
  • Views 13539
  • 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

Instance terminal mapping within IC5.10.41.500.x.x running on RHEl6.9

PBWU
PBWU over 5 years ago

Hi 

I found instance terminal mapping is broken within IC5.10.41.500.x.x running on RHEL6.9 so that the calculator function IT("/PATH/Instance/Terminal") won't work. However, if I open a result browser, I can find that all the terminals are labelled with Instance\:1, Instance\:2, etc. They can be accessed and plotted.  

If I switched the OS platform to RHEL5.6, which I still have. The problem disappears. Is there any switch to set in order to make it work? Thanks.

Best regards

Patrick 

  • Cancel
  • Andrew Beckett
    Andrew Beckett over 5 years ago

    Hi Patrick,

    You're really pushing your luck running IC5141 (which was released in 2004 (yes, 16 years ago), and was supported on RHEL2.1 and RHEL3, if my memory is correct). Even with RHEL5 various things (like cdsdoc) stop working. I know (from some recent experiments) that in RHEL7 it breaks fairly badly due to the fact that there are some incompatible shared libraries in the OS, and it's quite possible that some of those effects may also be happening in later RHEL6 OS versions.

    For a release that had its final hotfix in 2011, there has certainly been no official testing in RHEL6 (probably not RHEL5 either), so you are taking a risk running it on an OS that recent. It's unlikely to be a switch to fix it - you may just be hitting an incompatibility with the OS which is unavoidable. Even RHEL4 didn't come out until 2005 - and we don't retrospectively support newer OS versions (with some exceptions where it is easy to do) during the life of a release.

    Andrew.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • PBWU
    PBWU over 5 years ago in reply to Andrew Beckett

    Thanks Andrew. 

    That's what I thought. I was trying to get an answer anyway. Now I know there is no simple fixture to this. 

    Since there are market demands that needs some very old process support, e.g., 0.18um and 0.13um for ultra-low power non-volatile memory solution, we had to stay with the old IC platform but hardware keeps moving on regardless. 

    Emmm.., cdsdoc on RHEL6 can actually be fixed if we hack into the cdsdoc and obServer scripts to modify LD_ASSUME_KERNEL variable. 

    Best regards

    Patrick

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Andrew Beckett
    Andrew Beckett over 5 years ago in reply to PBWU

    My recommendation would be to run an older RHEL version on a Virtual Machine - that means you can keep that older OS alive to use with any legacy software neded, without being constrained by the requirements of newer hardware to use a newer OS.

    I'm aware of the cdsdoc workarounds - in fact many years ago I wrote an article on support.cadence.com (mentioned in this thread from 8 years ago) which explained exactly how to do this (and how to borrow a shared library from another release as well). It's no longer published as we tidy up articles for long-unsupported releases.

    Regards,

    Andrew.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • PBWU
    PBWU over 5 years ago in reply to Andrew Beckett

    Thanks Andrew

    It turns out that three settings are needed to fix this. 

    envSetVal("spectre.envOpts" "simOutputFormat" 'string "psfbin")

    export PSF_WRITE_CHUNK_MODE_ON=true

    export PSF_LARGE_FILE_ON=false

    This works for spectre19 running on IC5.10.41.500.6.151 on RHEL6.9 platform. Thanks.

    Best regards

    Patrick

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel

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.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information