Stats

  • Locked Locked
  • Replies 3
  • Subscribers 143
  • Views 3546
  • 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

abutment and controlling S/D dropping

RonSill

I am an end user layout engineer. I am not a developer of PDKs or Pcells, etc. so I am at the mercy of what is given me to use for the most part. I do develop SKILL code for automation of the layout task. One of the problems we encounter is when we abut pcell mos devices and the source/drain of one of the abuted devices drops off. That is all fine except sometimes when you pull the devices back apart the source/drain does not come back. This is a problem and probably has something to do with the way the pcell was created. If I happen to instantiate any new pcells of the same type the source/drain will also be missing on the new device as well. 

As an end user in most libraries I found that if I view the properties of the pcell most our libraries have a 'disable callback' button I can click on, apply the form, then click off and re-apply the form and the source/drain comes back and all is well.

My issue is that I am developing some Skill code that copies a selected pcell into another view, flattens it and extracts data but I need the source/drain to always be there so I can extract data off the shapes. Is there a way I can trigger this new view copy to get the source/drains back? Is there a Cadence functional way to maybe disable and re-enable calbacks to it to maybe do with Skill code what I do manually? I've been looking and can't seem to find an answer.

Parents
  • RonSill

     Andrew,

    Thank you for your reply. It confirms what I thought might be the answer. I do believe the callback in our param form is custom to us. Unfortunately I as an end user I have no control over this and also want to make my Skill code as generic as I can since we use many PDKs at my place and they are bound to be inconsistent in how, and even if, this callback function is even done. 

    I've been exploring a new angle. Maybe use the pcSkillGen and pcGenCell options. I can generate the procedure code that generates the cell, read and edit the code and read it back in. I noticed that when I generate the procedure on a mos device that has it's S/D gone there is a list parameter called "leftDiffState" "string" "SharedWithContact" (or "rightDiffState") and if I delete this/these parameters from the list and read everything back in then the S/D will come back. My only question is that since I use a Cadence function to generate this I wonder if the procedure it dumps out will always use the same named parameter for this condition. I plan on trying it out on a few different PDKs to see but I wonder if you know for sure. 

    So if this is consistent then my next step wil be to incorporate some Skill code to read the file in, find the proper lines, and write the file back out without those lines, then load and execute the procedure.

     Does this sound like a reasonable approach?

    Ron

Reply
  • RonSill

     Andrew,

    Thank you for your reply. It confirms what I thought might be the answer. I do believe the callback in our param form is custom to us. Unfortunately I as an end user I have no control over this and also want to make my Skill code as generic as I can since we use many PDKs at my place and they are bound to be inconsistent in how, and even if, this callback function is even done. 

    I've been exploring a new angle. Maybe use the pcSkillGen and pcGenCell options. I can generate the procedure code that generates the cell, read and edit the code and read it back in. I noticed that when I generate the procedure on a mos device that has it's S/D gone there is a list parameter called "leftDiffState" "string" "SharedWithContact" (or "rightDiffState") and if I delete this/these parameters from the list and read everything back in then the S/D will come back. My only question is that since I use a Cadence function to generate this I wonder if the procedure it dumps out will always use the same named parameter for this condition. I plan on trying it out on a few different PDKs to see but I wonder if you know for sure. 

    So if this is consistent then my next step wil be to incorporate some Skill code to read the file in, find the proper lines, and write the file back out without those lines, then load and execute the procedure.

     Does this sound like a reasonable approach?

    Ron

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.