Hello! DeviceLayout.jl is a new package for computer-aided design of superconducting quantum integrated circuits, developed at the AWS Center for Quantum Computing. The package supports the generation of 2D layouts and 3D models of complex devices using a low-level geometry interface together with a high-level schematic-driven workflow. It’s a successor to PainterQubits/Devices.jl that began as a fork when its primary author joined the AWS CQC. You can learn more by checking out the docs, including some detailed examples like layout of a quantum processor with 17 qubits. You can also listen to this lightning talk about it from last year’s JuliaCon.
We at the AWS CQC have been using this package to design devices for experiments like Hardware-efficient error correction using concatenated bosonic qubits (our “Ocelot” device). We’re highlighting the quantum use case because that’s where can most readily show examples and do support/outreach. But DeviceLayout.jl provides generic 2D/2.5D device CAD capabilities, and we’d be excited to see adoption in other domains. We look forward to seeing what others make with it, and we invite feedback and contributions from the community!
14 Likes
Thanks @gpeairs and AWS CQC for releasing this! I’m quite excited for my group to try writing GDS files in Julia and have a nice interface to design, mesh, and run simulations in Palace. More broadly, I’m glad the field of quantum computing is developing open source CAD as well as using commercial tools.
A few questions:
- Does DeviceLayout.jl support or plan to support design rule checking (DRC)?
- How does DeviceLayout.jl handle process bias? For example, is there a better solution than changing all of the relevant parameters between simulation and fab?
- How robust is the package to snap to grid errors and should the user take precautions like avoiding non-Manhatten connections or adding overlaps (ex. Grid snapping — gdsfactory)?
Thanks!
Thanks for the interest! I should add FAQ entries or create issues for these. If your group gives it a try, please don’t hesitate to ask questions or report issues for anything that comes up.
- We support rules at the schematic level—users must run
check! on a schematic before rendering, supplying rules that are just Boolean functions of the schematic. The only built-in rule is checking global orientation for component types that opt in (e.g. for checking that junctions have orientations compatible with your fab process). You could also write rules based on schematic connections and metadata, for example, to check that any readout line starts/ends at readout input/output ports. For global geometry-level rules, other tools like KLayout are more efficient for now.
- You could define a component’s geometry so that one thing gets rendered for a simulation target and another for an artwork target. (For example, you could give a component a parameter named
bias, and then this would look something like place!.(cs, not_simulated.(polygons), layer); place!.(cs, only_simulated.(offset(union2d(polygons), bias)), layer).) But this has its own pitfalls (like maintaining consistent duplicated geometries, or preserving connections to other components), and I’m not sure it’s always better than changing parameters. Otherwise, you could manually replace a layer with the offset of its union, but that can be expensive to do across a whole chip. (Those operations also require everything be converted to polygons first, so would be best for a compensating bias for the fabricated GDS.) A convenient global solution that takes the bias from process information would be a nice feature if it can be made efficient and robust.
- For now, users should take precautions. Avoiding non-Manhattan connections will generally be safe (and you could use schematic DRC to enforce it); otherwise, using
flatten before saving to GDS will prevent many errors. Neither overlaps nor flatten will necessarily fix issues related to collinearity after snapping to grid (see the last FAQ here).
1 Like
Thanks! This is very helpful.