Inserting DBox in shapes

sferre

Hello,

I manage to create boxes (Class Box) from a list of points i am defining. I am then inserting them as in the examples with
layout.cell( cell_id ).shapes( layer_id ).insert(my_box)
This is working fine with integer points. Nevertheless i would need to using floating points. I am then creating DBox defined by DPoint but i don't manage to insert them to the layout afterwards.
Anyone would know how to proceed with floating-points boxes ??

Thanks a lot

davidnhutch

You are right there is no insert(dbox) method for shapes class.

Here is how I do it.

# Puts a box with corners at (0,0) and (10.001,20) microns
include RBA
layout_view = Application.instance.main_window.current_view
layout = layout_view.active_cellview.layout
dbu = layout.dbu
out_cell = layout_view.active_cellview.cell
out_layer = layout.layer(1,0)
left  = 0.0  # microns
bott  = 0.0  # microns
right = 10.001 # microns
top   = 20.0 # microns
box = Box.new(left/dbu,bott/dbu,right/dbu,top/dbu) # Each one is divided by dbu
out_cell.shapes(out_layer).insert(box)

As you see, I'm using Box and scaling by the database unit (dbu = 0.001 by default; this factor converts the usual 1nm manufacturing grid to the usual 1um units).

Perhaps Matthias has another way, but that is my standard way.

On a higher-level note, personally I avoid the D... classes, for three reasons:

1. Sometimes a D... argument isn't supported for some methods, as you have found. However non-D... arguments are always supported. You can think of non-D... classes as the more 'basic' classes, I think.
2. You can always do any task with a non-D... class, i.e. I have never found a case where you need a D... class.
3. I have gotten myself confused several times when using methods like "Point.from_dpoint" etc (i.e. conversion back and forth can often confuse yourself. Or maybe I'm just stupid

In conclusion, personally I just always stick to the following method: Just use non-D... classes, and whenever you use them, always divide each one of its arguments by dbu. Then all the numbers in your script are always in microns, and all the methods are always the non-D type.

However I do see the conceptual benefit to the D... classes. And there is good reason for this behavior -- Box.new's argument is intentionally an integer because integers is how the point information is actually stored, and with ability to change dbu scaling factor if desired actually gives you a more flexible arrangement. But the above explanation is just how I handle it, and it has so far worked well.

Thanks,
David

Matthias

Hi David,

thanks for the explanation. That is correct.

Basically the "D" types are provided whenever you do computations in physical space ("micron space"). The layout database uses integer types for compactness and (more important) to avoid double precision rounding issues. You sometimes get "D" types from the database, for example if you transform an integer box with a magnifying transformation or one containing arbitrary rotations ("CplxTrans" will convert an integer object to a "D" object). In that case, you'll get "D" objects in fractional database units. But that is a rare case.

The conversion factor between micron-unit "D" and database-unit "non-D" types is the database unit which you can obtain from the layout object.

Here is the conversion code:

ibox = RBA::Box::new(1000, 2000, 3000, 4000)
dbu = layout.dbu

dbox = RBA::DBox::from_ibox(ibox * dbu)
ibox = RBA::Box::from_dbox(dbox * (1.0 / dbu))   # note: there is no "/" operator, only "*" is available

Matthias

sferre

Thanks a lot to both of you, you'll try to play around with that :)

Have a good day