Python<->Skill

edited May 2019 in Python scripting

Hi everybody,

I have had some success in transpiling if you will, skill into python bytecodes, after which I can instantiate PCells in klayout. I only have one PDK to test it with, not really sure how broadly it will work, and the process is rather manual, for now. I have published the code here:
https://github.com/jonpry/Pill

Looking forward to bug reports, and of course patches welcome. My Skill is not very good, but I suspect there is a way to automate this code dumping. On the other hand, I think the Skill binary context stuff is not really that complicated and it would eliminate the need for the Cadence executable.

~Jon

Comments

  • Hi Jon,

    That's really exciting :-) I have not even dared to imagine such a thing was possible!

    Let me know if you have suggestions for the Python API - I guess compatibility can be enhanced so the code migration is smoother.

    Best regards,

    Matthias

  • Mathias,

    Thanks for the encouragement. This would not be possible without the klayout python API! On the subject of API. Skill has these functions rodFillBBoxWithRects and rodCreatePath that are quite complex. I have implemented simple versions in python, but I am sure it is lacking in the details.

    rodFillBBoxWithRects() I mostly understand, but there is this distributed parameter that evenly spaces out the rects according to the grid, and I can't figure out if that means all spaces are equal or if they create a subgrid average spacing by intermixing different spacing. Depending on what is really being done, this could be fairly complex and potentially a useful feature.

    rodCreatePath() would be like DPath, except that it supports these "subrects", as a parameter, which of course, can be distributed along path segments in different ways depending on some parameters, and magic variables, and probably phase of the moon. What really confuses me is why it supports multiple subrects being specified, but that is probably overkill. This is really useful for drawing lines on metal/poly with arrays of vias being created to adjacent layers.

    ~Jon

  • Hi Jon,

    It's been some years since I did Skill the last time and I guess a lot happened in between (I used to have Cadence 4.x on CDB).

    But I guess your code will create some interest. I'm hoping for some community effect and maybe someone is able to provide an equivalent implementation of the rod* functions in Python.

    Thanks and lot for the code and best regards,

    Matthias

  • Mathias,
    Cadence path's have this notion of "justification". Klayout's DPath draw what they would consider center justification, where the width is evenly split on the left and right hand side of the path. They also have left and right justification where the entire width is located on the respective side of spine. Is this something you are interested in putting in KLayout itself?

    Thanks,
    Jon

  • Hi Jon,

    thanks for the explanation. Single-sided path would be a nice feature, but they cannot represented in GDS or OASIS. So that's a difficult decision.

    The wish list of geometric extensions is pretty long already (specifically smooth features), so maybe a new container format has to be born ...

    Kind regards,

    Matthias

  • I hacked something together to fix that particular issue. I've been able to synthesize the most complex cell to date. This one has about 20 sub pcells, all stitched together using various relative relationships from subcomponents. It is composed ~3k lines of skill code. Although this pales in comparison to the basic nfet design which is nearly 10x the code for some reason.

  • That's fascinating! Thanks a lot for sharing this!

    Best regards,

    Matthias

  • Update:
    I've added a new program that is able to parse cadence binary context files for those that are unable to pprint() or don't even have virtuoso. In theory this allows a 100% opensource flow from foundry PDK.

  • Update:
    We now have a parser for CDB files and ILE files. For the moment the CDB stuff only extracts the embedded skill code. Some geometry inevitably instantiates a cell that only has static geometry which doesn't work. This can be usually be worked around for the enterprising. I'm going to work on something to convert static cells into a skill generator function so we can get that loaded into klayout as well.

  • Thanks for sharing this :-)

    If I understand you correctly, the static cell-to-skill approach would allow translating OA cells into KLayout?

    That sounds promising!

    Best regards,

    Matthias

  • I don't have a reader for OA files yet. The newer OA based PDK's seem to put most of the skill code into these "context" files. Whereas the older CDB files pack the skill into the cell itself. For reading OA files I believe there is a tool in the OA distribution that can export to XML. I could make a tool to transform said XML into skill fairly easily.

  • Hi Jonpry,

    You work is interesting. I am interested to run skill code for 20 sub pcells that you mentioned in reply.

    Thanks
    Akshay
    akshaygore.36@gmail.com

  • I got this CDB->skill->klayout thing working on static cells. I also found that some old OSU PDK's are in CDB format. Now the repository has some submodules setup so it will automatically download the PDK and the example scripts will decompile and the run the cell. If only I could find a free pdk/design that actually has skill code in it :neutral: This is a screenshot of OSU018 DFFPOSX in klayout with no closed-source gunk.

  • This is all very impressive! Thanks a lot!

    Matthias

Sign In or Register to comment.