cell libraries and place and route

[Andrew Beckett]

Rahul,

I have had spectre give a numeric noise floor of over 200dB down (even 275dB -
approaching the machine limits). It just depends on what you're doing and how
you're doing it... various controls can give a pretty low numeric noise floor,
and so you can't make a sweeping statement about spectre having a Dynamic
Range of 123dB. It's not that simple!

Andrew.


On Fri, 04 Jul 2003 16:20:50 -0700, rahul <rahuls@hrl.com> wrote:

hello Andrew and Herald

You have hit the bull's eye !!! Andrew is correct, that
spectre wouldn't work unless you let the simulator run
for 10 days with an infinitesimal time step. The limitation
is the simulator Dynamic Range. I have done some work
on this and will be soon publishing my work at a DARPA
conference in August. I use a 4th order idealised Bandpass
continuous time sigma delta modulator as my test circuit
(I will send you the reference when the paper gets accepted
at BMAS) The idea is to force the simulator in TRAP only mode
(with SKIP dc) option and then let the simulation run. I found
with SPECTRE I get a dynamic range of 123dB for 5u secs (which
takes a few minutes depending on the step size). I have come
to the conclusion that spectre has a DR of 123Db
Here my DR = av noise floor - input carrier
-----------------------------------
lowest point in the Noise Transfer curve


This is the reason we are developing our own simulator
using wavelets so that we can improve the DR by capturing
sharp transitions using Haar wavelets. Well, rest of my work
is classified so cannot give out too much information.

Thanks for all the info

Rahul



Andrew Beckett wrote:
Harald,

Use spectreRF (it doesn't have to just be used for RF). See

http://www.designers-guide.com/Analysis/sc-filters.pdf

I agree, transient noise is not a good approach. I've made some
comments about transient noise in earlier appends in this group (check google),
which essentially agree with what you're saying. The paper above is
talking about sc-filters, but it could probably apply to an ADC. There's
another paper on Ken's site about simulating sigma-delta converters with
spectreRF too (not read that yet though).

Andrew.

On 4 Jul 2003 08:28:47 -0700, haneu@illegal.de (Harald Neubauer) wrote:


Hi,
ok, we agree, that this is distortion, but how could i calculate
signal to (stochastic) noise in a switched cap circuit with spectre?
This is something, what really worries me a long time now!
I would like to know how noise is transferred through a switched-cap
circuit (such as a adc but in reality i'm looking for more).
I know that there is such a possibility in eldo, but our main
simulator is spectre, so i would like to stick to that...(and that
might go to another newsgroup
One suggestion is to add a transient noise source. This is basically a
transient file generated by a mathematical program (matlab or such).
But i'm still concerned about accuracy then. Noise tends to have a
huge bandwidth, so either simulation can get awful slow (small
timesteps because of huge frequency) or inaccurate (because simulation
chooses huge timesteps compared to noise bandwidth).
Just adding it to the transient seem not to be reliable?
Any thoughts about that? Anything in the pipeline at cadence?
Regards Harald


rahul <rahuls@hrl.com> wrote in message news:<3F0528E5.50403@hrl.com>...

You are right that it is distortion.


--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd

--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd

 

[rahul]

Well, then design a circuit and show it to me.
Here at Hughes we have been designing Sigma delta
modulators for over 20 years and have got a max of
120dB-125dB dynamic range based on the formula I
provided you.

Andrew you are good at Skill programming, stick to
that. I am sure you do not have any patents pending
on data converters

Thanks for all the information
Rahul






Andrew Beckett wrote:

Rahul,

I have had spectre give a numeric noise floor of over 200dB down (even 275dB -
approaching the machine limits). It just depends on what you're doing and how
you're doing it... various controls can give a pretty low numeric noise floor,
and so you can't make a sweeping statement about spectre having a Dynamic
Range of 123dB. It's not that simple!

Andrew.


On Fri, 04 Jul 2003 16:20:50 -0700, rahul <rahuls@hrl.com> wrote:


hello Andrew and Herald

You have hit the bull's eye !!! Andrew is correct, that
spectre wouldn't work unless you let the simulator run
for 10 days with an infinitesimal time step. The limitation
is the simulator Dynamic Range. I have done some work
on this and will be soon publishing my work at a DARPA
conference in August. I use a 4th order idealised Bandpass
continuous time sigma delta modulator as my test circuit
(I will send you the reference when the paper gets accepted
at BMAS) The idea is to force the simulator in TRAP only mode
(with SKIP dc) option and then let the simulation run. I found
with SPECTRE I get a dynamic range of 123dB for 5u secs (which
takes a few minutes depending on the step size). I have come
to the conclusion that spectre has a DR of 123Db
Here my DR = av noise floor - input carrier
-----------------------------------
lowest point in the Noise Transfer curve


This is the reason we are developing our own simulator
using wavelets so that we can improve the DR by capturing
sharp transitions using Haar wavelets. Well, rest of my work
is classified so cannot give out too much information.

Thanks for all the info

Rahul



Andrew Beckett wrote:

Harald,

Use spectreRF (it doesn't have to just be used for RF). See

http://www.designers-guide.com/Analysis/sc-filters.pdf

I agree, transient noise is not a good approach. I've made some
comments about transient noise in earlier appends in this group (check google),
which essentially agree with what you're saying. The paper above is
talking about sc-filters, but it could probably apply to an ADC. There's
another paper on Ken's site about simulating sigma-delta converters with
spectreRF too (not read that yet though).

Andrew.

On 4 Jul 2003 08:28:47 -0700, haneu@illegal.de (Harald Neubauer) wrote:



Hi,
ok, we agree, that this is distortion, but how could i calculate
signal to (stochastic) noise in a switched cap circuit with spectre?
This is something, what really worries me a long time now!
I would like to know how noise is transferred through a switched-cap
circuit (such as a adc but in reality i'm looking for more).
I know that there is such a possibility in eldo, but our main
simulator is spectre, so i would like to stick to that...(and that
might go to another newsgroup
One suggestion is to add a transient noise source. This is basically a
transient file generated by a mathematical program (matlab or such).
But i'm still concerned about accuracy then. Noise tends to have a
huge bandwidth, so either simulation can get awful slow (small
timesteps because of huge frequency) or inaccurate (because simulation
chooses huge timesteps compared to noise bandwidth).
Just adding it to the transient seem not to be reliable?
Any thoughts about that? Anything in the pipeline at cadence?
Regards Harald


rahul <rahuls@hrl.com> wrote in message news:<3F0528E5.50403@hrl.com>...


You are right that it is distortion.

--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd


--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd

 

[Andrew Beckett]

Rahul,

Actually, I _do_ have a patent (granted) on a data converter.
US patent number 5870052.
I was an analog and mixed signal designer for ~10 years before joining
Cadence (and have done some design work since joining Cadence too).
My main area was indeed data converters and low power communication
systems. This was a bad choice to hit me with...

So please don't be so presumptuous (actually I thought you were pretty
rude). I have both a software and design background. Just because I
can write decent SKILL code doesn't mean I know nothing about
analog design.

Now, are you just running a transient and then doing an fft? One easy
way to improve the noise floor is to use the strobeperiod option on
transient analysis, and arrange that the strobeperiod ties up with the
sample interval for the fft. Remember that dft in the Artist calculator always
gives you a power of 2 samples, even if you ask for a different number.
Of course it's a good idea to tighten tolerances and so on as well. You may
want to limit maxstep in some circuits to force more timepoints to improve
the tracking (this is often useful in very linear circuits).
Note, strobeperiod forces the simulate to take a timepoint at
the strobe point, which reduces the amount of interpolation
that needs to be done during the fft sampling.

Of course, you may be doing all this already - so please forgive me
if I know less than you about design ;-<

I have seen plenty of circuits with lower noise floor than you describe.
Many of these are customer (i.e. real) examples.

Andrew (a lowly SKILL programmer)

On Sun, 06 Jul 2003 23:40:54 -0700, rahul <rahuls@hrl.com> wrote:

Well, then design a circuit and show it to me.
Here at Hughes we have been designing Sigma delta
modulators for over 20 years and have got a max of
120dB-125dB dynamic range based on the formula I
provided you.

Andrew you are good at Skill programming, stick to
that. I am sure you do not have any patents pending
on data converters

Thanks for all the information
Rahul






Andrew Beckett wrote:
Rahul,

I have had spectre give a numeric noise floor of over 200dB down (even 275dB -
approaching the machine limits). It just depends on what you're doing and how
you're doing it... various controls can give a pretty low numeric noise floor,
and so you can't make a sweeping statement about spectre having a Dynamic
Range of 123dB. It's not that simple!

Andrew.


On Fri, 04 Jul 2003 16:20:50 -0700, rahul <rahuls@hrl.com> wrote:


hello Andrew and Herald

You have hit the bull's eye !!! Andrew is correct, that
spectre wouldn't work unless you let the simulator run
for 10 days with an infinitesimal time step. The limitation
is the simulator Dynamic Range. I have done some work
on this and will be soon publishing my work at a DARPA
conference in August. I use a 4th order idealised Bandpass
continuous time sigma delta modulator as my test circuit
(I will send you the reference when the paper gets accepted
at BMAS) The idea is to force the simulator in TRAP only mode
(with SKIP dc) option and then let the simulation run. I found
with SPECTRE I get a dynamic range of 123dB for 5u secs (which
takes a few minutes depending on the step size). I have come
to the conclusion that spectre has a DR of 123Db
Here my DR = av noise floor - input carrier
-----------------------------------
lowest point in the Noise Transfer curve


This is the reason we are developing our own simulator
using wavelets so that we can improve the DR by capturing
sharp transitions using Haar wavelets. Well, rest of my work
is classified so cannot give out too much information.

Thanks for all the info

Rahul



Andrew Beckett wrote:

Harald,

Use spectreRF (it doesn't have to just be used for RF). See

http://www.designers-guide.com/Analysis/sc-filters.pdf

I agree, transient noise is not a good approach. I've made some
comments about transient noise in earlier appends in this group (check google),
which essentially agree with what you're saying. The paper above is
talking about sc-filters, but it could probably apply to an ADC. There's
another paper on Ken's site about simulating sigma-delta converters with
spectreRF too (not read that yet though).

Andrew.

On 4 Jul 2003 08:28:47 -0700, haneu@illegal.de (Harald Neubauer) wrote:



Hi,
ok, we agree, that this is distortion, but how could i calculate
signal to (stochastic) noise in a switched cap circuit with spectre?
This is something, what really worries me a long time now!
I would like to know how noise is transferred through a switched-cap
circuit (such as a adc but in reality i'm looking for more).
I know that there is such a possibility in eldo, but our main
simulator is spectre, so i would like to stick to that...(and that
might go to another newsgroup
One suggestion is to add a transient noise source. This is basically a
transient file generated by a mathematical program (matlab or such).
But i'm still concerned about accuracy then. Noise tends to have a
huge bandwidth, so either simulation can get awful slow (small
timesteps because of huge frequency) or inaccurate (because simulation
chooses huge timesteps compared to noise bandwidth).
Just adding it to the transient seem not to be reliable?
Any thoughts about that? Anything in the pipeline at cadence?
Regards Harald


rahul <rahuls@hrl.com> wrote in message news:<3F0528E5.50403@hrl.com>...


You are right that it is distortion.

--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd


--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd

--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd

 

[rahul]

My apologizes Andrew, I got a bit carried away.
Well the benchmark is quite specific to what we
do over here, CT Sigma Delta modulators and this circuits
take for ever to simulate. To get a descent notch (NTF)
I force spectre to run in Trapezoidal mode because
my simulator (HAARSPICE) runs in this mode, by gradually changing
the max step size I see the notch go down till it hits
-170Db. The noise floor is at approx=-45DB therefore the
magic number 125dB Now if we add the carrier which is
another 55 db, the DR will be 180Db

I am using factory defaults so my reltol 1e-3

If you talk with M. Steer (from NCSU) his benchmark
circuits give 40Db DR so the definition of DR and the
circuit used changes. For my applications with idealised
Verilog-A model and transistors I get this numbers.
I don't fake it this is what I get. There is nothing wrong
in reporting the truth.

Well, again I am sorry for my uncivilised comments.
(lowly Analog designer simulating a DAC at 3.00 am PT)

Regards
Rahul




Andrew Beckett wrote:

Rahul,

Actually, I _do_ have a patent (granted) on a data converter.
US patent number 5870052.
I was an analog and mixed signal designer for ~10 years before joining
Cadence (and have done some design work since joining Cadence too).
My main area was indeed data converters and low power communication
systems. This was a bad choice to hit me with...

So please don't be so presumptuous (actually I thought you were pretty
rude). I have both a software and design background. Just because I
can write decent SKILL code doesn't mean I know nothing about
analog design.

Now, are you just running a transient and then doing an fft? One easy
way to improve the noise floor is to use the strobeperiod option on
transient analysis, and arrange that the strobeperiod ties up with the
sample interval for the fft. Remember that dft in the Artist calculator always
gives you a power of 2 samples, even if you ask for a different number.
Of course it's a good idea to tighten tolerances and so on as well. You may
want to limit maxstep in some circuits to force more timepoints to improve
the tracking (this is often useful in very linear circuits).
Note, strobeperiod forces the simulate to take a timepoint at
the strobe point, which reduces the amount of interpolation
that needs to be done during the fft sampling.

Of course, you may be doing all this already - so please forgive me
if I know less than you about design ;-

I have seen plenty of circuits with lower noise floor than you describe.
Many of these are customer (i.e. real) examples.

Andrew (a lowly SKILL programmer)

On Sun, 06 Jul 2003 23:40:54 -0700, rahul <rahuls@hrl.com> wrote:


Well, then design a circuit and show it to me.
Here at Hughes we have been designing Sigma delta
modulators for over 20 years and have got a max of
120dB-125dB dynamic range based on the formula I
provided you.

Andrew you are good at Skill programming, stick to
that. I am sure you do not have any patents pending
on data converters

Thanks for all the information
Rahul






Andrew Beckett wrote:

Rahul,

I have had spectre give a numeric noise floor of over 200dB down (even 275dB -
approaching the machine limits). It just depends on what you're doing and how
you're doing it... various controls can give a pretty low numeric noise floor,
and so you can't make a sweeping statement about spectre having a Dynamic
Range of 123dB. It's not that simple!

Andrew.


On Fri, 04 Jul 2003 16:20:50 -0700, rahul <rahuls@hrl.com> wrote:



hello Andrew and Herald

You have hit the bull's eye !!! Andrew is correct, that
spectre wouldn't work unless you let the simulator run
for 10 days with an infinitesimal time step. The limitation
is the simulator Dynamic Range. I have done some work
on this and will be soon publishing my work at a DARPA
conference in August. I use a 4th order idealised Bandpass
continuous time sigma delta modulator as my test circuit
(I will send you the reference when the paper gets accepted
at BMAS) The idea is to force the simulator in TRAP only mode
(with SKIP dc) option and then let the simulation run. I found
with SPECTRE I get a dynamic range of 123dB for 5u secs (which
takes a few minutes depending on the step size). I have come
to the conclusion that spectre has a DR of 123Db
Here my DR = av noise floor - input carrier
-----------------------------------
lowest point in the Noise Transfer curve


This is the reason we are developing our own simulator
using wavelets so that we can improve the DR by capturing
sharp transitions using Haar wavelets. Well, rest of my work
is classified so cannot give out too much information.

Thanks for all the info

Rahul



Andrew Beckett wrote:


Harald,

Use spectreRF (it doesn't have to just be used for RF). See

http://www.designers-guide.com/Analysis/sc-filters.pdf

I agree, transient noise is not a good approach. I've made some
comments about transient noise in earlier appends in this group (check google),
which essentially agree with what you're saying. The paper above is
talking about sc-filters, but it could probably apply to an ADC. There's
another paper on Ken's site about simulating sigma-delta converters with
spectreRF too (not read that yet though).

Andrew.

On 4 Jul 2003 08:28:47 -0700, haneu@illegal.de (Harald Neubauer) wrote:




Hi,
ok, we agree, that this is distortion, but how could i calculate
signal to (stochastic) noise in a switched cap circuit with spectre?
This is something, what really worries me a long time now!
I would like to know how noise is transferred through a switched-cap
circuit (such as a adc but in reality i'm looking for more).
I know that there is such a possibility in eldo, but our main
simulator is spectre, so i would like to stick to that...(and that
might go to another newsgroup
One suggestion is to add a transient noise source. This is basically a
transient file generated by a mathematical program (matlab or such).
But i'm still concerned about accuracy then. Noise tends to have a
huge bandwidth, so either simulation can get awful slow (small
timesteps because of huge frequency) or inaccurate (because simulation
chooses huge timesteps compared to noise bandwidth).
Just adding it to the transient seem not to be reliable?
Any thoughts about that? Anything in the pipeline at cadence?
Regards Harald


rahul <rahuls@hrl.com> wrote in message news:<3F0528E5.50403@hrl.com>...



You are right that it is distortion.

--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd

--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd


--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd

 

[Andrew Beckett]

Hi Rahul,

My apologizes Andrew, I got a bit carried away.
No problem.

I was just trying to point out with my original comments that the dynamic range
(or at least the numeric noise floor) will vary dependent on the circuit - and
there are quite a few things you can do in the simulator to control various
tolerances and settings to improve matters. I'm not doubting the results you
see - I was just saying that "your mileage may vary" - and also by adjusting
various simulator settings, you may be able to get better results.

The technique I mentioned (setting strobeperiod to match the fft sampling
period) is a useful one - worth considering if you're not doing that already.

Also, in SpectreRF, the accuracy of the fourier analysis that is done in the PSS
can be improved massively using the new "High Order Multi Interval Chebyshev
Polynomial" method (aka MIC) that was added in IC50. With this I have seen
huge improvements in the numerical noise floor with strongly linear circuits
(which often start off with poor numerical noise floor when simulated using
standard time domain techniques). With nonlinear circuits the noise floor starts
off not so badly, and doesn't improve so radically with MIC enabled.
However, this stuff isn't necessarily going to help you with a sigma-delta
(although Ken Kundert has written a paper on characterising sigma-delta
converters using SpectreRF - I've not really read the paper properly yet, so
I can't comment on it. The paper is on http://www.designers-guide.com )

Kind regards,

Andrew.

On Mon, 07 Jul 2003 03:15:38 -0700, rahul <rahuls@hrl.com> wrote:

My apologizes Andrew, I got a bit carried away.
Well the benchmark is quite specific to what we
do over here, CT Sigma Delta modulators and this circuits
take for ever to simulate. To get a descent notch (NTF)
I force spectre to run in Trapezoidal mode because
my simulator (HAARSPICE) runs in this mode, by gradually changing
the max step size I see the notch go down till it hits
-170Db. The noise floor is at approx=-45DB therefore the
magic number 125dB Now if we add the carrier which is
another 55 db, the DR will be 180Db

I am using factory defaults so my reltol 1e-3

If you talk with M. Steer (from NCSU) his benchmark
circuits give 40Db DR so the definition of DR and the
circuit used changes. For my applications with idealised
Verilog-A model and transistors I get this numbers.
I don't fake it this is what I get. There is nothing wrong
in reporting the truth.

Well, again I am sorry for my uncivilised comments.
(lowly Analog designer simulating a DAC at 3.00 am PT)

Regards
Rahul




Andrew Beckett wrote:
Rahul,

Actually, I _do_ have a patent (granted) on a data converter.
US patent number 5870052.
I was an analog and mixed signal designer for ~10 years before joining
Cadence (and have done some design work since joining Cadence too).
My main area was indeed data converters and low power communication
systems. This was a bad choice to hit me with...

So please don't be so presumptuous (actually I thought you were pretty
rude). I have both a software and design background. Just because I
can write decent SKILL code doesn't mean I know nothing about
analog design.

Now, are you just running a transient and then doing an fft? One easy
way to improve the noise floor is to use the strobeperiod option on
transient analysis, and arrange that the strobeperiod ties up with the
sample interval for the fft. Remember that dft in the Artist calculator always
gives you a power of 2 samples, even if you ask for a different number.
Of course it's a good idea to tighten tolerances and so on as well. You may
want to limit maxstep in some circuits to force more timepoints to improve
the tracking (this is often useful in very linear circuits).
Note, strobeperiod forces the simulate to take a timepoint at
the strobe point, which reduces the amount of interpolation
that needs to be done during the fft sampling.

Of course, you may be doing all this already - so please forgive me
if I know less than you about design ;-

I have seen plenty of circuits with lower noise floor than you describe.
Many of these are customer (i.e. real) examples.

Andrew (a lowly SKILL programmer)

On Sun, 06 Jul 2003 23:40:54 -0700, rahul <rahuls@hrl.com> wrote:


Well, then design a circuit and show it to me.
Here at Hughes we have been designing Sigma delta
modulators for over 20 years and have got a max of
120dB-125dB dynamic range based on the formula I
provided you.

Andrew you are good at Skill programming, stick to
that. I am sure you do not have any patents pending
on data converters

Thanks for all the information
Rahul






Andrew Beckett wrote:

Rahul,

I have had spectre give a numeric noise floor of over 200dB down (even 275dB -
approaching the machine limits). It just depends on what you're doing and how
you're doing it... various controls can give a pretty low numeric noise floor,
and so you can't make a sweeping statement about spectre having a Dynamic
Range of 123dB. It's not that simple!

Andrew.


On Fri, 04 Jul 2003 16:20:50 -0700, rahul <rahuls@hrl.com> wrote:



hello Andrew and Herald

You have hit the bull's eye !!! Andrew is correct, that
spectre wouldn't work unless you let the simulator run
for 10 days with an infinitesimal time step. The limitation
is the simulator Dynamic Range. I have done some work
on this and will be soon publishing my work at a DARPA
conference in August. I use a 4th order idealised Bandpass
continuous time sigma delta modulator as my test circuit
(I will send you the reference when the paper gets accepted
at BMAS) The idea is to force the simulator in TRAP only mode
(with SKIP dc) option and then let the simulation run. I found
with SPECTRE I get a dynamic range of 123dB for 5u secs (which
takes a few minutes depending on the step size). I have come
to the conclusion that spectre has a DR of 123Db
Here my DR = av noise floor - input carrier
-----------------------------------
lowest point in the Noise Transfer curve


This is the reason we are developing our own simulator
using wavelets so that we can improve the DR by capturing
sharp transitions using Haar wavelets. Well, rest of my work
is classified so cannot give out too much information.

Thanks for all the info

Rahul



Andrew Beckett wrote:


Harald,

Use spectreRF (it doesn't have to just be used for RF). See

http://www.designers-guide.com/Analysis/sc-filters.pdf

I agree, transient noise is not a good approach. I've made some
comments about transient noise in earlier appends in this group (check google),
which essentially agree with what you're saying. The paper above is
talking about sc-filters, but it could probably apply to an ADC. There's
another paper on Ken's site about simulating sigma-delta converters with
spectreRF too (not read that yet though).

Andrew.

On 4 Jul 2003 08:28:47 -0700, haneu@illegal.de (Harald Neubauer) wrote:




Hi,
ok, we agree, that this is distortion, but how could i calculate
signal to (stochastic) noise in a switched cap circuit with spectre?
This is something, what really worries me a long time now!
I would like to know how noise is transferred through a switched-cap
circuit (such as a adc but in reality i'm looking for more).
I know that there is such a possibility in eldo, but our main
simulator is spectre, so i would like to stick to that...(and that
might go to another newsgroup
One suggestion is to add a transient noise source. This is basically a
transient file generated by a mathematical program (matlab or such).
But i'm still concerned about accuracy then. Noise tends to have a
huge bandwidth, so either simulation can get awful slow (small
timesteps because of huge frequency) or inaccurate (because simulation
chooses huge timesteps compared to noise bandwidth).
Just adding it to the transient seem not to be reliable?
Any thoughts about that? Anything in the pipeline at cadence?
Regards Harald


rahul <rahuls@hrl.com> wrote in message news:<3F0528E5.50403@hrl.com>...



You are right that it is distortion.

--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd

--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd


--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd

--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd

 

[Andrew Beckett]

I'm assuming from your email address that you're in the UK, in which case I'm
assuming that you got your software via EuroPractice?

Normally those who get their software via the university program don't get
sourcelink access (I believe). For support you need to go to EuroPractice
http://www.europractice.com/ and if you follow the links you'll end up
at:
http://www.te.rl.ac.uk/europractice/

Regards,

Andrew.

On 7 Jul 2003 21:52:16 -0700, ramnathvg@yahoo.co.uk (Ramnath) wrote:

Hi
We got Cadence through university programme.We are unable to register
for the source link program.

please help us.
regards

--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd

 

[Saqib Q Malik]

Thanks Andrew and Erik. As a university client, students are not supposed
to go to Cadence directly but through our sysadmin. I will report this to
Cadence through him and hope for a fix (before classes start in fall?)

Thanks again for the workaround.

Saqib Malik
e-mail: saqib at iastate dot edu

"Erik Wanta" <erikwanta@starband.net> wrote in message
news:84018314.0307062102.5a3862a0@posting.google.com...

Saqib:
Yes, I have seen this behavior but I have been unable to determine
exactly what the problem is. Note that I don't have this problem if I
run in batch mode instead of interactive. Please try adding the
following to your .cdsenv:

spectre.envOpts controlMode 'string "batch"

---
Erik

"Saqib Q Malik" <sqmalik@DeleteThisIastate.edu> wrote in message
news:<be89mg$5bj$1@news.iastate.edu>...
Hello all. I have run into a problem with Spectre. After a few
simulations,
spectre does not use the new netlist and wants to keep on simulating the
same old netlist. The problem occurs after running sumulations on the
same
design a few times. The types of changes I make before resimulating may
be
in the circuit, design variables, and in the analysis type.
I am using Spectre through the Cadence Analog design environment (the
Artist environment formerly known as Affirma). I am at IC 5.0.0.500.37
and
Spectre version 5.0.0.050803. I have tried check-and-save in schematic
as
well as Netlist->Recreate in "environment" but to no avail. The only
way to
get Spectre to use the new netlist is by quitting the environment and
restarting from Schematic window. Saving state and loading state upon
restart reduces the disruption time but it is irritating and disrupting
nonetheless

Does anyone know the solution to this problem or a way to force Spectre
to
reread the netlist?

Any help is appreciated.

Thanks.
Saqib Malik
e-mail: saqib at iastate dot edu

 

[Jay Lessert]

"Saqib Q Malik" <sqmalik@DeleteThisIastate.edu> wrote in message news:<be89mg$5bj$1@news.iastate.edu>...

Hello all. I have run into a problem with Spectre. After a few simulations,
spectre does not use the new netlist and wants to keep on simulating the
same old netlist.

The behavior I'm used to seeing is that a running Spectre sim (in the
"Analog Design Environment" GUI) will decline to notice changes in the
netlist unless you explicitly:

Simulation->Stop

I always assumed this was a "feature". Are you seeing behavior
different from this?

-Jay-

 

[John Gianni]

"Simon Prendergast" <simon.prendergast@ntlworld.com> wrote:

Anyone have a .cdsplotinit for a HP750C?

1. Apparently HP-750C color pen plotters can handle PostScript2 & HPGL2.

2. Here's one sample entry for HPGL2 below ...

3. Please replace PRINTER_NAME with your printer name.


PRINTER_NAME|Hewlett-Packard DesignJet 750C: \
:manufacturer=Hewlett-Packard: \
:type=hpgl2: \
:spool=lp -d PRINTER_NAME: \
:query=lpstat -o PRINTER_NAME: \
:remove=cancel $1 PRINTER_NAME: \
:maximumPages#10: \
:resolution#1016: \
:black#1:cyan#2:magenta#3:yellow#4:blue#5:red#6:green#7:white#8: \
aperSize="A portrait" 8226 10706: \
aperSize="A landscape" 10766 7266 75 75: \
aperSize="B portrait" 10766 15902: \
aperSize="B landscape" 16862 9806: \
aperSize="C portrait" 16862 20982: \
aperSize="C landscape" 21942 15902: \
aperSize="D portrait" 21942 33174: \
aperSize="D landscape" 34134 20982: \
apersize="E portrait" 34134 43334: \

aperSize="A0 portrait" 33230 46190: \
aperSize="A1 portrait" 23350 32270: \
aperSize="A1 landscape" 33230 22390: \
aperSize="A2 portrait" 16390 22390: \
aperSize="A2 landscape" 23350 15430: \
aperSize="A3 portrait" 11470 15430: \
aperSize="A3 landscape" 16390 10510: \
aperSize="A4 portrait" 7990 10510: \
aperSize="A4 landscape" 11470 7030: \
aperSize="24 inches wide" 23984 0: \
aperSize="36 inches wide" 36176 0:

--
All my USENET posts under this nom d' Internet are my personal opinion!

 

[Andrew Beckett]

Trying to post this again... it showed up on our own news feed, but not
on google...

Erik,

Erm, I think this is something that would be much better off going via customer
support. Many of your questions here require detailed tool knowledge, which
in the main contributors here, is pretty likely to end up being me. You
shouldn't rely on me contributing all the time, because I do have a day job
(supporting and training European customers) to do...

Anyway, here's some (quick) answers:

On 3 Jul 2003 12:19:05 -0700, erikwanta@starband.net (Erik Wanta) wrote:

sevMenuItems(session name)
=> t/nil

Displays the menu item list that corresponds to the named menu item.

1. I open ADE
2. sevMenuItems(nil "Tools")
3. I get all the items from the Tools menu

Question 1:
Note how I gave nil for the session. Why did it still work?

sevMenuItems() returns a predefined menu items structure, intended
for use in the simui.menus file. It is not intended for use in general
SKILL code. To quote what it says about the sev functions in the
documentation:

"The sev functions are used by the Cadence Analog Simulation
Environment to build and maintain the information and interfaces
used by the environment. Most of these functions require the
session argument. The only method to obtain this argument is by
calling these functions from a .menus file."

If you call it, you'll notice that a number of the arguments
show 'nil. If you pass a reasonable session:

sevMenuItems('sevSession1 "Tools")

You'll see that the arguments change. So the function does not
return the _current_ menus - but the template of what menus
would be added.
Look at simui.menus in the installation to see how it extends
an existing set of t menus.

I added a menu item:
hiInsertMenuItem(evalstring(strcat("sevToolsMenu" sprintf(nil "%d"
hiGetCurrentWindow()~>sevSession~>number))) mySliderMenu
length(sevMenuItems(asiGetCurrentSession() "Tools"))+1)

I don't see the menu that I added in the output of sevMenuItems(nil
"Tools") or sevMenuItems(asiGetCurrentSession() "Tools") or
sevMenuItems(hiGetCurrentWindow()~>sevSession "Tools").

Question 2:
Why don't I see the menu that I added? I am assuming this is because
sevMenuItems only returns what is defined in the tool.menus file.

ADB: Yes. See above.

Question 3:
How do I get a count of the number of menu items?

For example, I want to know the number of menu items in the Tools menu
in ADE.

length(get(sevToolsMenu1 "_menuItemList")) works but I don't know the
name of the menu. That is, I need to get the session number and add
it to sevToolsMenu.

I tried the following:
menu=concat(sprintf(nil "sevToolsMenu%d"
hiGetCurrentWindow()~>sevSession~>number))
dprint(length(get(menu "_menuItemList")))

The problem is that menu is a symbol instead of a hiMenu.
type(menu)
symbol
type(sevToolsMenu1)
hiMenu

How about:

theMenu=car(exists(menu hiGetBannerMenus(window(4))
symeval(menu)->_menuTitle=="Tools"))
length(symeval(theMenu)->_menuItemList)

Note, dprint is a PRIVATE function...

Question 4:
How do I get the hiMenu?

;get artist window
window=hiGetCurrentWindow()

It seems the following doesn't work:
menu=nth(7 hiGetBannerMenus(window))
type(menu)
symbol

It seems the following doesn't work:
menu=geixGetMenuFromMenuListByName(hiGetBannerMenus(window) "Tools")
type(menu)
symbol

It seems the following doesn't work:
foreach(m hiGetBannerMenus(window)
when(rexMatchp("^sevToolsMenu" symbolToString(m))
menu=m
) ;when
) ; foreach
type(menu)
symbol

It seems the following doesn't work:
handle=sevMenuHandle(window~>sevSession "Tools")
menu=ahiGetMenu(handle)
*Error* eval: unbound variable - _ahiiUniqueSymbolmenusevToolsMenu11

symeval() as above.

Regards,

Andrew.

--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd

 

[Andrew Beckett]

Rob,

You shouldn't read from the map directory itself (or the amap) because the
format is private and liable to change (I wasn't sure from what you said
whether you were doing that or not).

However, asiMapInstanceName should work. I just checked. I had
an instance name and a net name both called "R2" at the top level
of my design:

l=list("/R2")
asiMapInstanceName("~/simulation/rcac/spectre/schematic" l) => "_inst0"

I'd run a simulation - it may not work before a simulation.
Also, you _must_ include the / at the beginning - using the leading
slash, and then slashes to delimit hierarchy (e.g. /I1/I2/M3 ) is how
it knows that you're asking for a schematic name rather than a netlist name.

Note, the function destructively modifies the list - so l afterwards
contains ("_inst0")

Regards,

Andrew.

On 7 Jul 2003 10:47:07 -0700, malleablecandy@yahoo.com (Rob W) wrote:

An update:

For the moment, I am directly parsing the netlister files within the
ihnl/ directory. This is working fine, but if there is a better way,
I'd appreciate any advice.

Thanks

Robert


malleablecandy@yahoo.com (Rob W) wrote in message news:<7b74bad.0307060135.4a352644@posting.google.com>...
Hello,

I've been trying to obtain the netlist mapping information after a
netlist is generated. The purpose is to map the netlist data
(subcircuits, instances, parameters, etc.) back to the schematic after
some netlist-based manipulation is done.

I have tested the asiMapInstanceName() function using various forms of
the instance-specifier list argument, but I must not be using it
correctly, because it always returns the original instance name (I
have verified that the instance being tested has been mapped within
the netlist).

I have observed that all of the information I need is stored in
various files within the netlister directory, i.e.
spectre/schematic/netlist/ihnl. Do I need to access these files
directly?

Thanks much,

Robert

--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd

 

[eda support guy]

It is possible to create a dummy printer definition to handle previewing
your postscript files. I have on the system a ghostview alike tool
called mgv , that accepts postscript sent to standard input.

This is how the cadence printer definition looks like:
#-----------------------------------------------------------------------------
#todo:
# -set weird 1016 dpi resolutions to 1200 for postscript, 600 for hpgl.
pagesizes accordingly
# -ensure latest plotcap.il is used by all 4.4.x cadence
#-----------------------------------------------------------------------------
genericPS_lvl2|Generic 1016 dpi Adobe PostScript Level 2 Plotter: \
:spool=/cadappl/mgv/3.1.5/bin/mgv.wrap: \
:manufacturer=Adobe: \
:type=postscript2: \
:maximumPages#65000: \
:resolution#1016: \
aperSize="A4 portrait" 7990 10510: \
aperSize="A4 landscape" 11470 7030: \
aperSize="A3 portrait" 11470 15430: \
aperSize="A3 landscape" 16390 10510: \
aperSize="A2 portrait" 16390 22390: \
aperSize="A2 landscape" 23350 15430: \
aperSize="A1 portrait" 23350 32270: \
aperSize="A1 landscape" 33230 22390: \
aperSize="A0 portrait" 33230 46190: \
aperSize="A portrait" 8226 9806: \
aperSize="A landscape" 10766 7266: \
aperSize="B portrait" 10766 15902: \
aperSize="B landscape" 16862 9806: \
aperSize="C portrait" 16862 20982: \
aperSize="C landscape" 21942 15902: \
aperSize="D portrait" 21942 33174: \
aperSize="D landscape" 34134 20982: \
apersize="E portrait" 34134 43334:
#-----------------------------------------------------------------------------
genericPS_lvl1|Generic 1016 dpi Adobe PostScript Level 1 Plotter: \
:spool=/cadappl/mgv/3.1.5/bin/mgv.wrap: \
:manufacturer=Adobe: \
:type=postscript1: \
:maximumPages#65000: \
:resolution#1016: \
aperSize="A4 portrait" 7990 10510: \
aperSize="A4 landscape" 11470 7030: \
aperSize="A3 portrait" 11470 15430: \
aperSize="A3 landscape" 16390 10510: \
aperSize="A2 portrait" 16390 22390: \
aperSize="A2 landscape" 23350 15430: \
aperSize="A1 portrait" 23350 32270: \
aperSize="A1 landscape" 33230 22390: \
aperSize="A0 portrait" 33230 46190: \
aperSize="A portrait" 8226 9806: \
aperSize="A landscape" 10766 7266: \
aperSize="B portrait" 10766 15902: \
aperSize="B landscape" 16862 9806: \
aperSize="C portrait" 16862 20982: \
aperSize="C landscape" 21942 15902: \
aperSize="D portrait" 21942 33174: \
aperSize="D landscape" 34134 20982: \
apersize="E portrait" 34134 43334:
#-----------------------------------------------------------------------------
encapsulatedPS|Encapsulated PostScript: \
:spool=/cadappl/mgv/3.1.5/bin/mgv.wrap: \
:manufacturer=Adobe: \
:type=epsf: \
:maximumPages#1: \
:resolution#1016: \
aperSize="A4 portrait" 7990 10510: \
aperSize="A4 landscape" 11470 7030: \
aperSize="A3 portrait" 11470 15430: \
aperSize="A3 landscape" 16390 10510: \
aperSize="A2 portrait" 16390 22390: \
aperSize="A2 landscape" 23350 15430: \
aperSize="A1 portrait" 23350 32270: \
aperSize="A1 landscape" 33230 22390: \
aperSize="A0 portrait" 33230 46190: \
aperSize="A portrait" 8226 9806: \
aperSize="A landscape" 10766 7266: \
aperSize="B portrait" 10766 15902: \
aperSize="B landscape" 16862 9806: \
aperSize="C portrait" 16862 20982: \
aperSize="C landscape" 21942 15902: \
aperSize="D portrait" 21942 33174: \
aperSize="D landscape" 34134 20982: \
apersize="E portrait" 34134 43334:

And the wrapper script looks like this
#!/usr/bin/ksh
# wraparound for mgv, gives the library path and sets options
export SHLIB_PATH=/cadappl/X11/lib:$SHLIB_PATH
/cadappl/mgv/3.1.5/bin/mgv -interpreter $CADENV_HOME/cadbin/gs \
-prefix /cadappl/mgv/3.1.5/share/mgv/3.1.5/help/ \
-noantialias -magstep 1 -editres $@ &

but it is unnecessary if you have (unlike us) mgv properly installed and
configured.


the same approach can be used with any script in order to generate svf,
pdf , shockwave flash, windows metafile, or frozen utter crxp ;-) files,
But then the devil is in configuring those converters.

Has anyone succeeded in generating WMF files from schematics ? I tried
only ghostscript for this. To no avail, but I saw recently that there is
also a "libwmf" on linux.

The problem with this "previewer" setting is that df2 will wait until
the mgv job terminates (the user clicks close), so it is impossible to
edit schematics,layout, waveform or whatever while viewing in mgv.

Erik Wanta wrote:

Gerry:
I typically plot waveforms to generic level 2 postscript (plot.ps) and
then run ps2pdf plot.ps. The resulting pdf has a white background
with the same colors that were displayed in awd.
---
Erik

G Vandevalk <van@nortelnetworks.com> wrote in message news:<3EF3697F.9060806@nortelnetworks.com>...

I have several users who create waveform plots that they go on to
present at meetings.

They view the plots on the screen (black background) and then create
plots (white background)
and are often dissapointed at the resulting visibility of some colors.

I have been told that it is possible to make the3 background white, but
I cannot figure it out.


-- Gerry

 

[Erik Wanta]

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@DELETETHISBITcadence.com> wrote in message news:<ccgfiv0n3sn18nf3c773mo5asfcdht4q4n@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

 

[Erik Wanta]

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@starband.net (Erik Wanta) wrote in message news:<84018314.0307300939.206fd778@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@DELETETHISBITcadence.com> wrote in message news:<ccgfiv0n3sn18nf3c773mo5asfcdht4q4n@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 Beckett]

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@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@starband.net (Erik Wanta) wrote in message news:<84018314.0307300939.206fd778@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@DELETETHISBITcadence.com> wrote in message news:<ccgfiv0n3sn18nf3c773mo5asfcdht4q4n@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 Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd

 

[eda support guy]

Andrew,

It is indeed a bit of work to implement that all virtually shorted net
names are for the simulator just aliases for the same net, while a pin
name is to be treated as a fraction of the M'ed up pin. And it is also
true that the benefit would not extend to analyses where
components/branches with identical parameters are to be treated as
different (like DCmatch and MC).

As for the reasons why people will enter vectors or even explicitly
place identical instances in parallel, here are a few I can remember of:
- the support for M is buggy is either CDF, simulators' netlister, or
diva/dracula/assura (ext or lvs) ruledeck.
- the M'ed pcells do not satisfy the needs of layout ( rings for latchup
prevention, contacts to increase conductance to backgate, interdigitated
or cross-quad placement for matching ...)

That is probably for one of those reasons that pushed Austria
Mikrosystem to disable the m factor. There is extra schematic capture
effort involved in using vectors instead of M parameter. Since it is not
the path of least resistance, one can be confident that designers do not
do this gratuitously. Do you (cadence corp) have a set of "real life"
schematics from customers ? If so, statistics can be made, to check how
often it happens and thus how much simulation improvement it would bring.

Since I m new to the newsgroup, I take the occasion to thank you for
keeping it lively.

Andrew Beckett wrote:

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 Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd

 

[Andrew Beckett]

That would be ipcKillProcess(ipcId)

Andrew.

On 1 Aug 2003 09:18:07 -0700, erikwanta@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 Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd

 

[Erik Wanta]

Carol:
Do you mean that they are lr and nr in your model file? If so, you
can use prop Mapping to have it netlist m as nr and l as lr. See the
CDF User Guide.
---
Erik

wubin_98@yahoo.com (Bin Wu) wrote in message news:<ef46a08.0308010846.2ca6c503@posting.google.com>...

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

 

[Erik Wanta]

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@DELETETHISBITcadence.com> wrote in message news:<837hiv00p9esmlk837o5g5dctnjgvuoa8o@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@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@starband.net (Erik Wanta) wrote in message news:<84018314.0307300939.206fd778@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@DELETETHISBITcadence.com> wrote in message news:<ccgfiv0n3sn18nf3c773mo5asfcdht4q4n@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 Beckett]

Erik,

The IPC id is a handle like any other handle (ports, dbobjects, windows etc).
There is a variety of information held behind the scenes (process id, hostname,
at least). Getting this information is not really public - in fact I'm not sure
you can (because there's other stuff going on behind the scenes which
facilitates remote processes, synchronisation of the child process and so on).

Like most of these handles or objects, you can't recreate them, and since this
is a reasonable way to reference a submitted process, you should store it
somewhere (in fact a few releases back, if you didn't store it somewhere,
the ipcId could get garbage collected - because it thought that nothing was
using it, and there was a trigger to kill the process when that happened!
Luckily that was fixed some time back).
Now, it doesn't necessarily need to be stored in a global variable; it could
be stored in a global array of some kind, or as a property on a window or
form, or in a SKILL++ lexically scoped variable, but it needs to be stored
somewhere if you're going to reference it later.

Regards,

Andrew.

On 1 Aug 2003 20:17:17 -0700, erikwanta@starband.net (Erik Wanta) wrote:

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@DELETETHISBITcadence.com> wrote in message news:<icalivose5t58jjntarfngv701bukbpab9@4ax.com>...
That would be ipcKillProcess(ipcId)

Andrew.

On 1 Aug 2003 09:18:07 -0700, erikwanta@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 Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd