Bug in Clip Tool

[594chendata]

When instance with rotation(not Zero angle),then clip result may be not correct.
Top cell will be clipped:

Clipped result:

The red box is not correctly clipped by the purple clipping box.
I think the main problem occurs in the function collect_clip_variants:
the following code:

db::Box inst_clip_box = db::Box (cell_box.transformed (inst->cell_inst ().complex_trans (*a).inverted ()));
collect_clip_variants (layout, target_layout, inst->cell_index (), inst_clip_box, variants, false);

the first line want to make clip box of an instance, so make the clip box transformed by the instance inverted matrix.
But, when the instance transformed by an angle, the clip box transformed with the inverted matrix will not be a Box.
So the corner m_p1,m_p2 will be right, but now not a box. This will make the error clip results.
By the way, there may be something wrong in the code of complex_trans::to_matrix3d() :
return Matrix3d (m_cos * fabs (m_mag), -m_sin * m_mag, m_sin * fabs (m_mag), m_cos * m_mag, m_u.x (), m_u.y (), 0.0, 0.0);
maybe it should be:
return Matrix3d(m_cos * fabs(m_mag), -m_sin * m_mag, m_u.x(), m_sin * fabs(m_mag), m_cos * m_mag, m_u.y(), 0.0, 0.0);

That's all.
KLayout is a very cool tool.
Thanks a lot.

[klayoutmatthias]

Hi @594chendata,

Thanks :)

First point: I don't think the matrix conversion is wrong.

You refer to the version with 9 arguments (m11 ... m33) which actually would look like your proposal (if you add a "1.0" as the ninth argument). But the current solution uses the 8-argument constructor which has the signature

matrix_3d (double m11, double m12, double m21, double m22, double d1, double d2, double p1, double p2)

so that is the 2x2 rotation/shear/scale matrix, a displacement and perspective distortion. It maps to this setter for the m11 to m33 matrix elements:

set (m11, m12, d1, m21, m22, d2, p1, p2, 1.0);

Regarding the clip problem, you're right. Any-angle instances are not clipped at all currently. The clip function will take care they are not dropped, but does not make an attempt to generate clip variants. Frankly, no one asked for that case so far - at least I don't remember - and any-angle rotations and magnified instances are deprecated in many VLSI applications for a number of reasons.

I think it's possible to support though, but it's not a simple patch.

Matthias

[594chendata]

Oh, yes, the declaration of the matrix conversion is clear. matrix_3d (double m11, double m12, double m21, double m22, double d1, double d2, double p1, double p2) void set (double m11, double m12, double m13, double m21, double m22, double m23, double m31, double m32, double m33) I make a mistake. Ha. The clipping of rotation is really a big work. Perhaps it may affect basic algorithms such as begin_touching(). Thanks for your reply. 594chendata

[klayoutmatthias]

The basic problem of clipping of rotated cells is that in that case, the operation is not recursive in hierarchy: inside a rotated cell, the clipping basically has to happen on a rotated rectangle - so that is no longer the same than the original clipping and much more difficult.

The solution was to unrotate such cells until clipping can happen on a rectangle again. This is what makes the clipping solution more difficult when it comes to considering rotated cells. I'll see what I can do.

Matthias

[594chendata]

It's indeed a bit difficult.