In my design I'm using nmos4 and pmos4 active devices from AMS DKIT 3.70 PRIMLIB library. As shown in the figure, when I try to edit their properties in Virtuoso Schematic, their area and perimeter fields are recalculated for w and l values (and are not editable for that reason). So, there is no problem when I assign numerical values to w and l, but when I parametrize those variables (to do parametric analysis with the Analog Environment or to pass symbols parameters down through design hierarchy with "pPar") the area and perimeter values are miscalculated. In fact, they are not recalculated, and the last calculated numerical values remain fixed regardless the actual value the parameters take. I guess this is really no a Cadence issue, but a DKIT one. However, I need to get around this inconvenient and I don't know how to do that.
Thanks in advance for your help.
Unfortunately this is one of the dangers of CDF callbacks that I describe in sourcelink solution 11223092. This happens all too often in PDKs - insufficient thought is made about how you parameterize things.
A workaround would be to edit the CDF of the transistors (in the CIW Tools->CDF->Edit CDF, pick the component, and then look down for the fields for ad/as/pd/ps etc, and hit the "Edit" button in the parameters section. You can then make these parameters editable. If you don't have write access to the PDK, you can always make the change in the "Effective" CDF (rather than "Base").
Having made the fields editable, you can replace the fixed numbers on the instances with edit properties, using pPar() with expressions (either based on the pPar() or using iPar() to reference the w and l).
In reply to Andrew Beckett:
I modified the "Base" CDF (because I had write access) of the transitors as you suggested and that worked fine for the issue.
However, it's not clear to me where these modifications are saved. I read CDF documentation and now I know there are 3 CDF types: Base, User and Effective. If I edit Effective CDF, those changes are lost when I close the cadence session, User and Base (having write access) CDF are effectively saved though.The place where they are saved (or how to save and recall them) is what I am missing. Previous issue is important to me because I am planning to move from dkit AMS 3.70 (with IC51.41) to 4.00 (with IC6.10), and I want to keep my previous work (assuming that AMS 4.00 still has the callbacks problem related to your sourcelink solution).
Can I really keep my previous CDF modifications when moving to next dkit version? I think that now I have to move the previous Base CDF modifications to User CDFs (and discover how to save and reuse them) in order to be able to applying them to the new version dkit User CDFs, is that correct?
What else do I need to take into account to do this Cadence and Dkit moving?
How do I convert my CDBs to the new OpenAccess platfform?
Thanks in advance !!
In reply to joliveros:
Base CDF is saved in the cell's prop.xx (or data.dm in OpenAccess-based releases) or library's prop.xx (or data.dm) if it is library CDF rather than cell CDF. This is the "property bag" used for cell and library meta data.
User CDF is not saved to disk. Effective CDF is just the Base CDF masked by User CDF; any changes you make to the Effective CDF are actually stored in the User CDF.
You could dump the CDF using the SKILL cdfDump() function. You should be careful though within dumping it and loading it to the new PDK, because you may lose additional parameters which have been added in the new PDK. So you may be better off doing a cdfDump() from both your modified PDK, and the new PDK, and comparing them (with diff?) to see what changed.
Migrating a design to OpenAccess is relatively straightforward; there's a utility in the Tools->Conversion Toolbox in IC613 to do this (or you can use cdb2oa at the command line). You should read the Virtuoso Design Environment Adoption Guide in cdnshelp in IC613, which can also be found at <IC613instDir>/doc/dfoaAdopt/dfoaAdopt/pdf . If you're going to do this, you'll be best if the PDK you're going to use is developed/supported on IC613, because migrating a PDK yourself is not something we would normally recommend (although in many cases it works fine).