• 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. Migration to new operating system and force compiled model...

Stats

  • Locked Locked
  • Replies 7
  • Subscribers 126
  • Views 4403
  • 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

Migration to new operating system and force compiled model recompile

JayBee
JayBee 11 months ago

Dear all,

we're in the process of migrating from CentOS to RockyLinux. I know that those are not officially supported platforms but a sneak peak into the check_sysconf scripts made me confident that Rocky Linux would be a good path to go...

We have a funny issue that some previously running simulations are crashing without further notice. Sometimes deleting the testbench and results dir and starting a new Explorer view would help sometimes not.

The reason turned out to be that the PDK contained models that spectre compiles and that the compiled models are not interchangeable between the platforms. So deleting them sometimes worked in order to make it recompile. But then we found that spectre would even go and look into the results dirs of _other_ testbenches, which are otherwise totally unrelated! Since during the transition time we have both types of machines, and we need to be able to switch back and forth, it is just infeasible to always delete all .so files in all testbenches... 

I find it a little disturbing that it searches all other testbenches, is anybody aware how to turn this off ?
There is at least a way to force it to recompile the models always such that it would always be up to date for the recent run:

Solution is to set option -va,forcecompile

You can also see this Cadence support article for reference:
https://support.cadence.com/apex/ArticleAttachmentPortal?id=a1O0V0000090zjSUAQ

I hope this helps,
 Cheers, Joachim

  • Cancel
  • Andrew Beckett
    Andrew Beckett 11 months ago

    Joachim,

    I'm not sure of the way (or why) this is happening - I don't think it's shared between test benches, but maybe some of this is being saved in the user ~/.cadence directory? 

    I would suggest you contact customer support so that we can investigate. I think we also need to detect the need for recompilation too...

    Andrew

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • JayBee
    JayBee 11 months ago in reply to Andrew Beckett

    Dear Andrew,

    thanks for your reply. My first guess for a binary incompatibility would have been glibc. 

    We used CentOS Linux for ages, up to version 7.9.2009 , 3.10  :  ldd (GNU libc) 2.17

    Then we tried Red Hat Enterprise Linux release 9.4 (Plow) , 5.14 : ldd (GNU libc) 2.34
    There was no recompilation needed for that transition.

    Now we have  Rocky Linux release 9.4 (Blue Onyx)  , 5.14 : ldd (GNU libc) 2.34

    So it is indeed a little bit funny why it doesn't need it for RedHat but for Rocky with same version.

    I also find it strange that it searches / shares between testbenches. But the logfile clearly showed that it included the .so file from the path of another cellview.

    Spectre (R) Circuit Simulator
    Version 23.1.0.362.isr5 64bit -- 26 Jan 2024

    Current working directory: /work/Chip2_local/DSM_TB/maestro/results/maestro/Interactive.1/1/Chip2_local_DSM_TB_1/netlist


    Command line:
    /soft64/Cadence/SPECTRE231/tools.lnx86/bin/spectre -64 input.scs \
    +escchars +log ../psf/spectre.out -format psfxl -raw ../psf \
    +preset=cx +mt +lqtimeout 900 -maxw 5 -maxn 5 -env ade \
    +adespetkn=0001089D13A302B663E41FB550AF0DF415A679A322D5069144BF588C12F604E07EF416DC01A319B562BB63D374D2329B45A330D5088C219107D010C540F54F926DD979D15D9175FF349872C21AF81CA651EC278946FE5ABA05AC6D954EBB44FD0EA979D128F874D3349879D118F874D334981F048931E51A524D0000363D \
    -ahdllibdir \
    /work/Chip2_local/DSM_TB/maestro/results/maestro/Interactive.1/sharedData/CDS/ahdl/input.ahdlSimDB \
    +logstatus

    ...

    Opening directory /work/Chip2_local/DSM_TB/maestro/results/maestro/Interactive.1/sharedData/CDS/ahdl/input.ahdlSimDB/input.ahdlSimDB/ (775)
    Created directory /work/Chip2_local/DSM_TB/maestro/results/maestro/Interactive.1/sharedData/CDS/ahdl/input.ahdlSimDB/input.ahdlSimDB//bsource_resnoise_r_10430f.va.bsource_resnoise_r_10430f.ahdlcmi/ (775)
    Reading file: /work/DAC_Lib/tb_sampler/maestro_cp/results/maestro/Interactive.227/sharedData/CDS/ahdl/input.ahdlSimDB/input.ahdlSimDB/bsource_resnoise_r_10430f.va.bsource_resnoise_r_10430f.ahdlcmi/Linux-64/obj/optimize/5.0/libahdlcmi_bsource_resnoise_r_10430f.so
    Created directory /work/Chip2_local/DSM_TB/maestro/results/maestro/Interactive.1/sharedData/CDS/ahdl/input.ahdlSimDB/input.ahdlSimDB//bsource_resnoise_r_10430f.va.bsource_resnoise_r_10430f.ahdlcmi/Linux-64/obj/optimize/5.0
    Copying files from directory /work/DAC_Lib/tb_sampler/maestro_cp/results/maestro/Interactive.227/sharedData/CDS/ahdl/input.ahdlSimDB/input.ahdlSimDB/bsource_resnoise_r_10430f.va.bsource_resnoise_r_10430f.ahdlcmi/Linux-64/ to directory /work/Chip2_local/DSM_TB/maestro/results/maestro/Interactive.1/sharedData/CDS/ahdl/input.ahdlSimDB/input.ahdlSimDB//bsource_resnoise_r_10430f.va.bsource_resnoise_r_10430f.ahdlcmi/Linux-64/
    Finished copying files from /work/DAC_Lib/tb_sampler/maestro_cp/results/maestro/Interactive.227/sharedData/CDS/ahdl/input.ahdlSimDB/input.ahdlSimDB/bsource_resnoise_r_10430f.va.bsource_resnoise_r_10430f.ahdlcmi/Linux-64/ to /work/Chip2_local/DSM_TB/maestro/results/maestro/Interactive.1/sharedData/CDS/ahdl/input.ahdlSimDB/input.ahdlSimDB//bsource_resnoise_r_10430f.va.bsource_resnoise_r_10430f.ahdlcmi/Linux-64/.
    Existing shared object for module bsource_resnoise_r_10430f is up to date.
    Installed compiled interface for bsource_resnoise_r_10430f.

    The testbench is 'DSM_TB' in library 'Chip2_local'. When compiling models, it clearly sais that it is looking even into another library 'DAC_Lib' and copies the .so file from there.

    The compilation might be up to date with respect to the last changed date of the source file, but it was compiled on another OS, so it needs to be recompiled, else Spectre creashes.

    I have only COS light account so I can't open a support case. Just wanted to share the workaround and hope it helps anybody with similar issues.

    Cheers, Joachim

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • TomasMelander
    TomasMelander 10 months ago

    Hi Joachim,

    Thank you for an interesting post and your forcecompile solution helped me greatly.

    Were you successful in the migration to Rocky Linux? 

    Thanks!
    Tomas.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • JayBee
    JayBee 10 months ago in reply to TomasMelander

    Dear Tomas, 
    glad it helped you !
    We have migrated to Rocky, because looking into the checksysconf scripts from latest Cadence releases gave us a good feeling about it...
    Cheers,
     Joachim

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • TomasMelander
    TomasMelander 10 months ago in reply to JayBee

    Cool. Thanks for your quick reply.


    Thanks again,
    Tomas.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Andrew Beckett
    Andrew Beckett 10 months ago in reply to TomasMelander

    Tomas,

    Note that current releases all support RHEL8 (IC23.1, SPECTRE23.1 and SPECTRE24.1 and this is true of all releases since at least 2023). You may still be using IC6.1.8 which actually should work OK on RHEL8 since IC6.1.8/ICADVM20.1 ISR24, but there is no routine testing (and the release is in sunset mode anyway as both IC6.1.8 and ICADVM20.1 have reached their final ISRs).

    In general Rocky and Alma distributions are tolerated by the various startup scripts and checkers - this doesn't mean that they are routinely tested, but since they are downstream binary-compatible releases you should generally be OK. We had some teething issues with Quantus and Pegasus - there's an engineering hotfix for Quantus and I think for Pegasus too, but there's a workaround that you can use if you hit that - contact customer support.

    Andrew

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • TomasMelander
    TomasMelander 10 months ago in reply to Andrew Beckett

    Hi Andrew,

    Yes, we are stuck with IC618 for a while longer, but you encourage me to try RHEL8 and Rocky Linux8.

    Thanks for your good input.

    Regards,
    Tomas 

    • 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