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.
RonSill said:This is a problem and probably has something to do with the way the pcell was created.
Actually it's probably more to do with how the abutFunction for the device has been created. This is supposed to adjust the parameters on the pcell during an abutment or unabutment event - and clearly it is not doing the right thing. This is a fault of the PDK (most likely), and you should take it up with whoever created or supplied the PDK.
RonSill said: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.
I have never seen such an option before, so it must be a peculiarity of your PDK/library. There is no generic capability to disable callbacks, so something must have been coded specially for your PDK. As such I can't answer your last paragraph, because it is all very specific to your design kit. I'd need to know what the parameters are that contrl the source/drains. Also, modifying the instances by SKILL won't trigger the CDF callbacks anyway - so it should just be a matter of setting the appropriate (whatever they are) parameters to control the source/drains.
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?
When you dump the pcell code, you are looking at the superMaster of the pcell. This does not include the abutment code but the two parameters you mentioned, leftDiffState and rightDiffState sound like that they control the diffusion during abutment.
The abutment function should have saved the original state of the parameters on the abutment group but it doesn't look like it. You could find the abutment function assigned to the pins and fix it or you could restore the default value to the parameter once you have un-abutted the instances.