Good question: when you placed a cell offgrid, how do I move it on-grid?

[klayoutmatthias]

Scenario: I placed a cell on a 5nm grid for example. Then I switch to 10nm. When I move the cell it will move in increments of 10nm, but not snap to 10nm. So when it was offgrid, it will stay so.

Suggestion is to change the behavior from "move by x grid" to "snap to grid".

Comments?

[sebastian-goeldi]

I have a kinda related question. Is it possible to position cells intentionally off-grid? ;) Asking for a friend and definitely not wanting to abuse it xD

But regarding the question, yes I think the suggestion is good. I assume you meant "move by x (grid) and snap to closest", if yes, I think that's a good solution, maybe have it spit out a warning that it did so (and a flag to disable that warning?).

[klayoutmatthias]

@sebastian-goeldi Usually one would choose a smaller grid and then place the cell, but there is also the option to turn off grid snapping at all ("No grid"):

BTW: the "Snap to grid while moving" option now will be added in the next minor release. If it is checked (the default), moving objects will make the vertexes snap to grid. If off, the object will move in multiples of the grid.

[sebastian-goeldi]

@klayoutmatthias I see, thank you. In that case, is it possible to do that via API?

It would be very useful for the all-angle router in kfactory/gdsfactory. But I am still confused whether this would produce legitimate gds/oas files. If a transformation/move doesn't have to be on-grid, with regard to what is the Instance origin (as in where is (0,0) of the cell grid w.r.t. its parent) defined then?

Sorry didn't have time (and motivation) yet to dig into the gds file docs

[klayoutmatthias]

Hi Sebastian,

This is in general a somewhat difficult question. Basically the database allows placing cells on the database unit. This means with a DBU of 1nm and not taking into account scaling (which is somewhat deprecated today), you can create only features being on a 1nm grid. So there is some intrinsic grid built in.

But usually there is a larger grid imposed by the design manual and that may depend on the layer even. Fine-pitch layers may have a smaller grid or they are happy with the database unit-implied grid. But other layers may demand 10nm grid for example. The reason is often that during post-processing some manufacturing grid is introduced, for example for pixel-based mask writers. Larger grid means higher writing speed, hence lower cost. You like to have your design on that grid, because if snapping gets involved, the critical dimensions can no longer be guaranteed and what may even be worse, symmetry and matching may be broken. So it's a good idea to observe the required grid.

However, that applies to flat data. As seen from top cell, all vertexes should be on grid. But that does not imply the instances to be on-grid necessarily. You can have off-grid instances and if the content of the cells is off-grid in a way that in the end, everything is on grid, you're safe. But if you do so, you have to be very careful when rotating cells or moving them.

So in short, the answer is that cells can be placed off grid as long as the as-if-flat geometry is on grid.

Matthias