Modifying xsection.rbm?

kqtran

Hi Matthias:

Thanks for the excellent software tool you made.

I recently came across the xsection script which I'm starting to use.

Since I'm ignorant of Ruby programming, could I ask if there is an easy modification to the script to enable the selection of the process description deck from a pull-down menu?

For example, if I have 3 different process description decks for 3 different processes, I would like to be able to select the right one when I hit the x-section button. In the current demo provided, the cmos.xs process description is hard-coded into the xsection.rbm script.

Many thanks in advance for your guidance and help.

-Ken

Matthias

Hi Ken,

That is actually possible. Here is a simple solution:

Change the constructor of the XSectionGenerator object (around line 490 of the script), so you can supply a file path

# The main class that creates a cross-section file
class XSectionGenerator

  # Constructor
  def initialize(fp = "xsection.xs")
    @file_path = fp
    @ep = RBA::EdgeProcessor.new
  end

  def layer(layer_spec)

...

you can then add more items to the toolbar at the end of the script:

menu = mw.menu
if !menu.is_valid("@toolbar.xsection")
  menu.insert_separator("@toolbar.end", "tb_separator")
  menu.insert_item("@toolbar.end", "xs1", $xsection_action_1 = MenuAction.new("XS1", "") { XSectionGenerator.new("file1.xs").run })
  menu.insert_item("@toolbar.end", "xs2", $xsection_action_2 = MenuAction.new("XS2", "") { XSectionGenerator.new("file2.xs").run })
  menu.insert_item("@toolbar.end", "xs3", $xsection_action_3 = MenuAction.new("XS3", "") { XSectionGenerator.new("file3.xs").run })
end

creating a drop-down menu in the toolbar should be possible but I have to figure out how to do so myself :-)

Regards,

Matthias

kqtran

Hi Matthias:

Thank you!!! Your changes work like a charm.

I have a couple of additional things that are badly in need of help:

a) When one opens 2 layout files in the same panel, the gds layers in the Layer Window are appended by @1 and @2, corresponding to layout1 and layout2, respectively. I'm trying to take advantage of this to construct a composite x-section of a 2 die stack. Would it be possible to modify xsection.rbm to read in all layers as denoted by the extra @suffix?

b) When defining an output layer, would it be possible to associate a layer name so it shows up on the Layer Window as well?

Many thanks in advance again.

-Ken

kqtran

Hi Matthias:

Regarding both issues above, i think I figured it out.

For a), I added the following lines to the string_to_layerinfo function to parse the @1 and @2.

elsif (layer_spec =~ /^(\d+)\/(\d+)(@)(\d+)$/)
ls = RBA::LayerInfo.new($1.to_i, $2.to_i, $4)

If there is a better way, it would be interested to know.

For b), it looks like the ability is already built into your xsection.rbm script. In my .xs file, I just needed to change the output to say, for example:

output("piso (103/0)", piso)

Many thanks for the great program!

-Ken

Matthias

Hi Ken,

sorry of the late answer.

For b.): you're right. This will set the dabase layer name accordingly and then it's shown in the layer list.

For a.): I don't think there is a straightforware solution currently. If I understand you correctly, you try to stack two layouts. That is possible but you need to address different layout objects, depending on the "@1" or "@2" flag. I have to look into the code whether there is an easy way to do that or the code has to be refactored.

Best regards,

Matthias

kqtran

Hi Matthias,

Yes I would like to stack 2 layout and perform a x-section. Presently, the problem I run into is that even though the viewing window displays all layers from both layouts, depending on which layout I select from the "cell" window, the x-section code will just see 1 layout or the other, but not both.

I would appreciate your insight into this as well as a potentially solution.

Thanks,
-Ken

Matthias

Hi Ken,

I did not have time yet to look deeper into the xsection script. But it probably it requires some rewriting.

Did you consider to merge both layouts before applying the xsection? For example by using the "File/Import Layout" function?

Regards,

Matthias

kqtran

Hi Matthias:

Thank you for the suggestion.

I used the built-in capability to translate the layers of the 2nd die in case some are the same as the 1st die but other than that, merging works nicely.

Regards,
-Ken

kqtran

Hi Matthias:

I noticed a problem with V0.22.

The sequence is like this:
a) Using the code in your 1st reply, I install 2 separate x-section scripts on the menu
b) I open 2 different layouts in 2 panels (1 intended to be used with the 1st script, the other with the 2nd script)
c) I draw a ruler to cut through layout 1 in panel 1, and hit the script1 button. The correct x-section as prescribed by script 1 is generated in a new panel
d) I draw a ruler to cut through layout 2 in panel 2, and hit the script2 button. Instead of getting a x-section (as prescribed by script 2) in a new panel, nothing happens.

The above problem does not happen in V0.19.21, but I would much prefer to use V0.22 as it has more features and the rendering is just so much faster.

Many thanks in advance for your help.

Regards,
-Ken

Matthias

Hi Ken,

I usually try to be backward compatible, but 0.22 is a big step, so I have to check whether there is any compatibility issue.

Best regards,

Matthias

Matthias

Hi Ken,

I'm afraid I can't reproduce it.

I do the following:

• I have two layout x.gds and y.gds
• I prepare two section scripts: file1.xs and file2.xs
• I installed xsection.rbm with the patches as described above
• I run KLayout: "klayout -e x.gds y.gds"
• I select the left panel. I draw a ruler through some structures and press "XS1"
• A new panel opens with the cross section of the left layout
• I select the second layout
• Again I draw a ruler
• I hit "XS2"
• A new panel opens with the cross section corresponding to the second layout and ruler

So basically it appears to be working. So I wonder what might be the problem in your case. First guess is that the script does not find "file2.xs". But in that case, an error message should appear.

The second guess is that the file2.xs is not working propertly. I'd also expect that this would give an error message, but one never knows. Can you tell whether it's file2.xs or the second layout is causing the problem? Or: does the second button work on the first layout?

And if you're on Linux: do you get and error message on the terminal?

If it turns out it's the second .xs file, maybe you are able to pinpoint the reason or send the file to my address mentioned on the contacts page.

Best regards,

Matthias

kqtran

Hi Matthias:

Thank you for checking into it.

I'm using 32-bit Windows 7 professional with Service Pack 1. I presently don't have a Linux setup.

In my setup I could repeat the problem everytime I try V0.22 but not on V0.21.19.

Furthermore, both of my file1.xs and file2.xs individually works on x.gds and y.gds.

It's just that if I draw a ruler on either x.gds or y.gds and press "XS1" first, then only it works and continues to work with additional cuts. "XS2" does nothing.

Conversely, if I start with "XS2" first, then only it works and continues to work, and "XS1" does nothing.

For what it is worth, my file1.xs and file2,xs are ~70% similar and not exactly the same.

Thanks,
Ken

Matthias

Hi Ken,

I was able to reproduce the problem on Windows.

I could track it down to Ruby. The Action object are garbage collected because insert_item does not keep a reference to them. I'll try to fix that in the core code.

Fortunately there is a simple fix for that. Use the following patch above instead of the original one:

menu = mw.menu
if !menu.is_valid("@toolbar.xsection")
  menu.insert_separator("@toolbar.end", "tb_separator")
  menu.insert_item("@toolbar.end", "xs1", $xsection_action_1 = MenuAction.new("XS1", "") { XSectionGenerator.new("file1.xs").run })
  menu.insert_item("@toolbar.end", "xs2", $xsection_action_2 = MenuAction.new("XS2", "") { XSectionGenerator.new("file2.xs").run })
  menu.insert_item("@toolbar.end", "xs3", $xsection_action_3 = MenuAction.new("XS3", "") { XSectionGenerator.new("file3.xs").run })
end

(note the $xsection_... global variables which keep the reference so the action objects don't get lost).

I have edited the patch above as well so nobody won't use the wrong one.

On my installation that fixed the problem.

Best regards,

Matthias

kqtran

Hi Matthias:

I used the patch above, but for unknown reasons, my results are the same as before.

That is, which ever button I click on first is the one that works. The 2nd button does nothing subsequently.

Just to make sure I didn't make typo somewhere, I dragged the mouse and copied/pasted verbatim the above. Same problem for me still. :(

Any further insights would be much appreciated.

Thanks,
Ken

Matthias

Hi Ken,

That's a pitty. I was definitely able to solve that problem with the patch on my Windows 7 installation (on 32 and 64 bit).

I suspect that with all this patching our versions got out of sync. Or that you have more than one copy and KLayout is using the non-patched second-latest one.

In the meantime, because I felt that this 3-button solution with the fixed file assignment is just a hack, I have provided a version integrated into the user interface is a more natural and more generic fashion.

Maybe you like to try the current version. You can download xsection.rbm at http://xsectionklayout.svn.sourceforge.net/viewvc/xsectionklayout/trunk/src/xsection.rbm.

In contrast to the three-button solution, you can choose any file using "Tools/XSection Scripts/XSection Script". A file browser will open and you can select any .xs file.
Once you have selected one, it is available as a shortcut menu item below in the "Tools/XSection Scripts" menu. The list will survive when you exit KLayout and you can pick a .xs file rather quickly from that list, so this solution may be almost as convenient as the 3-button one, but is more generic.

I think this solution does not have problems with non-functional tool buttons.

Hopefully that leads further,

Best regards,

Matthias

kqtran

Your generic and flexible solution is brilliant. Thank you for all the efforts, Matthias.

BTW, after chasing around, I think I have figured out my problem. It is due to a pre-patched xsection.lym under my c:/users/username/klayout/macros folder that always get loaded. I must have accidentally created it when I was playing around with the macro development features. Anyways, that seems to supercede the xsection.rbm so no matter what I did to xsection.rbm, it didn't work.

Best regards,
-Ken

Matthias

Hi Ken,

Thank you for the feedback :-)

And you're right, there are different places where KLayout looks for script files. Since I try to stay backward compatible there are already a couple of them now. c:\users\username\klayout\macros is one of them and that is where you can put your own scripts to if for example you don't have admin rights to stored them in the installation folder.

I'm glad there is such a simple explanation :-)

Best regards,

Matthias

kqtran

Hi Matthias:

I have a need perform "processing" on the wafer backside once the frontside is done.

As I understand it, the current xsection.rbm operates the stackup from the bottom to the top.

Would there be a way to enhance the code to mirror-flip the x-section around after a number of steps, and continue with "processing" (which is now on the backside)?

Many thanks in advance,
-Ken

Matthias

Hi Ken,

that's a interesting application, but such a feature is missing unfortunately.

I'm sure that is possible somehow (likely with a minor enhancement). I'd like to have a look into that, but I ask you for some patience - I am quite short of time currently.

Best regards,

Matthias

kqtran

Hi Matthias,

I completely understanding.

I'm trying to get up to speed on Ruby coding, so if there are any hints, that would be very useful as well.

Thanks in advance,
-Ken

kqtran

Hi Matthias,

I'm trying to write some Ruby code under the MaterialData class to mirror the xsectional polygons to enable further processing on the original wafer backside.

Could I get some hints on what argument "xs" is and how it is used?

Any additional help on the mirroring code would be greatly appreciated as well.

Thank you in advance.

-Ken

Matthias

Hi Ken,

it appears that you are desperate ... :-)

It's definitely not easy to modify the script when not familiar with the concept. First of all, "xs" is the XSectionGenerator (singleton) object. That object keeps track of general information while the cross section is computed. Specifically, one piece of information kept in the xs object is the "air" geometry which is basically everything which is not some material.

I have tried to implement the mirror code myself and found it difficult to do based on a geometrical transformation. The reason is that for doing so one has to update "air" to now describe the region below the wafer. That is tricky because the cross section generator does not track material data itself and the information about what is "not air" is not available.

But the air object offers a pretty simple way of solving your problem: by providing two "air" objects - one above and one below the wafer - we can simply implement backside processing by using "air below" instead of "air above".

Sounds strange? It is in fact. But it works because of two remarkable properties: first, most (except deposition) processing operations are symmetrical - they apply upwards as well as downwards. Normally you won't notice, because etching into "air" does not have an effect. But that means we can simply put "air" below and "material" above and the result is upward etching. Second, it's the interface between "air" and "material" which acts as a seed for the processing. And the direction of the interface does not matter.

I have updated the xsection.rbm script accordingly. You can download it here:

https://xsectionklayout.svn.sourceforge.net/svnroot/xsectionklayout/trunk/src/xsection.rbm

It has two new operations:

• "flip" will switch between backside and frontside processing
• "below" will specify the thickness of "air" below. The default is 2um

Please note that "depth" will specify the width of the wafer. After flipping, the backside of the bulk layer with thickness "depth" is processed.

For the processing of the backside use the same operations than for a clean frontside (in particular start with a copy of "bulk"):

depth(150)   # wafer thickness

pbulk = bulk

... frontside processing ...

flip
mask(tsv).etch(150, :into => pbulk, :taper => 2)
... more backside processing ...
flip

... continue frontside processing

Hope that helps.

Best regards,

Matthias

kqtran

Hi Matthias:

Thank you for the much needed help. I was struggling to understand many aspects of your script. Now I understand a bit better of how the xsectiongenerator uses "air" to know whether to process up or down. Before, I had absolutely no idea about this concept.

Best regards,
-Ken

Matthias

Hi Ken,

you're welcome.

I had no idea about this solution myself before I started to experiment :-)

Best regards,

Matthias

kqtran

Hi Matthias:

I was experimenting with the new flip command recently.

I noticed that after "flipping" and depositing 1 layer of some thickness on the backside, I can get anything further deposition to show up.

No problem on the frontside though.

For example, in the script example below, backild2 doesn't result in any deposition:

depth(50)
below(100)
height(100)
pbulk = bulk

frontild1 = deposit(10)

flip
backild1 = deposit(10)

flip
frontild2 = deposit(20)

flip
backild2 = deposit(20)

I haven't been able to determine what's going on so would really appreciate your expertise here.

Thank you.
-Ken

Matthias

Hi Ken,

you mean "cannot get ..", right? :-)

Anyway, I could reproduce the problem. I have also found a cure: actually the "world" did not extend far enough below the wafer (including depth). I have checked in a new version of the script here: https://xsectionklayout.svn.sourceforge.net/svnroot/xsectionklayout/trunk/src/xsection.rbm.

This one should work.

Best regards,

Matthias

kqtran

Thanks Matthias.

You're right... sorry for the typo. If I'm not mistaken, the fix is in:

mask_polygons.push(RBA::Polygon.new(RBA::Box.new(p1, -@depth - @below, p2, @height))) ?

I just noticed that the planarize command doesn't seem to work right for the backside.

If appears to polish the frontside (instead of backside) boundary of a layer, and strangely remove the entire thickness of the backside?

Thanks,
Ken

Matthias

Hi Ken,

you're right, both with the fix and the observation that the planarize command does not work.

The planarize command needs some special handling in the flipped case. I have updated the script at the given location (see above) accordingly. Now I am able to produce the complete demo CMOS stack at the backside.

Thanks and best regards,

Matthias