Spectre.hbnoise warning

This suggests you have invalid entries in the .cdsenv file that look like this:

spectre.pnoise noiseoutUI radio "USB"
spectre.hbnoise noiseoutUI radio "USB"

and it should be this:

spectre.pnoise noiseoutUI string "USB"
spectre.hbnoise noiseoutUI string "USB"

They should be string rather than radio. Maybe you have an envLoadFile call somewhere that is loading the file which is causing the spectre env vars to be loaded?

Regards,

Andrew.

Hello Andrew,

When I run which .cdsinit and which .cdsenv I see that I do not load envLoad file in any of these two locations.

In .cdsinit: I have the following that pertains to spectre:

envSetVal("asimenv.startup" "simulator" 'string "spectre")

envSetVal("spectre.outputs" "save" 'string "all")

envSetVal("spectre.outputs" "currents" 'string "all")

envSetVal("spectre.outputs" "pwr" 'string "all")

And in .cdsenv I have the following that calls spectre:

spectre.envOpts       modelFiles   string  "design.scs wafer.scs allModels.scs;tt"

spectre.envOpts       includePath              string "/home/grps/ef-test/GF8HP/IBM_PDK/bicmos8hp/V1.7_0.4HP/Spectre/models"

spectre.opts               tnom                                       string              "25"

I don't know where it is getting called from. 

Thank you always.

If you have envSetVal with any spectre related env vars, it will cause the env system to load from the .cdsenv files for the env vars related to spectre. These are not normally loaded until the first time something related to spectre is referenced.

Exactly where they are located depends on two things:

1. If $CDS_LOAD_ENV is set. If this is set to "CSF" see option 3 below. If it is set to "addCWD" it will look in the <ICinstDir>/tools/dfiI/local, home directory and working dir. If set to "CWD" it will only look in the working dir. If not set at all, it may depend on option 2 below
2. If there's a csfLookupConfig somewhere with "INCLUDE .cdsenv" then that tells it to look in the locations in point 3 in this list. You can check using "cdswhich -lookupconfig .cdsenv". This will tell you if it looks for it using the CSF mechanism or not. If not, then it looks in <INSTDIR>/tools/dfII/local and the home dir for a .cdsenv
3. If configured via csfLookupConfig or $CDS_LOAD_ENV set to CSF, then "cdswhich -all .cdsenv" will tell you all the .cdsenv locations it can find - it could be in any of these.

Regards,

Andrew.

Hello Andrew,

Thank you so much indeed as always. This is very helpful.

I have learned that the $CDS_LOAD_ENV is not set to CSF because when I put cdswhich -lookupconfig .cdsenv, it responded Cadence software is not configured to locate file '.cdsenv' via Cadence Search File mechanism.

My understanding is that .cdsenv and .cdsinit are the two main cadence initialization files that set the cadence environment.

The .cdsenv is loaded before the .cdsinit. The .cdsnit is written in skill script and whatever setting defined in .cdsinit file may override the settings in .cdsenv

In my working directory GF8HP I have copied .cdsenv and .cdsinit from GF8HP (former IBM8HP) example cdslib directory.

But when I launch cadence virtuoso, since I do not have CDS_LOAD_EVN set to any program, .cdsenv file is loaded in the following sequence

1. $IC_DIR/tools/dfII/etc/tools/<application>/.cdsenv
2. $IC_DIR/tools/dfII/local/.cdsenv (site customizations)
3. ~/.cdsenv (user customizations)

Because, whenever cadence runs for the first time, it creates hidden files such as .cadence and .cdsenv in my home directory (as ~/.cdsenv) and any value defined in the ~/.cdsenv (in the home directory) overrides those previously loaded. Because the default search mechanism for the .cdsenv file does not look in the working directory. Hence a ./.cdsenv file placed my working directory is not loaded by default.

If I want the .cdsenv that I have in my working directory which is ./.cdsenv (in my case the .cdsenv in my GF8HP directory) to be loaded first, I have to set the CDS_LOAD_EVN variable in my shell script to addCWD as follows:

setenv CDS_LOAD_ENV addCWD

I just want to make sure. Am I on the correct path?

Thank you very much again.

Yes, you're mostly right. First of all, there are two ways of using the Cadence Search File mechanism - one is to set $CDS_LOAD_ENV to CSF, and the other is to have a csfLookupConfig file somewhere in one of the search locations (as defined via a file called setup.loc) which says it should be enabled as a file to be loaded via CSF. Note that cdswhich -lookupconfig does not know anything about the special CDS_LOAD_ENV UNIX env var, because that was a specific mechanism that was added for extending .cdsenv searching before the csfLookupConfig extension mechanism was added - so cdswhich only knows about the general purpose csfLookupConfig approach.

Secondly, the tools create a .cadence dir automatically to save various preferences - they do not normally create a .cdsenv file unless asked to (or if you ask it to "not ask again" sometimes) - but you're right, such a file could get created in your home dir. The working dir .cdsenv does not get loaded by default unless you're in a CSF mode and the working dir is in the search path (which it usually is) or you have $CDS_LOAD_ENV set to CWD or addCWD.

.cdsenv files are loaded in a cumulative fashion - so it will load all of the files in the search order (in order) with the last in the search order loaded last - so in the case of addCWD it loads the working dir one first, overriding any duplicate variable in earlier cdsenv files.

So in your case I think you'd be OK with using the addCWD setting. Note, that wouldn't necessarily prevent the erroneous line for noiseoutUI still creating a warning (I didn't check this) because remember it loads the files cumulatively.

Regards,

Andrew.

Yes, you're mostly right. First of all, there are two ways of using the Cadence Search File mechanism - one is to set $CDS_LOAD_ENV to CSF, and the other is to have a csfLookupConfig file somewhere in one of the search locations (as defined via a file called setup.loc) which says it should be enabled as a file to be loaded via CSF. Note that cdswhich -lookupconfig does not know anything about the special CDS_LOAD_ENV UNIX env var, because that was a specific mechanism that was added for extending .cdsenv searching before the csfLookupConfig extension mechanism was added - so cdswhich only knows about the general purpose csfLookupConfig approach.

Secondly, the tools create a .cadence dir automatically to save various preferences - they do not normally create a .cdsenv file unless asked to (or if you ask it to "not ask again" sometimes) - but you're right, such a file could get created in your home dir. The working dir .cdsenv does not get loaded by default unless you're in a CSF mode and the working dir is in the search path (which it usually is) or you have $CDS_LOAD_ENV set to CWD or addCWD.

.cdsenv files are loaded in a cumulative fashion - so it will load all of the files in the search order (in order) with the last in the search order loaded last - so in the case of addCWD it loads the working dir one first, overriding any duplicate variable in earlier cdsenv files.

So in your case I think you'd be OK with using the addCWD setting. Note, that wouldn't necessarily prevent the erroneous line for noiseoutUI still creating a warning (I didn't check this) because remember it loads the files cumulatively.

Regards,

Andrew.

Hello Andrew,

I looked for .cdsenv files and I couldn’t find ((spectre.hbnoise) noiseoutUI radio "USB")

 or ((spectre.pnoise) noiseoutUI radio "USB") anywhere called. 

Will it also work to call the .cdsenv from my working directory by writing the envload file within .cdsinit as:

envLoadFile("./.cdsenv")?

Thank you.

Yes, you could do that, but it's still probably going to load this problematic .cdsenv file (wherever it's located) with the hbnoise setting in that causes the message. The world won't end because of that message, but if you want to get to the bottom of it, perhaps you should contact customer support (it's a bit hard to debug these things via the forum).

Regards,

Andrew.