Seperate packaging for technologies

[robtaylor]

We've discussed having separate packages for installing technologies, this is a placeholder for this work and discussion around it.

[jpc-lip6]

We could use as a starting point what has been done in cumulus/src/designflow/technos.py (installed as coriolis.desigflow).

It is important to distinguish between the configuration files for Coriolis and the files from the PDK itself (gds, LEF, .lib and whatever). So we always need to supply to the Coriolis config where the PDK is installed. Unless a standard location is agreed upon (open_pdk maybe ?). I don't see that going into a pip package, it is too far from a Python module.

The question of NDA must also be addressed, the strategy must also allow restricted distribution.

So we have three components that must work together :

1. Coriolis itself (pip capable).
2. The technology configuration (pip capable or direct wheel in case of NDA).
3. The PDK itself. Usually third party and not standardized.

[robtaylor]

I think we could include open PDKs within the pip install no problem. For closed PDKs, probably the best solution would be the user supplying a path At configuration.

…

On Sun, 29 Oct 2023 at 10:42, Jean-Paul Chaput ***@***.***> wrote: We could use as a starting point what has been done in cumulus/src/designflow/technos.py (installed as coriolis.desigflow). It is important to distinguish between the configuration files for Coriolis and the files from the PDK itself (gds, LEF, .lib and whatever). So we always need to supply to the Coriolis config *where* the PDK is installed. Unless a standard location is agreed upon (open_pdk maybe ?). The question of NDA must also be addressed, the strategy must also allow *restricted* distribution. So we have three components that must work together : 1. Coriolis itself (pip capable). 2. The technology configuration (pip capable or direct wheel in case of NDA). 3. The PDK itself. Usually third party and not standardized. — Reply to this email directly, view it on GitHub <#74 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB4O4FNDU2R34F247YGDW3YBYQINAVCNFSM6AAAAAA6JCFOTSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBUGA3DENBRHE> . You are receiving this because you were assigned.Message ID: ***@***.***>

[mmlouerat]

I fully agree that for closed PDK, the user can supply a path.
Is one path enough? I mean that the organization of the closed PDK may be not compliant with the flow's "great expectations".

[jpc-lip6]

In the case the PDK is included in the wheel datas, this also put us in charge of maintaining it's synchronicity with the original one. A user may also want to use the PDK for other tools than Coriolis, it shouldn't have to install it a second time for those other tools that may rely on other installation strategies...

[stafverhaegen-chipflow]

For the PDKMaster based PDKs I would like that it can be done from the PDKMaster based c4m-pdk-XXX python repo as installed from pip. Due to legacy reason PDKMaster.io.coriolis now spits out python files that are then loaded from a path into Coriolis. This was done as I was using python 3 but Coriolis was still python 2.
I would like to transform that so you can initialize the in memory techno from a function in PDKMaster.io.coriolis directly and also do similar for a library f.ex. the standard cell library and not go through python files.