I am looking for a feature where the user draw a virtual horizontal or vertical line (w/ may be some limit in the length) and the tool display in another panel the vertical cross section of that part of the layout. Of course the user must provide somewhere the thickness of the different layers and the height from the substrate to (in the layer property file ?) I was wondering if it will be possible to implement a feature like that ?
Of course, the ultimate goal will be to have a 3D view of that portion of the layout :-)))
I had a couple of discussions about the feature already. It looks like you're not the only one looking for that :-)
Technically the issue is not to provide an interface to the layout but rather to implement a more or less reasonable cross section generation algorithm and to interface to a technology description.
Me too please - as realistic as practical, which means a good few masking operations and polygon re-shaping methods, plus a fairly complex technology description - a huge task unless you can find an ally... ;-)
I am referring to Joaquim's request above. I think it would be most practical to be compliant with an itf description (already because this is the kind of information that will usually be accessible).
In reality I might skip many options there and stick with a simple sequence of conformal and non-conformal intermetal dielectrics. (But maybe other users closer to PFA will appreciate the option to specify side-wall and top-thicknesses or tapering...)
After thinking somewhat about that request, I think I can come up with a very simple solution.
IMHO it is possible to emulate the process stack more or less using the boolean and sizing functions already built into KLayout. I have performed some experiments. Have a look at the screenshot about one result.
The underlying concept is to create a vertical cut where polygons represent the materials. A ruler specifies the cut line in the original layout. A ruby script creates the material geometry and provides methods to simulate the process steps in a very simple way. It produces a new "layout" in a new panel. This way, rulers, layer (=material) coloring, screenshot and other features are available as well.
In that scenario, a ruby script declares the process steps by executing a sequence of operations that define input geometry, apply material modifications and output the results. This script must be provided for a certain technology. It's not as simple as a table description but far more versatile.
A sample script may look like that:
m = mask(layer("3/0").sized(-0.5))
si = bulk
fox = m.grow(0.5, 2).or(m.grow_into(0.5, 0.5, si))
poly = all.grow(0.5, 0.5)
output("1/0", si)
output("100/0", m)
output("101/0", fox)
output("102/0", poly)
For a brief description: "layer" extracts and original layer. Such layers can be sized and boolean operations can be applied. "mask" converts horizontal geometry into intervals along the cut line and produces thin seed lines on the surface of the current material stack. "all" is a special mask which covers all. "grow" will make the given seed line grow atop of the material stack. In this case, two dimensions are specified which means that the material will grow in xy and z direction (xy first, z second). Both grow values can be different. The non-conformal extreme case would be xy=0. "grow_into" means material is consumed. "bulk" is the initial wafer surface. "output" will produce the material geometry on the respective output layer.
This sample is supposed to mimic field oxide formation and deposition of some poly layer (gate oxide and all the well/implant things are omitted to keep it simple). This script was actually used to produce the screenshot.
The script is not nearly finished, so I don't have anything to provide yet. I'll follow up on that topic here soon. I am not quite sure whether that is a stupid approach to use, so I'd appreciate feedback.
I have contacted you earlier via email on a cross-section program that I already have. Unfortunately, there are copyright issues with sharing the code. Also, the approach that you propose using booleans is in principle much faster than the algorithm that I implemented. So, I think it is an excellent approach, as long as the boolean code handles glitches correctly (which I seem to recall it does).
I would be interested to contribute (would need to learn Ruby etc). Realistic is important for many applications, and the boolean approach allows that in principle.
Etching holes is probably a little harder to program than deposition. You will need to deal with different etch rates on different materials in some way, and for true realism you need to give the etched holes a realistic shape (isotropic / anisotropic). A more realistic bird's beak on LOCOS would also be nice. (My program does all that in principle, but does not use the boolean approach, so we would have to find a different way to get the same result.)
The script approach is very flexible, but has a long learning curve for new users. Several solutions are possible. The simplest is probably to have more advanced functions like "deposit" and "etch". It may be an idea to use an intermediate text file with a simpler non-Ruby syntax, or perhaps even a GUI, and generate the script from there.
Matthias, let me know how I can help. Another question: is BigBren who I think it is?
I tried to picture what you describe and as far as I can tell I can do everything I need with your proposed code.
Two little things where I am not sure though: 1. What about a burried layer? I would have to do a grow_into for the lower AND the upper edge (in Z) of the layer. Is that supported? 2. What is the Xsection result when I am cutting right next to a shape that is covered by a conformal layer? Will the increased thickness of the coverlayer be displayed correctly? (This is where I am running out of imagination...)
I have performed some more experiments on the boolean approach and adding a "planarize" function already gives some flexibility. I tried to describe a simple CMOS process and a result screenshot can be found here. If anybody is interested in the scripts: the ruby module is xsection.rbm, the technology description is cmos.xs.
I think it's possible to create buried layers as well, because it should be possible to describe epitaxy process steps as well (as a deposition step).
But I think Hans is right - the approach has some limitations. To simulation different etch rates would be difficult. Also my LOCOS does not show the beak. And I agree - a simple description would be easier to adopt by the users.
My basic question is if it's worth to further investigate the approach? What is a promising approach like? I assume that simulation an etch process would require some kind of solver for the rate equation, right?
I buried myself in "The Ruby Programming Language" for a week and have not followed the forum. Ik will now study the code and give my comments / additions. Thank you for making this available.
This thread is quite exciting, and the idea of a boolean approach, with the intention of also achieving the realism of Hans' famous program, seems very promising. Yes Hans, it is who you think it is, and I would be happy to test out any new code with the latest simple process I'm working on...
Please note that this is more like a feasibility study. It's not perfect in every respect. In particular, the sizing approach is very limited and somewhat fragile. I'd like to try to enhance the script by providing a more versatile hull generation algorithm which can provide a more realistic LOCOS beak for example.
If you find the approach useful, I'd try to start a real project for example on SourceForge for that.
I was trying to implement a real stack with a total height > 2um so I was changing the default values for height (and depth). Doing so the deposition command deposits material also from a 'top line' 2um above bulk downwards which is not what I want. I reckon this can be adapted in xsection.rbm but I didn't dive deep enough to see where. Can you help?
I think the script is rather a proof of principle, not a useful implementation. Because there was some interest in that topic I started a project on sourceforge (http://sourceforge.net/projects/xsectionklayout/). Hopefully, some useful solution will emerge.
I have fixed that problem along with a nasty flaw: now, the cross section is extended internally somewhat further by an adjustable parameter ("extend", default is 2um) to eliminate boundary effects.
