Generate missing shapes with ruby

rolbit

Hello
Just started to use klayout and am very impressed. I am used to Silvaco expert and clewin. There is one thing I am missing: circles. Can this be added by using a ruby script? If so, could you provide a little example?
Another nice little feature I miss that is implemented in Expert is the capability to draw in hole mode, i.e. what ever I draw is directly substracted from the shapes I am drawing on. I know this can be done by boolean operations, it is just much quicker.

Regards
Roland

Matthias

Hi Roland,

thank you for the nice suggestion about "hole" mode. It's probably a very useful feature.

Regarding the circles: right now, it's already possible to use "round end" paths as circles if you draw a path with identical start and end point. On GDS, these paths remain circles even when saving them to GDS (although GDS does not have the concept of a circle object). I just noticed that when you save such a path to OASIS, it's converted into a polygon which is not the expected behavior since OASIS has a circle object. I'll have a look into that ...

Another option to create circles is to draw squares and use the "Round corner" function on them with a radius of half the side length.

I know that circles are objects which are definitly missing. But the basic problem with any of those "exotic" objects is that I somehow need to represent them in GDS. Otherwise they are converted to polygons on save ...

Best regards,

Matthias

rolbit

Hi Matthias

thanks for the tips on how to create circles. I didn't really think along those lines.

I guess if you want to stick to the standard formats like gds and oasis you will always be limited to polygons. But I think everybody doing photomasks is used to work with some sort of proprietary file format that can be converted to gds. So why not introduce some sort of extension to those formats that work only with klayout? Something that would allow to include scripted objects for example.

Regards
Roland

rolbit

Just got an additional comment: why not use one big ruby file to represent the mask internally? I dont know ruby, so might be a stupid idea but again expert does something similar with their script language. Their mask file format is basically a zipped script file of all the commands executed by the user interface.

Matthias

Hi all,

the comment about using a custom format is valid. On the other hand, the limitations of GDS basically match the requirements of the mask makers. For example, having a circle may be useful for the layouter, but when it's printed to the mask, it is always converted to a polygon or fractured into a set of trapezoids.

The same is true whenever you process a layout with a typical DRC or layout processing tool because all the algorithms are based on polygons. That basically makes circles "evil" objects and when mask/layout fidelity is important, they should be avoided.

My personal viewpoint is that one needs a twofold representation: a "editable" representation (i.e. circle, given by radius and center point) and a mask representation (polygon). Such a twofold representation can be achieved for example with a PCELL concept where a layout entity can be defined using intuitive parameters while the geometry is produced internally in the render process by the PCELL code and represents the mask. That concept is quite generic and should provide a solution for the general "exotic" object problem.

I am also quite confident that it's possible to enrich GDS with the necessary meta information that allows to store the PCELL parameters inside a GDS file. That basically matches the idea of Roland.

Of course it should be possible to introduce a custom format that supports more objects but frankly I am not prepared to handle a large object diversity. The main focus still is provide a fast layout viewer and that imposes some restrictions on the internal database.

Best regards,

Matthias

rolbit

For me having the possibility to save PCELLs to a project is already all it needs. I am doing some MEMS and micro optics stuff, so having parametric designs is actually quite important (think of comb drives or funny lens arrays).