Hi Cliff,
so PDK generation is a service from Analog Rails. That put again the question of liability on the table.
In 1993 I had to setup a flow for composer, virtuoso and diva. The process foundry supported edge and dracula. So both are from the early cadence. But analysing both tool collections, both from cadence, I end up starting everythink from scratch. There was the famous drac2diva but you have to manually rewrite everything because only 90% was automatic translated, and that in a terriable way.
The problem with a tool-locked PDKs is that some tool-functionality is used which is not supplied by other tools. A very good example is the ivpcell verification. Here a parametric cell is verified not based on geometric layer properties but on the numeric layout generator properties themselve. Some PDK's support both because of calibre,diva and assura. But in this case they limit to what could be checked on both methods.
I did not checked the IPL guide but if the foundry restrict themselve to the physical support there is an open way for any improvement which is based on special tool features and not on specfic foundry support.
For instance modelling and verification of layout compositions based on the principal physical devices avaible should be outside the foundry. How I use multifinger-MOS and model the parasitic inductance, the distributed body substrate, the overrouting parasitic cap to gate finger coupling and so on, is design specific.
Do plan Analog Rails to join IPL? (In addition to the service model)
http://blog.shrinkingviolence.com/2010/02/IPL-design-kit-release.html#more