Customize PDK library without changing it.

Hi,

I think one way that you might be able to do this without changing the PDK library would be to change the CDF in virtual memory, in other words create/edit the "User" level cell CDF so that the "Effective" CDF now contains your desired defaults. You might need to load such code after the library had been accessed, in case a libInit.il file makes changes that stomp on your changes. If there is no libInit.il file then you might put your code in a libInit.il file inside the library structure so that it is automatically read when the library is accessed. The idea behind this approach is that the "effective" CDF is what exists in Virtual Memory and it is the summation of the Base CDF and any User CDF, the latter potentially overriding values coming from the Base settings.

There might be another option which would mess with the Create Instance form, but I think this would involve changing the CDF anyway, so just changing the parameter directly may be the way to go with this.  Also, I am not sure that just changing "A" to 2 would force any of the CDF callbacks to run, so you could end up with a mess where the device is not self-consistent.  There is a great solution written by Andrew for forcing the callbacks to run procedurally, look for it in COS.

Are you familiar with programming what I have described above?

Regards,

Lawrence.

Thanks Lawernce.

I've already tried changing the effective CDF of A = 2 as a test.  But when I instantiate the instance A is = 2, x, y, z don't get updated.

I was thinking if there's a way to update the effective CDF *AND* triggering the callback of "A" automatically, this might work.

This this what you're describing?

But I'm not sure how to

1. load the code only after libInit.il is load (appending code to the end of libInit.il would mean changing the PDK) and

2. how to change the effective CDF and trigger the callback automatically without user's interaction...

 Hi,

Yes, that is the situation I was describing.  A problem with this is that the "force-the-callbacks-to-run" code works on the instantiated devices, not the unplaced "form" device since it does not have an instance id nor instance CDF yet.  So you would somehow need to change the User CDF for all of the dependent parameters in exactly the same way that the PDK does so that the device parameters are all consistent with each other. This might work but you would need to be sure (by inspection I guess) that one of your changed-default devices matches a device where A was changed interactively from 1 to 2.

How about placing the devices with A=1 and changing them all to A=2 later (needs some designer interaction to trigger this I would think)? This is where the callback code would come into play.  This fails your criteria on no user interaction.

For automatically running this code I cannot think of a good triggering event - you would want something like a run-this-after-any-libInit.il  trigger (assuming you were going to use the method that creates the User CDF).  Perhaps you could have a userPostInstall trigger on the view in question?  Not ideal but it might work?

Hmm, I'm running out of ideas and it is starting to sound messy.

Regards,

Lawrence.

 There are numerous problems with changing the defaults in the effective CDF. For a start, if the user does a File->Refresh in the CIW, and hits OK when it asks them whether they want the CDF refreshed, the effective CDF will be discarded.

Getting all the callbacks to run on the create instance form doesn't really make sense, and isn't really doable. You could potentially do something in a formInitProc (which you could set in the effective CDF too), but formInitProcs that change values are nasty, because they will then modify the values on existing instances when you do an edit properties, which gives you misleading information when you simply do edit properties to look at the current properties. Similarly if you changed the doneProc - that's also nasty.

The cleanest solution would probably be to not only change A=2 in the effective CDF, but also change the defaults for x, y  and z to the values the callbacks would have set them to. That way it is all consistent out of the box. After all, that's the case with the original defaults - at least if well design.

Overall, I'd be very wary of doing this. Especially if there are pcells involved - if the pcell's defaults then become different from the CDF's defaults, then odd things can happen (workaroundable by setting storeDefault=yes; what happens is that edit props things that if the form shows the CDF's default, it doesn't store the property on the instance; during pcell evaluation, if there's no property on the instance, it uses the pcell's default - so you think you've asked for one value, but it's actually evaluated using a different value).

Regards,

Andrew.

thanks all for your ideas and suggestions.  there doesn't seem to be a clean yet safe solution...

I might have to rely on the users to set A=2....and do some checks

a) after they create an instance.

b) after they save the design.

Is there any trigger at a) and b) where I can run a SKILL code to loop through the instatnces and do some checkings? 

Where can I find all those "point of trigger" where I can insert code anyways?  (use deRegUserTriggers ?)

 thanks