Copy a schematic and change parameter values

Hi all,

I am using design variables for some parameters of my schematic.
I would like to make a copy of that schematic and, in that new cell,
substitute the design variables with numeric values (which I've
determined by playing around with the design variables in the original
schematic).
How can do all this in SKILL?

Maybe this has any easy answer, but I am still lost.

Thanks.
Kind regards,
Marco

 

[S. Badel]

I am using design variables for some parameters of my schematic.
I would like to make a copy of that schematic and, in that new cell,
substitute the design variables with numeric values (which I've
determined by playing around with the design variables in the original
schematic).
How can do all this in SKILL?

I think you're asking for exactly this :

http://groups.google.com/group/comp.cad.cadence/browse_frm/thread/a0bf0ae10662a3fb

See Andrew's solution with default CDF values in the above post ; I like it...

Stéphane

 

On Sep 9, 5:39 pm, "S. Badel" <stephane.ba...@REMOVETHISepfl.ch>
wrote:

I think you're asking for exactly this :

http://groups.google.com/group/comp.cad.cadence/browse_frm/thread/a0b...

See Andrew's solution with default CDF values in the above post ; I like it...

Thanks for the link! Yes that's what I was looking.

I also like Andrew's solution of using component parameters instead of
design variables.
But how can change a component parameter from SKILL? I cannot find it
in the Cadence documentation...

However if I want to use a parametric analysis, the variable must be a
design variable and cannot be a component parameter, can it?

I also see two little complications in using the component parameters:
1) I would need to edit the CDF for every new design variable I want
to add (and I still do not understand all the details: I had a look at
a CDF file two days ago for the first time!).
2) Your approach (instantiate a new copy where the design variables
are replaced with numeric values) appears to me as safer, because you
actually remove in the new view the possibility to modify those values
(unless editing the cell). While in Andrew's approach, it is still
possible to override default values. So to make sure they actually
have the default value you have to go through all your cell instances
and check that those fields are empty (i'm thinking about doing this
in the GUI now).
3) You may want to hide, in your new instantiated cell, what were the
values you were playing with (using the design variables), and have a
cleaner cell.

However I am still not sure whether my approach is a good one.

Looking forward to hearing your comments,
Marco

 

[Andrew Beckett]

marcoballins@gmail.com wrote, on 09/09/08 17:50:

On Sep 9, 5:39 pm, "S. Badel" <stephane.ba...@REMOVETHISepfl.ch
wrote:

I think you're asking for exactly this :

http://groups.google.com/group/comp.cad.cadence/browse_frm/thread/a0b...

See Andrew's solution with default CDF values in the above post ; I like it...


Thanks for the link! Yes that's what I was looking.

I also like Andrew's solution of using component parameters instead of
design variables.
But how can change a component parameter from SKILL? I cannot find it
in the Cadence documentation...

Not sure quite what you want to do here. It's a matter of putting
pPar("mywid") as (say) the width of a transistor - you could use the
same pPar() on multiple devices in the schematic.

Then you need "mywid" to show up in the CDF for that cell. If you've not
created the symbol yet, then doing Create->CellView from CellView to create
the symbol will automatically build the CDF for you. Alternatively, you
could do it again in "modify" mode, and it will just update the CDF. Or
if you like SKILL, you can do:

artGenerateHierSymbolCDF(geGetEditCellView())

Then you need to go to Tools->CDF->Edit CDF, pick "Base" and select
the cell you're working on. Define the default values of all the CDF
parameters you just created.

In your testbench, you can then instantiate the block, and where it
says "mywid" you can override the default with your design variable
"varwid" and sweep that to your heart's content.

However if I want to use a parametric analysis, the variable must be a
design variable and cannot be a component parameter, can it?

In ADE XL in IC61, you can alter a component parameter directly, but in ADE L
(and IC5141 ADE), in the parametric tool, you need to sweep design variables.

I also see two little complications in using the component parameters:
1) I would need to edit the CDF for every new design variable I want
to add (and I still do not understand all the details: I had a look at
a CDF file two days ago for the first time!).

It's not complicated - see above.

2) Your approach (instantiate a new copy where the design variables
are replaced with numeric values) appears to me as safer, because you
actually remove in the new view the possibility to modify those values
(unless editing the cell). While in Andrew's approach, it is still
possible to override default values. So to make sure they actually
have the default value you have to go through all your cell instances
and check that those fields are empty (i'm thinking about doing this
in the GUI now).

I'm not sure I'd class it as safer. You run the risk of having multiple copies
which get out of sync with the original. Also, if the block is lower in the
hierarchy, it could get messy.

Note that if you _have_ overridden the values, then at least you will get that
in simulation, layout, and LVS (provided you don't have trouble with evil CDF
callbacks, to use Stephane's term from the other posting!) - so I'm not sure
that would count as dangerous?

3) You may want to hide, in your new instantiated cell, what were the
values you were playing with (using the design variables), and have a
cleaner cell.

However I am still not sure whether my approach is a good one.

Looking forward to hearing your comments,
Marco

Regards,

Andrew.

 

On Sep 12, 7:11 am, Andrew Beckett <andr...@DcEaLdEeTnEcTe.HcIoSm>
wrote:

marcoball...@gmail.com wrote, on 09/09/08 17:50:
[...]
But how can change a component parameter from SKILL?  I cannot find it
in the Cadence documentation...

Not sure quite what you want to do here.

I meant set a new value for a component parameter, similarly to what I
can do with desVar(myVar newValue).

It's a matter of putting
pPar("mywid") as (say) the width of a transistor - you could use the
same pPar() on multiple devices in the schematic.

Then you need "mywid" to show up in the CDF for that cell. If you've not
created the symbol yet, then doing Create->CellView from CellView to create
the symbol will automatically build the CDF for you. Alternatively, you
could do it again in "modify" mode, and it will just update the CDF. Or
if you like SKILL, you can do:

artGenerateHierSymbolCDF(geGetEditCellView())

Then you need to go to Tools->CDF->Edit CDF, pick "Base" and select
the cell you're working on. Define the default values of all the CDF
parameters you just created.

In your testbench, you can then instantiate the block, and where it
says "mywid" you can override the default with your design variable
"varwid" and sweep that to your heart's content.

For design variables, the procedure of adding a new one is faster:
just need to fill the field with variable's name, without need to
modify anything else.

However if I want to use a parametric analysis, the variable must be a
design variable and cannot be a component parameter, can it?

In ADE XL in IC61, you can alter a component parameter directly, but in ADE L
(and IC5141 ADE), in the parametric tool, you need to sweep design variables.

I have "IC5141" (thanks for the hint in the other post!), so it seems
that I anyhow have to use design variables to run parametric analysis
with paramAnalysis().

I also see two little complications in using the component parameters:
1) I would need to edit the CDF for every new design variable I want
to add (and I still do not understand all the details: I had a look at
a CDF file two days ago for the first time!).

It's not complicated - see above.

Thanks for the receipt.

2) Your approach (instantiate a new copy where the design variables
are replaced with numeric values) appears to me as safer, because you
actually remove in the new view the possibility to modify those values
(unless editing the cell). While in Andrew's approach, it is still
possible to override default values. So to make sure they actually
have the default value you have to go through all your cell instances
and check that those fields are empty (i'm thinking about doing this
in the GUI now).

I'm not sure I'd class it as safer. You run the risk of having multiple copies
which get out of sync with the original.

I don't care.

Also, if the block is lower in the
hierarchy, it could get messy.

You mean because of Stephane's script? My goal is just to replace all
design variables with numeric values, at all hierarchy levels.

Kind regards,
Marco

 

[Andrew Beckett]

marcoballins@gmail.com wrote, on 09/12/08 09:38:

On Sep 12, 7:11 am, Andrew Beckett <andr...@DcEaLdEeTnEcTe.HcIoSm
wrote:
marcoball...@gmail.com wrote, on 09/09/08 17:50:
[...]
But how can change a component parameter from SKILL? I cannot find it
in the Cadence documentation...
Not sure quite what you want to do here.

I meant set a new value for a component parameter, similarly to what I
can do with desVar(myVar newValue).


It's a matter of putting
pPar("mywid") as (say) the width of a transistor - you could use the
same pPar() on multiple devices in the schematic.

Then you need "mywid" to show up in the CDF for that cell. If you've not
created the symbol yet, then doing Create->CellView from CellView to create
the symbol will automatically build the CDF for you. Alternatively, you
could do it again in "modify" mode, and it will just update the CDF. Or
if you like SKILL, you can do:

artGenerateHierSymbolCDF(geGetEditCellView())

Then you need to go to Tools->CDF->Edit CDF, pick "Base" and select
the cell you're working on. Define the default values of all the CDF
parameters you just created.

In your testbench, you can then instantiate the block, and where it
says "mywid" you can override the default with your design variable
"varwid" and sweep that to your heart's content.

For design variables, the procedure of adding a new one is faster:
just need to fill the field with variable's name, without need to
modify anything else.


However if I want to use a parametric analysis, the variable must be a
design variable and cannot be a component parameter, can it?
In ADE XL in IC61, you can alter a component parameter directly, but in ADE L
(and IC5141 ADE), in the parametric tool, you need to sweep design variables.

I have "IC5141" (thanks for the hint in the other post!), so it seems
that I anyhow have to use design variables to run parametric analysis
with paramAnalysis().


I also see two little complications in using the component parameters:
1) I would need to edit the CDF for every new design variable I want
to add (and I still do not understand all the details: I had a look at
a CDF file two days ago for the first time!).
It's not complicated - see above.

Thanks for the receipt.


2) Your approach (instantiate a new copy where the design variables
are replaced with numeric values) appears to me as safer, because you
actually remove in the new view the possibility to modify those values
(unless editing the cell). While in Andrew's approach, it is still
possible to override default values. So to make sure they actually
have the default value you have to go through all your cell instances
and check that those fields are empty (i'm thinking about doing this
in the GUI now).
I'm not sure I'd class it as safer. You run the risk of having multiple copies
which get out of sync with the original.

I don't care.


Also, if the block is lower in the
hierarchy, it could get messy.

You mean because of Stephane's script? My goal is just to replace all
design variables with numeric values, at all hierarchy levels.

Kind regards,
Marco

My point is really to think about parameterization as you do the design, rather
than retro-fit it. If you routinely parameterize devices, it's easy. Going
through to make them parameterized afterwards is obviously more awkward.

I just don't like the idea of having design variables (which are global) in
the designs themselves - because it's easy to forget about them, and then
you can have clashes when you bring together two blocks that happen to
use the same variable name. With passed parameters (pPar()), there is no
ambiguity.

If you use pPar(), all you need to do is have a design variable at the top
level (in the testbench) which you can then sweep. You never need to touch
the design after that. If you decide you want to keep a particular value
of a design variable, having swept it - you change the CDF default for
your pPar. Or set it on the instance in the real design. But no need to
go through the design and locate the 10 places it got used and change all of those.

Of course, your mileage may vary. I just found it to be a more structured way of
working. I used to work this way (along with all my colleagues) as a designer 15
years ago (even in the original Analog Artist (aka Edge or DF1)). It's a similar
thought process to programming - global variables bad, passed variables good.

Regards,

Andrew.

 

[S. Badel]

thanks for the suggestions.
About the problems related to using design variables: I know you are
perfectly right! That's why I wanted to delete all design variable
before starting to simulate a new circuit (to avoid potential
clashes).

I think I still need design variables for paramAnalysis(), however
I'll try to use component parameters for all other cases, in the way
you pointed out.
What function should I use to set the value of a component parameter
from SKILL? Is it dbREplaceProp (I saw Stéphane uses this function at
some point in this script) or another one?

I was also thinking that I could also do without the CDF, if I could
set the value of any component parameter I want (say the resistance of
a resistor) even if it's down in the hierarchy (say the cell specified
with design())
Is this possible?
Maybe an example might elucidate my needs: I want to optimize an
"amplifier" which is a cell inside another "testbench" cell where I
have an instance of the amp and the signal generators and power
supply.
I'd like to have some properties of the amp to be parametric: say I
want to optimize the width of one transistor.
Suppose it originally has a value of 100u or even no value set (from
the schematic UI).
Can I simply set the value with a call to some function (even if this
property is inside the cell instance and not at top cell)?

I think what Andrew suggests is to use pPar() everywhere in the *design*, and so-called
'design-variables' only in the *testbench* (which is the part that you actually simulate).

If the design is made with parameterization in mind, you'll use pPars everywhere you'd want to be
able to modify a value. At all levels of hierarchy. Therefore the top-level should have parameters
to control the complete hierarchy.

Let's take example of your amplifier, assuming it's a basic differential amplifier with one
differential pair and one current mirror. Say you'd want to optimize the transistor sizes of those.
You'd choose to name the parameters for width and length of the mirror as 'wm' and 'lm', and width
and length of the pair as 'wp' and 'lp'.

Now you'd set the width and length of the mirror transistor as pPar("wm") and pPar("lm"),
respectively. Same with the differential pair : pPar("wp") and pPar("lp").

Now you re-generate the cell CDF (artGenerateHierSymbolCDF). In your testbench, edit properties of
your amplifier, you have now 4 parameters (wm,lm,wp,lp). To these parameters, assign a design
variable (say, 'wm', 'lm', 'wp', 'lp', this time without pPar => these are design variables). In ADE
you can now assign them and sweep them at will.

Now let's say you build a voltage buffer with your amplifier, and want it to be parametric as well.
You just have one instance of your amplifier in a unity-gain configuration. You set the amp's
variables to pPar("wm") etc.. (this time with the pPar). Generate CDF, and your voltage buffer has
the four parameters that control the sizes of transistor inside the amplifier. You can simulate it
as part of a testbench in the same way as was done with the amplifier.

I fully agree with Andrew about this being the best way to do it. The only thing I'd wish (and the
reason why I wrote the script) is that it would be possible to fix values of the pPar to define a
particular configuration of a parametric design.

Because a layout is by definition fixed, it should have a corresponding schematic, with well-defined
values for the parameters. That could be accomplished, I guess, by creating a new cell,
instanciating a symbol of the parametric schematic, and setting hard values for the parameters, but
it introduces an additional level of hierarchy and additional work (must create all the pins, and
the wires, pfew...). In my case, I was doing standard cells and this operation was to be repeated
tens, hundreds of times... not for me So that was my fix to accomplish what I wanted, but by no
means do I think of this as a good solution...



Cheers,
Stéphane

 

On Sep 12, 3:03 pm, Andrew Beckett <andr...@DcEaLdEeTnEcTe.HcIoSm>
wrote:

My point is really to think about parameterization as you do the design, rather
than retro-fit it. If you routinely parameterize devices, it's easy. Going
through to make them parameterized afterwards is obviously more awkward.

I just don't like the idea of having design variables (which are global) in
the designs themselves - because it's easy to forget about them, and then
you can have clashes when you bring together two blocks that happen to
use the same variable name. With passed parameters (pPar()), there is no
ambiguity.

If you use pPar(), all you need to do is have a design variable at the top
level (in the testbench) which you can then sweep. You never need to touch
the design after that. If you decide you want to keep a particular value
of a design variable, having swept it - you change the CDF default for
your pPar. Or  set it on the instance in the real design. But no need to
go through the design and locate the 10 places it got used and change all of those.

Of course, your mileage may vary. I just found it to be a more structured way of
working. I used to work this way (along with all my colleagues) as a designer 15
years ago (even in the original Analog Artist (aka Edge or DF1)). It's a similar
thought process to programming - global variables bad, passed variables good.

Regards,

Andrew.

Hi Andrew,

thanks for the suggestions.
About the problems related to using design variables: I know you are
perfectly right! That's why I wanted to delete all design variable
before starting to simulate a new circuit (to avoid potential
clashes).

I think I still need design variables for paramAnalysis(), however
I'll try to use component parameters for all other cases, in the way
you pointed out.
What function should I use to set the value of a component parameter
from SKILL? Is it dbREplaceProp (I saw Stéphane uses this function at
some point in this script) or another one?

I was also thinking that I could also do without the CDF, if I could
set the value of any component parameter I want (say the resistance of
a resistor) even if it's down in the hierarchy (say the cell specified
with design())
Is this possible?
Maybe an example might elucidate my needs: I want to optimize an
"amplifier" which is a cell inside another "testbench" cell where I
have an instance of the amp and the signal generators and power
supply.
I'd like to have some properties of the amp to be parametric: say I
want to optimize the width of one transistor.
Suppose it originally has a value of 100u or even no value set (from
the schematic UI).
Can I simply set the value with a call to some function (even if this
property is inside the cell instance and not at top cell)?

Thanks.
Kind regards,
Marco

 

On Sep 12, 6:02 pm, "S. Badel" <stephane.ba...@REMOVETHISepfl.ch>
wrote:

I think what Andrew suggests is to use pPar() everywhere in the *design*, and so-called
'design-variables' only in the *testbench* (which is the part that you actually simulate).

If the design is made with parameterization in mind, you'll use pPars everywhere you'd want to be
able to modify a value. At all levels of hierarchy. Therefore the top-level should have parameters
to control the complete hierarchy.

Let's take example of your amplifier, assuming it's a basic differential amplifier with one
differential pair and one current mirror. Say you'd want to optimize the transistor sizes of those.
You'd choose to name the parameters for width and length of the mirror as 'wm' and 'lm', and width
and length of the pair as 'wp' and 'lp'.

Now you'd set the width and length of the mirror transistor as pPar("wm") and pPar("lm"),
respectively. Same with the differential pair : pPar("wp") and pPar("lp")..

Now you re-generate the cell CDF (artGenerateHierSymbolCDF). In your testbench, edit properties of
your amplifier, you have now 4 parameters (wm,lm,wp,lp). To these parameters, assign a design
variable (say, 'wm', 'lm', 'wp', 'lp', this time without pPar => these are design variables). In ADE
you can now assign them and sweep them at will.

Thanks, this clarifies to me some things. Sorry if I did not get it
before.

I thought you could actually set the value of a component parameter
from SKILL directly without the need of design variables.
Maybe I am using the wrong terms here...
Example of what I thought was possible (and maybe is...):
I have used pPar, in the way you showed, and now I have my amp where
it's component parameters are wm, lm, wp, lp.
Let's say I left those value empty when I added an instance of the amp
in the testbench schematic (but doesn't matter, I could have also
specified a value).
Can I assign a value to those parameters without using design
variables?
I thought there existed a function that worked like:
setComponentParameterValue(parameterName newValue)
where instance name is something like "/I0/wp", where wp is a
parameter of the instance "I0" of the amp, and newValue is e.g. 100u.
Does such a function exists?
I think I am a bit confused now....


Extra thought:
In case such a function existed and
in case it worked also down in the hierarchy (similarly to what you
can do when retrieve a value from results with pv(instance param)),
then, well, maybe I would not even need pPar at all.

Now let's say you build a voltage buffer with your amplifier, and want it to be parametric as well.
You just have one instance of your amplifier in a unity-gain configuration. You set the amp's
variables to pPar("wm") etc.. (this time with the pPar). Generate CDF, and your voltage buffer has
the four parameters that control the sizes of transistor inside the amplifier. You can simulate it
as part of a testbench in the same way as was done with the amplifier.

I fully agree with Andrew about this being the best way to do it. The only thing I'd wish (and the
reason why I wrote the script) is that it would be possible to fix values of the pPar to define a
particular configuration of a parametric design.

Because a layout is by definition fixed, it should have a corresponding schematic, with well-defined
values for the parameters. That could be accomplished, I guess, by creating a new cell,
instanciating a symbol of the parametric schematic, and setting hard values for the parameters, but
it introduces an additional level of hierarchy ...

Why does it add an additional level in the hierarchy?

...and additional work (must create all the pins, and
the wires, pfew...). In my case, I was doing standard cells and this operation was to be repeated
tens, hundreds of times... not for me So that was my fix to accomplish what I wanted, but by no
means do I think of this as a good solution...

Cheers,
Stéphane

KR,
Marco