Are there any resources for storing multiple layouts with shared cell definitions in a database?

Hey folks,

I deal with a lot of layout files that share cell definitions. I want to decompose layouts and store them in tables inside a database.

Database schema would look something like this:

Tables:

  • cell definition: cell ID, cell name, hierarchy level
  • layer definition: layer ID, layer source
  • cell bbox per layer: cell ID, layer ID, bbox
  • cell instances: cell ID, parent cell ID, x, y
  • cell shapes: cell ID, layer ID, pya.Shape object

Stored procedures:

  • Load layout: given a layout file, decompose and load to database; check for existing cell definitions in the database using XOR
  • Cell layout: given a cell name, reconstruct layout and return layout file or pya.Layout object in Python

I would like to leverage Klayout as much as possible in this project. Has anyone done something similar before? Also, there's some documentation / discussions which suggests that layout objects essentially ARE databases. Is there an easy way to use pya.Layout objects with a database management system like postgres?

Thanks,
Scott

Comments

  • Hi Scott,

    If you want to persist single cells in a database, maybe a blob with the cell in a standard format like GDSII is a better choice than decomposing the cell into objects and mapping them to a database table.
    For simplicity you could even choose to use a file system instead of a database. If you need a central facility with access control and support for concurrent access, a managed repository such as Subversion or git may also be an option.

    Layout objects are databases in the most general sense (providing managed access for hierarchical polygon data), but there is not equivalence with other databases.

    BTW: the scheme you ask for feels like being an enhancement of the library model KLayout offers. From you description I think that the built-in library model only lacks the "managed update" you want to have - like running an XOR before updating. But I don't know your use case, so it's difficult for me to judge.

    Matthias

Sign In or Register to comment.