Stats

  • Locked Locked
  • Replies 6
  • Subscribers 144
  • Views 16878
  • 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

Finding all paths in a cell and increase width

Lynks

I never used SKILL before but I decided to put one together to migrate a cell library. 

The final piece I am missing is finding all paths on a particular metal layer (e.g. M1) whose width is less than 0.1 um. Once found, I'd like to set the width of all those paths to be 0.1 um. I tried searching a bit but the solutions I found were assuming the paths are selected already. In my case, I am iterating through all the cells in my library and opening the layout view. By the way, when I mention 'paths', they show up as 'path segments' in Layout XL (created by using the wire command Ctrl+Shift+W). I am not sure what the difference is between these two.

Any help on the above (assuming I already have the appropriate cv opened through dbOpenCellViewByType()) would be great.

Aside from that, this forum provided nice solutions for changing metal layers and replacing vias with new ones, and I was able to use them in my migration script. 

Parents
  • Andrew Beckett

    tweeks said:
    Two years ago I switched to using Lisp style so I could take advantage of Emacs' Lisp mode (since I was too lazy to write one for infix SKILL)

     

    I too tend to write in Lisp style (and have done so for 20 years or so), for a few reasons. One was that I used to write a lot of C code, and SKILL was different enough from C that I kept making mistakes. Secondly I was somewhat familiar with Lisp and writing in Lisp syntax tended to encourage me to think in terms of Lisp ways of doing things. Thirdly "vi" has a lisp mode (I'm a vi rather than emacs user). Fourthly I'm a bit perverse...

    That said, I do tend to revert to C style when I am trying to illustrate examples or ideas, because I know the majority of the SKILL user-base uses C style and I don't want them to be put off by the "Lots of Irritating and Superflous Parentheses"...

    tweeks said:
    Don't make a habit of putting close-parentheses on lines by themselves; Lisp programmers find this disconcerting.

    That said, I do tend to shy away from excessive numbers of close parentheses on the same line - I'm not rigid on this, but I try to consider readability over compactness...

    Regards,

    Andrew.

     

Reply
  • Andrew Beckett

    tweeks said:
    Two years ago I switched to using Lisp style so I could take advantage of Emacs' Lisp mode (since I was too lazy to write one for infix SKILL)

     

    I too tend to write in Lisp style (and have done so for 20 years or so), for a few reasons. One was that I used to write a lot of C code, and SKILL was different enough from C that I kept making mistakes. Secondly I was somewhat familiar with Lisp and writing in Lisp syntax tended to encourage me to think in terms of Lisp ways of doing things. Thirdly "vi" has a lisp mode (I'm a vi rather than emacs user). Fourthly I'm a bit perverse...

    That said, I do tend to revert to C style when I am trying to illustrate examples or ideas, because I know the majority of the SKILL user-base uses C style and I don't want them to be put off by the "Lots of Irritating and Superflous Parentheses"...

    tweeks said:
    Don't make a habit of putting close-parentheses on lines by themselves; Lisp programmers find this disconcerting.

    That said, I do tend to shy away from excessive numbers of close parentheses on the same line - I'm not rigid on this, but I try to consider readability over compactness...

    Regards,

    Andrew.

     

Children
No Data

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.