• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Custom IC Design
  3. some questions after using abConvertComponentParams.il to...

Stats

  • Locked Locked
  • Replies 5
  • Subscribers 125
  • Views 11923
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

some questions after using abConvertComponentParams.il to do schematic porting

ringamp
ringamp over 4 years ago

Hi
I am using abConverComponetParams.il (SCCS Info: @(#) abConvertComponentParams.il 05/23/05.12:00:00 1.7) to do the schematic porting, it is very powerful. But there are some points I want to know how to make it work:

1. PDK X and PDK Y have different sheet resistance, So I want to some multiplication on resistor's Length after porting. I used something like ' sprintf(nil "%n" evalstring(val)*2) ' in the code example but the result showed that the number get rounded (like 13.82u actually 14u is used in computation). can anyone give an example how to write the correct expression ?

2. PDK X has some properties which can not be found PDK Y. So I find that after running the porting script, those properties become user property. How can I delete them ?

3. The MOSFET symbol in PDK X has 5 terminal (G, D, S, B, T) with one connected (T) with noConn in basic library. But in PDK Y, the corresponding MOSFET symbol has 4 terminal (G, D, S, B). So after running porting script, the noConn shows floating after schematic check. How Can I delete those noConn automatically?

4. the resistor symbol has 2 terminals in PDK X but 3 terminals in PDK Y. So I need to add one wire to the resistor after porting. How can I add a short wire with Label to this extra terminal automatically ?

Is anyone can give me a hand? BTW I am just start to learn the SKILL

  • Cancel
Parents
  • Andrew Beckett
    Andrew Beckett over 4 years ago

    That's a pretty old version - not sure where you got it from (can you let me know, so I can update the reference if that makes sense)? The version in this post is pretty much the latest (there's a slightly newer version, but it only fixes a minor issue; I may update that post at some point). That's version 1.13 from 2019 rather than 1.7 from 2005.

    Some answers for your questions:

    1. Either use %N (rather than %n) in the sprintf: sprintf(nil "%N" evalstring(val)*2) (which gives you exponential format if that makes more sense) or use something like aelSuffixNotation(evalstring(val)*2) or maybe aelSuffixNotation(cdfParseFloatString(val)*2) .
    2. This is supported in a newer version than that which you're using - you'll see from the comments at the top that you can now specify the new parameter name in the params map as nil and that causes the property to be deleted
    3. There's nothing in the code to do this - you'd have to write some code to search for any instances of noConn and delete them - but it's slightly tricky because it would need a check to see if the noConn is on top of a wire or a pin. I don't have code to do this right now
    4. The newer version has a postProcess option that could be used to write code to add a wire stub and label. Again, hard to write something without details on precisely what is needed (I have some other code for wiring up when symbols have changed, but it very much needs tuning to a particular need). 

    Perhaps you could contact customer support? You can ask the AE to contact me and I can certainly look at this with some real examples and make abConvertComponentParams better at handling this? That said, it's unlikely to be in the next couple of weeks as I'm busy this week and on vacation next week...

    Andrew

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • Andrew Beckett
    Andrew Beckett over 4 years ago

    That's a pretty old version - not sure where you got it from (can you let me know, so I can update the reference if that makes sense)? The version in this post is pretty much the latest (there's a slightly newer version, but it only fixes a minor issue; I may update that post at some point). That's version 1.13 from 2019 rather than 1.7 from 2005.

    Some answers for your questions:

    1. Either use %N (rather than %n) in the sprintf: sprintf(nil "%N" evalstring(val)*2) (which gives you exponential format if that makes more sense) or use something like aelSuffixNotation(evalstring(val)*2) or maybe aelSuffixNotation(cdfParseFloatString(val)*2) .
    2. This is supported in a newer version than that which you're using - you'll see from the comments at the top that you can now specify the new parameter name in the params map as nil and that causes the property to be deleted
    3. There's nothing in the code to do this - you'd have to write some code to search for any instances of noConn and delete them - but it's slightly tricky because it would need a check to see if the noConn is on top of a wire or a pin. I don't have code to do this right now
    4. The newer version has a postProcess option that could be used to write code to add a wire stub and label. Again, hard to write something without details on precisely what is needed (I have some other code for wiring up when symbols have changed, but it very much needs tuning to a particular need). 

    Perhaps you could contact customer support? You can ask the AE to contact me and I can certainly look at this with some real examples and make abConvertComponentParams better at handling this? That said, it's unlikely to be in the next couple of weeks as I'm busy this week and on vacation next week...

    Andrew

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Children
  • ringamp
    ringamp over 4 years ago in reply to Andrew Beckett

    Hi Andrew,

    I found the old version  here.

    1. works well if I changed to %N.

    2. newer version I can delete the user property. one thing after I tried is: in PDK_A, "m" is a string but in PDK_B "m" is int type. can you give an example how to do the mapping in this situation ? I wrote ("m“ ”m“ int) in the Params section. It didn't work.

    3. I just want to know is it the script support that poring A device in PDK_A to nil in PDK_B, if so, I think it might be use to delete something.

    4.  you mean using something like "schHiCreateWire" in the postProcess ?

    I will talk with AE if he come next-time. thanks for your help!

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Andrew Beckett
    Andrew Beckett over 4 years ago in reply to ringamp

    Answering your questions:

    2. You'd need to create a function to convert the string parameter to an integer, and also specify the type as the fourth entry in the params element (see the comments at the top). So for example:

    procedure(RINGAMPstringToInt(inst paramName val)
        atoi(val)
    )

    and then in the params section, you'd have:

       ("m" "m" RINGAMPstringToInt "int") ; fourth element is the type of the new property - the default is the same as the old property.

    3. No, there's nothing in the code to delete an instance right now. Mapping to nil just wouldn't work.

    4. Yes - something like that.

    Andrew

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • ringamplifier
    ringamplifier over 4 years ago in reply to Andrew Beckett

    add one questions:

    if the device W & L parameter is something like "Ppar("nw")" "Ppar("nl")", how to write the mapping function ?

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Andrew Beckett
    Andrew Beckett over 4 years ago in reply to ringamplifier

    What needs mapping here? Use of pPar() is a design decision - it's unclear what you're expecting to be mapped.

    Andrew 

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information