What I want to do, its a Layout versus Layout comparaison or a Mask versus Mask (MVM) - its the same thing -
when 2 layouts are loaded in the same panel.
Basically is an XOR between 2 layouts loaded in the same panel layer by layer
and to have the result in a 3rd layer set as I had loaded a 3rd layout in the same panel
like that I will can browse the differences w/ your cmd in menu bar > Tools > Browse Shapes
You have something of available doing that and if not its difficult to implement ?
PS. May be other people are interesting in doing the same thing but with an other operation: OR , NOT or AND
It's actually already there but not released yet :-)
For Linux users, a snapshot of the current development version can be found here: http://klayout.de/build.html#snapshot.
The XOR functionality can be found in the "Tools" menu in the "Verification" submenu (probably I'll move it somewhere else). The function requires that both layouts are loaded into the same panel and compares layer by layer. Currently, all layers are compared and a marker database is created from the results.
Supported operations are XOR, ANOTB and BNOTA. In addition, the function features a tolerance setting which is basically a undersize following the boolean operation. Multiple tolerances can be given to create a binning of differences with varying sizes.
Performance-wise the function cannot compete with hierarchical engines since it currently uses a flat approach. However, it features a tiling option which allows to use the function also for huge layouts with moderate memory requirements. In tiling mode, the boolean operation is performed on a small tile which is moved over the whole layout. Thus, only a small portion of the layout is processed in each step. For already flat or semi-flat data such as standard cell layouts this should be an acceptable alternative to a hierarchical processor.
I compiled your 'snapshot' r250 w/o any problem on CentOS 4.7 w/ Qt-4.5.1 and ruby-1.8
I tried on a little example and its what I were expecting even better w/ your Marker browser database.
Next week, I will try w/ a real chip.
But something to add, its the possibility to choose a subset of layers (by example: layers visible of set @1 or set @2).
The location in Tools seems fine and I will move may be menu 'Marker Browser' in Verification, what do you think ?
I tried w/ real chips and here my remarks/wishes :-)
- its working well.
A little bit slow :-) w/ 'huge' db (GDS size 1.3G, TIME: 1h40 w/ tiling
and w/o 2h. The RAM influence a lot the results)
- I had 2x a crash but its difficult to reproduce.
The 2 times, it was during the browsing of XOR marker database just after the end of the XOR operation.
user@sim% [BUG] Segmentation fault
ruby 1.8.1 (2003-12-25) [x86_64-linux-gnu]
 Done klayout
- it will be possible to save the result of the XOR to a GDS file ?
And for the output layers to put them on the same layers as the error ?
What I have seen in other tools, its that they are creating a TopCell
which call a cell by error. In your case you should insert an additional cell
corresponding to the category between the TopCell and the ErrorCell.
- an option to display the highlights w/ the same color/stipple as the original layer
- an option to display the name of layer if there is one in place of the layer/datatype
- an option to do not keep/show empty 'errors' db for a layer
I really appreciate the fact that you are supporting the users and introducing new features.
I added some features recently to the XOR tool, namely choice of the layer subset (currently visible or all) and some output options (in particular to create layout rather than a marker database). I just put a new snapshot on the server which may already provide some of the requested features.
If you uncheck the "Show All" checkbox from the categories' context menu in the marker browser, the "empty" checks should disappear. This is probably what's behind the last request.
I did not provide per-layer markers yet, so you can just color them in one way, but I'll have a look if that can be done.
Speed and stability-wise I admit there is room for improvement. If you still encounter problems a stack dump would be helpful to locate the problem. I have some ideas how to improve performance but I'll need to establish the algorithmic basis for this first.
The tiling approach is mainly intended to reduce the memory requirements. That's why it does not have a big impact on run times. However, it would offer a simple performance enhancement option by exploiting multi core architectures by parallelization.
I just noticed a difference in how the output XOR polygons are created,
when I output to the original layout the 1st coordinate is
However when I output to Other Layout the 1st coordinate is
so the data doesn't align with the original layout...
did you by chance check the "Coordinates in database units" checkbox on the properties page in the first case? Assuming the database unit is 0.001um that would explain the difference and also why the coordinates are shown with 2 trailing digits in the first case and 5 in the second.
I think the source of this problem is the GDS files that I'm reading in:
Database unit: 0.254 micron
Database unit in user units 0.01
Database unit in meter 2.54e-007
While the L1 layout is created with:
Database unit: 0.001 micron
I have changed to sending the output to new layers in layout A, so this is a resolved issue
Thanks for your support :)