GDS Cutting

edited August 2011 in General
Hi! I have encountered this problem while cutting/clipping a GDS. I have a large GDS which I have to cut into many smaller ones (~10). I use a ruby script to do so. I use the proc boxes.push to get the box/clipped GDS. This has inputs x1 y1 x2 y2. The problem here is that y2 does not accept values larger than 20000. Help in this regard is greatly appreciated.

Comments

  • edited November -1

    Hi Sambhav,

    I guess that you are using a pretty small database unit of 0.01nm. There is a basic constraint within GDS (and KLayout) that all coordinates must be 32bit integer multiples of the database unit. With this database unit, the 32bit signed integer limit of 2^31 ~ 2000000000 corresponds to 20000 micron.

    If that is the case, you could switch to a large DBU (0.1 is sufficient an almost every case).

    Best regards,

    Matthias

  • edited November -1
    Hi Matthias,

    I'm facing almost similar issue in one of the scripts which you helped me to code sometime back.

    From the Layout Properties, I checked that the database units is 0.001 micron i.e. 1nm
    Now in the script I created an array of boxes:
    boxes.push( RBA::Box.new( x1, y1, x2, y2 ) ) #x1 = 0, y1 = 0, x2 = 10000, y2 = 21000000 (in nm)

    Then I did clipping with the following code:
    cells = lay.multi_clip_into(top, cl, boxes)

    When running the script I'm getting the following error:

    *** ERROR: /home/acku/tools/klayout-0.21.12/src/dbClip.cc,314,vmp != variants.end ()
    *** ERROR: Ruby error: 'Internal error: /home/acku/tools/klayout-0.21.12/src/dbClip.cc:314 vmp != variants.end () was not true' (RuntimeError)
    ./gds_clip.rb:64:in `multi_clip_into'
    ./gds_clip.rb:64

    Surprisingly when I flattened the gds and ran the script, it worked fine !

    I'm using klayout 0.21.12 but the problem came with 0.21.1 as well.

    Please do help me to figure out the issue or it would be really helpful if some workaround is possible here.
  • edited November -1

    Hi,

    I tried to figure out from the code what is happening.

    Basically, the clip function first gathers all clip variants (cells for which only parts are required) and creates the new cells. Then it starts the clip operation and uses the cells where required. The assertion basically says that it is not able to find the required cell in the collection it created before, which explains why the problem only occurs for hierarchical layout. From the algorithm I don't understand how that can be possible. Your problem is probably not connected to the database limitations of the data representation.

    One possible mechanism are rounding errors. Does your layout contain magnified instances (magnification != 1)? Can you explain roughly how your hierarchy looks like?

    I'll try to narrow down the problem myself. Until I have a solution, my suggestion is to use the flattening if possible.

    Best regards,

    Matthias

  • edited November -1
    Hi Matthias,

    Thanks for spending time on the issue.

    Actually the hierarchy is pretty simple; one top cell with loads of cells at first level. It is at most 3-4 levels deep. The instances have no magnification / no rotation or mirrored. The count of instances is also not high (infact 1 in most cases).

    One more thing, I'm able to clip successfully using the clip tool in the GUI editor mode with the same values.

    I'll work with flattening for now.

    Thanks again.

    Regards,
    Acku
  • edited November -1

    Hi Acku,

    thanks for the hint about the clip tool. I was not successful in reproducing the problem with the clip tool but using the script I finally found a testcase that I could reproduce the problem on.

    Basically it seems to be related to empty cells (cells not containing any content). A quick workaround therefore is to save the layout dropping empty cells: check "Write non-empty cells only" on the writer options page, write the layout and read it again. In my test case, the problem did no longer occur then.

    I'll try to provide a fix in the code nevertheless.

    Best regards,

    Matthias

  • edited August 2011

    Hi Acku,

    here's a patch to fix the bug: file dbClip.cc needs a new if() around lines 313..319:

        ...
        const db::Cell &inst_cell = layout.cell (inst->cell_index ());
    
        // BUGFIX : don't create variants for empty cells
        if (! inst_cell.bbox ().empty ()) {  
    
          std::map <std::pair <db::cell_index_type, db::Box>, db::cell_index_type>::const_iterator vmp = variants.find (std::make_pair (inst->cell_index (), inst_cell.bbox ()));
          tl_assert (vmp != variants.end ());
    
          new_inst.object () = db::CellInst (vmp->second);
    
          //  TODO: keep properties 
          target_cell.insert (new_inst);
    
        }
        ...
    

    Best regards,

    Matthias

  • edited November -1
    Hi Matthias,

    I tried the fix you gave above and it worked absolutely fine!

    I manually inspected the cells which were triggering the error earlier. They indeed have empty cells in them which were causing the problem.

    Thanks a lot for the prompt reply and support.

    Regards,
    Acku
Sign In or Register to comment.