RTimothyEdwards / magic

Magic VLSI Layout Tool
Other
453 stars 101 forks source link

OpenAccess support #257

Open Blebowski opened 1 year ago

Blebowski commented 1 year ago

Hello @RTimothyEdwards,

I was wondering whether there is a chance that Magic will ever support Open Access format. I have only very brief knowledge of the politics behind the OA, so forgive me if I am asking inappropriate questions.

The reason we are interested in this, is that at my workplace we are evaluating whether it is feasible to design a simple analog block (e.g. 100 transistors) with open source tools and commercial PDK. We are a digital team that has analog design outsourced. We lack flexibility so we are looking for other options.

We have a PDK delivery from fab and that includes HSPICE models. Plus, the PDK includes Virtuoso schematics and layouts in OpenAccess formats. This is where we hit the problem, since it seems that no OS tools support OA.

We are able to work-around this issue for schematic entry in XSCHEM. In the past few days, I was able to create schematic symbols for few of the primitives from the PDK, design a simple AND gate, export the netlist from XSCHEM and simulate in NGSPICE.

However, we are completely stuck with layout. PDK documentation does not really demonstrate how should the cells be layed out. Even if we had this information, we don't now about the way of integrating XSCHEM + MAGIC, and achieve e.g. following flow:

It seems that if magic supported OpenAccess, we would be able to load layout of primitives to Magic.

We would appreciate any insights on how to move forward.

RTimothyEdwards commented 1 year ago

Nothing is inappropriate, although I agree that it's all political (or at least legal in the sense of having to do with lawyers and legal departments).

This has been the biggest and longest-running issue for me in the development of magic and other open source EDA tools. There is nothing "open" about Open Access in spite of the name. I took a stab at it once, but as I didn't have access to any Cadence tools or PDK at the time, I couldn't get it working and didn't have any incentive to continue. You will note that klayout has the same issue. Both klayout and magic have taken the same route, which is to implement parameterized devices in a different way. Klayout does this with python-based routines; magic does it with Tcl/Tk-based routines.

What you describe above is exactly how the open-source PDKs for SkyWater sky130 and Global Foundries gf180mcu are working. Magic has parameterized device generator routines for all the primitive devices, and a scripted routine to read in a netlist from SPICE and convert it to device instances in a layout (potentially hierarchical). You can then arrange the instances and wire them up, check DRC, export GDS and a layout-derived netlist, and run LVS.

You can see the whole flow in action if you go to the Efabless YouTube channel and look up the schematic capture tutorial with Stefan Schippers, and the layout tutorial with me (for magic) and Thomas Parry (for klayout). But it does require technology files for magic or klayout, and those can get quite complicated to write from scratch.

Beyond the open PDKs from SkyWater and Global Foundries (and a recent one from IHP that supports klayout, I think) I do have some PDKs for magic for some X-Fab processes which (by arrangement with X-Fab, and requiring an NDA check) I can give out, but beyond that there's not much support for open source EDA tools.

You can always try starting from the sky130 or gf180mcu tech files and adapting them to your target process, but that is a lot of work, and generally takes several iterations of cross-checking against commercial tools to get everything in mostly working condition.

Blebowski commented 1 year ago

Hi @RTimothyEdwards,

thanks for quick reply and explanation of the situation. I think for now this is may be a showstopper for us since it is a lot of work and we don't have so huge PDK building experience. Just re-creating all the layouts and scripts to generate parametrized layouts might be so much work, that it is more worthy to buy the Virtuoso license. Plus, without knowing the details and tiny tricks of the particular PDK, I think there is a risk that we will do a mistake and the circuit will be non-functioning after manufacturing.

Just out of curiosity, to implement OpenAccess support, one needs to become a member of some sort of alliance to get an access to the format, correct? Has there been some attempts to standardize this format by e.g. IEEE standard (and therefore open it) ? Has there been any attempts to reverse engineer the format (possibly with some legal consequences) ? I know that in Kicad development, someone reverse engineered Altium format to add support for loading Altium board layouts and it works quite nicely.

Thanks once again for reply.