One .cdsenv, several design kits...

[spectrallypure]

Hello all!
I recently realized that my ~/.cdsenv has several definitions
pertaining to the design kit I've been using from always (AMS). I
recently installed a new design kit (TSMC), which didn't come with any
environment configuration templates (e.g. .cdsinit, .cdsenv). The
thing is that when I started simulating with the new design kit, the
references to the previous technology in my ~/.cdsenv arose, confusing
things a little.

Now I wonder how should I manage the fact that I will be using several
design kits from different vendors within the same unix account.
Specifically, how should I manage the fact that each design kit
expects ~/.cdsenv to be "its own"? With the .cdsinit there is no such
problem as it is "local" to each project's directory, but what about
the .cdsenv?

Cheers,

Jorge.

 

[Andrew Beckett]

spectrallypure wrote, on 02/05/09 12:53:

Hello all!
I recently realized that my ~/.cdsenv has several definitions
pertaining to the design kit I've been using from always (AMS). I
recently installed a new design kit (TSMC), which didn't come with any
environment configuration templates (e.g. .cdsinit, .cdsenv). The
thing is that when I started simulating with the new design kit, the
references to the previous technology in my ~/.cdsenv arose, confusing
things a little.

Now I wonder how should I manage the fact that I will be using several
design kits from different vendors within the same unix account.
Specifically, how should I manage the fact that each design kit
expects ~/.cdsenv to be "its own"? With the .cdsinit there is no such
problem as it is "local" to each project's directory, but what about
the .cdsenv?

Cheers,

Jorge.

Hi Jorge,

A few ways you could do this:

1. setenv CDS_LOAD_ENV addCWD
This will also look in the working dir for a .cdsenv file. That way
you can have it local to the project dir.
2. setenv CDS_LOAD_ENV CSF
You can then find the .cdsenv via the setup.loc file mechanism
(check in the <instdir>/doc/caiuser/caiuser.pdf for more details)
3. In your .cdsinit do:
envLoadFile("./.cdsenv") ; or whatever you want to call the file

Regards,

Andrew.

 

[spectrallypure]

On Feb 5, 5:59 pm, Andrew Beckett <andr...@DcEaLdEeTnEcTe.HcIoSm>
wrote:

spectrallypure wrote, on 02/05/09 12:53:



Hello all!
I recently realized that my ~/.cdsenv has several definitions
pertaining to the design kit I've been using from always (AMS). I
recently installed a new design kit (TSMC), which didn't come with any
environment configuration templates (e.g. .cdsinit, .cdsenv). The
thing is that when I started simulating with the new design kit, the
references to the previous technology in my ~/.cdsenv arose, confusing
things a little.

Now I wonder how should I manage the fact that I will be using several
design kits from different vendors within the same unix account.
Specifically, how should I manage the fact that each design kit
expects ~/.cdsenv to be "its own"? With the .cdsinit there is no such
problem as it is "local" to each project's directory, but what about
the .cdsenv?

Cheers,

Jorge.

Hi Jorge,

A few ways you could do this:

1. setenv CDS_LOAD_ENV addCWD
    This will also look in the working dir for a .cdsenv file. That way
    you can have it local to the project dir.
2. setenv CDS_LOAD_ENV CSF
    You can then find the .cdsenv via the setup.loc file mechanism
    (check in the <instdir>/doc/caiuser/caiuser.pdf for more details)
3. In your .cdsinit do:
    envLoadFile("./.cdsenv")  ; or whatever you want to call the file

Regards,

Andrew.

I get the idea. Thanks so much for the reply!.

Regards,
Jorge.

 

[S. Badel]

Tim,

by default the .cdsenv is loaded from your home directory (I think).

You can override this by setting the environment variable CDS_LOAD_ENV to one of the following values :
CWD : always read .cdsenv from current working directory
False : Do not load ~/.cdsenv nor CWD/.cdsenv
addCWD : Load ~/.cdsenv followed by CWD/.cdsenv
CWDElseHome : Loads CWD/.cdsenv if it exists, or else ~/.cdsenv, if it exists
CSF : Search setup.loc for <toolname>.cdsenv files .


Personally, i prefer to avoid having any conf. files in my home directory, and always load them from
..cdsinit using envLoadFile() or calls to envSetVal(). This way, at least, you're sure what you're
loading, do not depend on changes that your sysadmin might do without you knowing, or changes due
new software releases, and you can separate your settings for your different workspaces.

Based on my experience with several design kits, I can say that most tend to behave like they're
alone in the world, so it's always a bit of trouble to get them working together, but eventually it
ends up working.


Good luck.
Stéphane


Tim wrote:

Hi Andrew,

Will having a .cdsenv in the working directory overwrite the one from
your home directory?

We are having the same problem wiht multiple PDKs here with different
settings.

Thanks,
Tim

 

[Tim]

Hi Andrew,

Will having a .cdsenv in the working directory overwrite the one from
your home directory?

We are having the same problem wiht multiple PDKs here with different
settings.

Thanks,
Tim

 

[Andrew Beckett]

S. Badel wrote, on 02/12/09 18:44:

Tim,

by default the .cdsenv is loaded from your home directory (I think).

You can override this by setting the environment variable CDS_LOAD_ENV
to one of the following values :
CWD : always read .cdsenv from current working directory
False : Do not load ~/.cdsenv nor CWD/.cdsenv
addCWD : Load ~/.cdsenv followed by CWD/.cdsenv
CWDElseHome : Loads CWD/.cdsenv if it exists, or else ~/.cdsenv, if it
exists
CSF : Search setup.loc for <toolname>.cdsenv files .


Personally, i prefer to avoid having any conf. files in my home
directory, and always load them from .cdsinit using envLoadFile() or
calls to envSetVal(). This way, at least, you're sure what you're
loading, do not depend on changes that your sysadmin might do without
you knowing, or changes due new software releases, and you can separate
your settings for your different workspaces.

Based on my experience with several design kits, I can say that most
tend to behave like they're alone in the world, so it's always a bit of
trouble to get them working together, but eventually it ends up working.


Good luck.
Stéphane

Tim,

Since you asked me - I'll respond, although only to say that I completely agree
with what Stephane said.

Regards,

Andrew.