Copy a schematic and change parameter values

Discussion in 'Cadence' started by marcoballins, Sep 9, 2008.

  1. marcoballins

    marcoballins Guest

    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
     
    marcoballins, Sep 9, 2008
    #1
  2. marcoballins

    S. Badel Guest

    I am using design variables for some parameters of my schematic.
    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
     
    S. Badel, Sep 9, 2008
    #2
  3. marcoballins

    marcoballins Guest


    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
     
    marcoballins, Sep 9, 2008
    #3
  4. 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.
    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.
    It's not complicated - see above.
    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?
    Regards,

    Andrew.
     
    Andrew Beckett, Sep 12, 2008
    #4
  5. marcoballins

    marcoballins Guest

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

    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.

    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().

    Thanks for the receipt.

    I don't care.

    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
     
    marcoballins, Sep 12, 2008
    #5
  6. 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.
     
    Andrew Beckett, Sep 12, 2008
    #6
  7. marcoballins

    marcoballins Guest


    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
     
    marcoballins, Sep 12, 2008
    #7
  8. marcoballins

    S. Badel Guest

    thanks for the suggestions.
    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
     
    S. Badel, Sep 12, 2008
    #8
  9. marcoballins

    marcoballins Guest


    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.

    Why does it add an additional level in the hierarchy?

    KR,
    Marco
     
    marcoballins, Sep 12, 2008
    #9
Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.