cell libraries and place and route

Is there a standard/documented set of environment variables for the stream root?

CDS_INST_DIR
CDSHOME
LDVHOME
AMSHOME
ASSURAHOME
ACV_ROOT
...
---
Erik


cadeguy_at_yahoo.com (Partha) wrote in message news:<7f58031f.0309281821.5a09e662_at_posting.google.com>...
Erik,
I recollect that you need to set ACV_ROOT variable to the aptivia install dir.
Partha


erikwanta_at_starband.net (Erik Wanta) wrote in message news:<84018314.0309280913.2ec9e882_at_posting.google.com>...
I have aptivia 3.2 installed. I can run from the command line, but I
can't get the Aptivia menu in the CIW or in the Schematic Composer
Tools menu. Am I supposed to load something to get the menus? I see
that acv.cxt is getting loaded.

I am running IC 5.0.32.500.5.
---
Erik

There's an upcoming mechanism in the cds.lib file which will avoid the need for env vars for this purpose anyway.

Erik,

Most of the streams don't need an envronment variable to indicate where their
root is - they fathom it out using the "cds_root" mechanism from the path.

However, Assura requires this (using the ASSURAHOME env var),
as does Aptivia (ACV_ROOT). I've complained about the ASSURAHOME one for
some time, because it really should be unnecessary. Aptivia is forgiveable
because it is relatively new to the Cadence stable and sometimes
getting rid of these legacy requirements takes a little while.

There is no need for env vars for the IC and LDV streams, but people
commonly define an env var in order to reference libraries included with
that stream. CDSHOME, LDVHOME and AMSHOME are commonly used
for this, but then again I've also seen CDSROOT, LDVROOT used. There's
an upcoming mechanism in the cds.lib file which will avoid the need for
env vars for this purpose anyway.

CDS_INST_DIR is an env var that people often used to use to point
to the Cadence installation back when everything was in a single FIRM
release - and it had special meaning to the tools. It didn't make much
sense in a multi-stream environment and so the special interpretation
has been removed, _except_ in the cds.lib and setup.loc files, where
it means the installation associated with the executable which is reading the
file (e.g. if it is being read by icfb, it means the IC stream containing that;
if it is being read by ncvlog, then it means the LDV stream containing that,
etc). It no longer (from IC445 onwards) is interpreted as an environment
variable.

Regards,

Andrew.

On 29 Sep 2003 13:51:57 -0700, erikwanta_at_starband.net (Erik Wanta) wrote:

Is there a standard/documented set of environment variables for the stream root?

CDS_INST_DIR
CDSHOME
LDVHOME
AMSHOME
ASSURAHOME
ACV_ROOT
...
---
Erik


cadeguy_at_yahoo.com (Partha) wrote in message news:<7f58031f.0309281821.5a09e662_at_posting.google.com>...
Erik,
I recollect that you need to set ACV_ROOT variable to the aptivia install dir.
Partha


erikwanta_at_starband.net (Erik Wanta) wrote in message news:<84018314.0309280913.2ec9e882_at_posting.google.com>...
I have aptivia 3.2 installed. I can run from the command line, but I
can't get the Aptivia menu in the CIW or in the Schematic Composer
Tools menu. Am I supposed to load something to get the menus? I see
that acv.cxt is getting loaded.

I am running IC 5.0.32.500.5.
---
Erik

Andrew:
Please provide more information on the following:
There's an upcoming mechanism in the cds.lib file which will avoid the need for env vars for this purpose anyway.

What is the mechanism and what is the PCR number?
---
Erik

Andrew Beckett <andrewb_at_DELETETHISBITcadence.com> wrote in message news:<e84invcm3q419ug3u5ddhh78u0690jahkt_at_4ax.com>...
Erik,

Most of the streams don't need an envronment variable to indicate where their
root is - they fathom it out using the "cds_root" mechanism from the path.

However, Assura requires this (using the ASSURAHOME env var),
as does Aptivia (ACV_ROOT). I've complained about the ASSURAHOME one for
some time, because it really should be unnecessary. Aptivia is forgiveable
because it is relatively new to the Cadence stable and sometimes
getting rid of these legacy requirements takes a little while.

There is no need for env vars for the IC and LDV streams, but people
commonly define an env var in order to reference libraries included with
that stream. CDSHOME, LDVHOME and AMSHOME are commonly used
for this, but then again I've also seen CDSROOT, LDVROOT used. There's
an upcoming mechanism in the cds.lib file which will avoid the need for
env vars for this purpose anyway.

CDS_INST_DIR is an env var that people often used to use to point
to the Cadence installation back when everything was in a single FIRM
release - and it had special meaning to the tools. It didn't make much
sense in a multi-stream environment and so the special interpretation
has been removed, _except_ in the cds.lib and setup.loc files, where
it means the installation associated with the executable which is reading the
file (e.g. if it is being read by icfb, it means the IC stream containing that;
if it is being read by ncvlog, then it means the LDV stream containing that,
etc). It no longer (from IC445 onwards) is interpreted as an environment
variable.

Regards,

Andrew.

On 29 Sep 2003 13:51:57 -0700, erikwanta_at_starband.net (Erik Wanta) wrote:

Is there a standard/documented set of environment variables for the stream root?

CDS_INST_DIR
CDSHOME
LDVHOME
AMSHOME
ASSURAHOME
ACV_ROOT
...
---
Erik


cadeguy_at_yahoo.com (Partha) wrote in message news:<7f58031f.0309281821.5a09e662_at_posting.google.com>...
Erik,
I recollect that you need to set ACV_ROOT variable to the aptivia install dir.
Partha


erikwanta_at_starband.net (Erik Wanta) wrote in message news:<84018314.0309280913.2ec9e882_at_posting.google.com>...
I have aptivia 3.2 installed. I can run from the command line, but I
can't get the Aptivia menu in the CIW or in the Schematic Composer
Tools menu. Am I supposed to load something to get the menus? I see
that acv.cxt is getting loaded.

I am running IC 5.0.32.500.5.
---
Erik

Folks,

I would like to know if there are simple fuctions that would do the
following, rather than re-inventing the wheel.

given a net name in the schematic i would like to delete that net &
add a elemnet( say a resistor) between the trminals of the net.

Do i need to do the following,
1. get the net & terminals
2. Delet the net( schDelete?)
3. check and see if the net is vertical or horizontal( by coparing the
co-ordinates of the terminals)
4. place the resistor in the appropriate orientation returned by 3
5. connect the resistor to one terminal & place a wire between the
other terminal of the resistor to complete the circuit

Should i do the above in skill, or is there a fancy skil
function/expression to do the above?

Thanks
Partha

HEllo,
I would like to know if here is a way to display user defined handles
on layout, just like a stretch parameter is displayed when using ROD
pcells/structures.

I am trying to do automatic resistance calculation as is outlined in
ROD user guide( code examples) and i was succesful in adding the user
defied handle, but would be cool if we could be able to display them
in the layout


Thanks
Partha

Also in the same thread, can a layout event trigger a call to a user
defined function, for example can i make the "stretch event" call a
function after the stretching is done?

Thanks
Partha

cadeguy_at_yahoo.com (Partha) wrote in message news:<7f58031f.0309221206.e10b5b3_at_posting.google.com>...
HEllo,
I would like to know if here is a way to display user defined handles
on layout, just like a stretch parameter is displayed when using ROD
pcells/structures.

I am trying to do automatic resistance calculation as is outlined in
ROD user guide( code examples) and i was succesful in adding the user
defied handle, but would be cool if we could be able to display them
in the layout


Thanks
Partha

And which tribe are you from?

Dennis is not your typical Native American name now, is it?

Oh, you mean to tell me your a descendant from European ancestry?
NO CHIT !

Count your blessings the door was open when your forefathers decided to make
a better life for themselves and their families.

Now about that pot calling the kettle black ......

"Dennis" <Howdy Doody_at_howdydoody.net> wrote in message
news:1088pg8k8qu3g9a_at_corp.supernews.com...
In article <d81b4dfc.0403251202.47a83564_at_posting.google.com>,
adewumirowland_at_yahoo.com says...

those south of the border. Even though the door was open
for my ancestors, it was still not open without limits.
I'm also against job "outsourcing". I suppose you have
a problem with me on that also.

Dennis <Howdy Doody_at_howdydoody.net> wrote in message
news:<108bi08b36fck02_at_corp.supernews.com>...
I don't see the problem.The same phiosophy applies to
those south of the border. Even though the door was open
for my ancestors, it was still not open without limits.
I'm also against job "outsourcing". I suppose you have
a problem with me on that also.

No, you have the problem- its called (politely) xenophobia;
this level of ignorance is more common on the A!@#*cad NG,
disappointing to see it here............

Hi,

I'm using Cadence Virtuoso Schematic Editing. I'm also using an RF
subcircuit as my library which only accept lr & nr as parameters for
channel length and number of fingers.

When I define my NMOS transistor, I need to define parameters as "lr"
and "nr" to specify channel length and number of fingers. In the
default CDF parameters, channel length and number of fingers are given
by "l" and "m" which will be ignored by the library I am using.

It seems that I need to define my own CDF parameters with names "lr"
and "nr", but I don't know how to do. I tried to add "user property"
in "edit object propertiers", but it does not work.

Can anyone help me to solve this problem? Thanks a lot.

Regards,

Carol

Hi Erik,

It's possible, but wouldn't then handle custom netlist procedures (each
custom netlist procedure would have to implement this); nor would it handle
m factor on subckt instances; nor would it help people working from netlists.

So I think the simulator is probably the right place to do it.

Regards,

Andrew.

On 30 Jul 2003 19:52:46 -0700, erikwanta_at_starband.net (Erik Wanta) wrote:

Andrew:
Instead of splitting the devices up inside spectre, how about a
netlist option that prints out the devices that use the mfactor in the
iterated instances format?
---
Erik

erikwanta_at_starband.net (Erik Wanta) wrote in message news:<84018314.0307300939.206fd778_at_posting.google.com>...
Andrew:
I like the idea of the option to split the devices up that are using
mfactor inside spectre for dcmatch and monte carlo.

We try to discourage the use of iterated instances and use the mfactor
and layoutXL generate multiple instances. The only problem we have
are layout designers who refuse to use layoutXL.
---
Erik

Andrew Beckett <andrewb_at_DELETETHISBITcadence.com> wrote in message news:<ccgfiv0n3sn18nf3c773mo5asfcdht4q4n_at_4ax.com>...
Frederic,

Fairly recently I did propose the opposite:

PCR: 419311
Title: montecarlo and dcmatch need to allow mismatch with m factor

Where I outlined:

Commonly instances have the "m" parameter on them to indicate multiple
devices. This is generally used to indicate that a device will be laid
out using m devices in parallel.

However, the problem with doing this is that for mismatch type analyses
(i.e. montecarlo and presumably the new IC50 dcmatch), all the
separate parallel instances are going to end up being 100% correlated,
because the m-factor is being taken account within the device equations.

We need to come up with some way of handling this. One possibility would
be to split the devices up (inside spectre) into really separate parallel
devices. Of course, the downside is that this would slow the simulation
down and increase the memory usage significantly.

The user can workaround this by using instance names such as M1<0:8
in composer (i.e. an iterated instance), but this means that you pay
the penalty for there being parallel devices in normal simulations.

Potentially the other way around could be done (at least in simple cases).
The problem is where do you stop? I think you'd want to do it both before
the hierarchy was flattened (so that subckts in parallel get m-factor'd up),
and then after flattening (to catch any others which happened to end
up in parallel after flattening - although in this case you'd probably be
restricted to single primitives in parallel). Doing this reduction could take
a reasonable amount of time (it can do in a verification tool), so it
would have to be an option.

Then you'd have the issue of relating the simulated results back to the
original netlist. For example, what if you'd asked to save the current
in _one_ of the devices that got paralleled up? Or what if you wanted to
look at the operating point data for one of these devices. It could get quite
confusing (or hard to handle).

An interesting idea though. I'm not sure how often people use the iterated
instance approach though - in other words, would it really be worth the effort
of implementing this (which I suspect could end up being a can of worms...)
when the "right" thing to do is to use the m-factor (with the proviso of PCR
419311 above).

Any thoughts?

Regards,

Andrew.

On Tue, 29 Jul 2003 12:53:54 +0200, eda support guy
cad_support_at_catena_dot_the_netherlands> wrote:


Andrew,

You mentioned here something that always puzzled me. Putting 2
identical devices, in parallel in a netlist does increase the simulation
cpu-time compared to putting one device with m=2. This is true with
spectre, and also with any spice-like simulator that I know of.

Now, would it not be easy for spectre programmers to do a little
"network preprocessing" in spectre and replace identical devices in
parallel by devices with an M>1 ? This, of course applies not only to
device models or devices modelled as subcircuits, but to any identical
subcircuit, or any identical "subparts" in a circuit.
Those two identical parts should have their nodes virtually shorted,
thereby easily reducing the admittance (or tableau, etc ...) matrix size.

I admit this can bring it share of problems, for instance in
implementing DCmatch or other sensitivity analysis, but the simulation
speedup would outweight the trouble, wouldn t it ?

Now, this would be too easy, and it is not done in spectre or *spice, so
I m probably overseeing stg. Anyone please tell me what ?

--
Frederic

Andrew:
I have a simulation form. The user specifies a bunch of things and
then hits OK. The code then submits the job either locally or to a
remote host with cid=ipcBatchProcess. Later on, the user might click
on stop simulation and I want to do a ipcKillProcess(cid) however cid
is gone. Do I need to make cid a global variable? Is there a way
that I can write cid to a file and then read it in an regenerate it?
It seems to be of type other. What information is stored in the
ipcId? Why can't I just give ipcKillProcess the number?
ipcKillProcess(3) for ipc:3
---
Erik

Andrew Beckett <andrewb_at_DELETETHISBITcadence.com> wrote in message news:<icalivose5t58jjntarfngv701bukbpab9_at_4ax.com>...
That would be ipcKillProcess(ipcId)

Andrew.

On 1 Aug 2003 09:18:07 -0700, erikwanta_at_starband.net (Erik Wanta) wrote:

I submit a job to a remote host with ipcBeginProcess or
ipcBatchProcess. Lets say that I change my mind after submission and
want to kill the job I submitted. Any ideas on how to kill the job on
the remote host?
---
Erik

Andrew:
How about postprocessing the netlist to convert all the devices with a
specified mfactor (m, np, M, _M, ...) to iterated instance notation
(M0_0, M0_1...)? I suppose you could have the case of iterated
instances and m>2.
---
Erik

Andrew Beckett <andrewb_at_DELETETHISBITcadence.com> wrote in message news:<837hiv00p9esmlk837o5g5dctnjgvuoa8o_at_4ax.com>...
Hi Erik,

It's possible, but wouldn't then handle custom netlist procedures (each
custom netlist procedure would have to implement this); nor would it handle
m factor on subckt instances; nor would it help people working from netlists.

So I think the simulator is probably the right place to do it.

Regards,

Andrew.

On 30 Jul 2003 19:52:46 -0700, erikwanta_at_starband.net (Erik Wanta) wrote:

Andrew:
Instead of splitting the devices up inside spectre, how about a
netlist option that prints out the devices that use the mfactor in the
iterated instances format?
---
Erik

erikwanta_at_starband.net (Erik Wanta) wrote in message news:<84018314.0307300939.206fd778_at_posting.google.com>...
Andrew:
I like the idea of the option to split the devices up that are using
mfactor inside spectre for dcmatch and monte carlo.

We try to discourage the use of iterated instances and use the mfactor
and layoutXL generate multiple instances. The only problem we have
are layout designers who refuse to use layoutXL.
---
Erik

Andrew Beckett <andrewb_at_DELETETHISBITcadence.com> wrote in message news:<ccgfiv0n3sn18nf3c773mo5asfcdht4q4n_at_4ax.com>...
Frederic,

Fairly recently I did propose the opposite:

PCR: 419311
Title: montecarlo and dcmatch need to allow mismatch with m factor

Where I outlined:

Commonly instances have the "m" parameter on them to indicate multiple
devices. This is generally used to indicate that a device will be laid
out using m devices in parallel.

However, the problem with doing this is that for mismatch type analyses
(i.e. montecarlo and presumably the new IC50 dcmatch), all the
separate parallel instances are going to end up being 100% correlated,
because the m-factor is being taken account within the device equations.

We need to come up with some way of handling this. One possibility would
be to split the devices up (inside spectre) into really separate parallel
devices. Of course, the downside is that this would slow the simulation
down and increase the memory usage significantly.

The user can workaround this by using instance names such as M1<0:8
in composer (i.e. an iterated instance), but this means that you pay
the penalty for there being parallel devices in normal simulations.

Potentially the other way around could be done (at least in simple cases).
The problem is where do you stop? I think you'd want to do it both before
the hierarchy was flattened (so that subckts in parallel get m-factor'd up),
and then after flattening (to catch any others which happened to end
up in parallel after flattening - although in this case you'd probably be
restricted to single primitives in parallel). Doing this reduction could take
a reasonable amount of time (it can do in a verification tool), so it
would have to be an option.

Then you'd have the issue of relating the simulated results back to the
original netlist. For example, what if you'd asked to save the current
in _one_ of the devices that got paralleled up? Or what if you wanted to
look at the operating point data for one of these devices. It could get quite
confusing (or hard to handle).

An interesting idea though. I'm not sure how often people use the iterated
instance approach though - in other words, would it really be worth the effort
of implementing this (which I suspect could end up being a can of worms...)
when the "right" thing to do is to use the m-factor (with the proviso of PCR
419311 above).

Any thoughts?

Regards,

Andrew.

On Tue, 29 Jul 2003 12:53:54 +0200, eda support guy
cad_support_at_catena_dot_the_netherlands> wrote:


Andrew,

You mentioned here something that always puzzled me. Putting 2
identical devices, in parallel in a netlist does increase the simulation
cpu-time compared to putting one device with m=2. This is true with
spectre, and also with any spice-like simulator that I know of.

Now, would it not be easy for spectre programmers to do a little
"network preprocessing" in spectre and replace identical devices in
parallel by devices with an M>1 ? This, of course applies not only to
device models or devices modelled as subcircuits, but to any identical
subcircuit, or any identical "subparts" in a circuit.
Those two identical parts should have their nodes virtually shorted,
thereby easily reducing the admittance (or tableau, etc ...) matrix size.

I admit this can bring it share of problems, for instance in
implementing DCmatch or other sensitivity analysis, but the simulation
speedup would outweight the trouble, wouldn t it ?

Now, this would be too easy, and it is not done in spectre or *spice, so
I m probably overseeing stg. Anyone please tell me what ?

--
Frederic

Vladimir wrote:
Hi!
Does anybody know any information about a bug of StreamOut or
StreamIN? I heard something like that from my friend. But recently we
met the same situation. When I translated GDS file we transferred to
foundry (only one layer) back to Cadence I found out the original
layout and GDS translated layout are different.
I checked PIPO.log file. There is no error. Moreover the missed layout
according to PIPO.log was succesfully translated. I checked statistics
related to missed block. That showed that a hadred of rectangulars,
poligons, cell and so on was successfully translated without any
problem. The only one layer was translated. But when I opened layout
one block has no layout. I suppose this happened for version 4.4.5 or
4.4.6.
Vladimir Fomin

Vladimir,

Masks are expensive enough... When tapeing-out I d recommend you put
yourself in paranoid mode and perform a check like this:
-stream-out
-snap gds2 to mask grid
-stream-in
-use dracula/diva/assura to Xor the streamed-in and source db's.