Weird behavior in meshing on octave interface #171
-
|
Hello, I'm trying to run a simulation of a microstrip line on the substrate configuration of the open-source sky130 CMOS technology. I'm using a complete representation of its substrate layers and I'm trying to get the mesh on the z coordinate to run properly. I'm getting a very weird behavior of a lot of lines bunching up at the bottom of the signal and ground metals, and after spending the best part of the evening trying to debug it, I basically gave up... Here's my simulation code. It's based on a similar code written to simulate an inductor on IHP SG13G2 technology (https://github.com/IHP-GmbH/IHP-Open-PDK/tree/main/ihp-sg13g2/libs.tech/openems/testcase/SG13_Octagon_L2n0/OpenEMS_Matlab): Also, when I open CSXCAD, I get an error message saying that most of my materials have no properties, and Sub_Metal2 represents almost all of my substrates... Could someone take a look and tell me what I'm missing? :) |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 10 replies
-
|
Hi Leo, I am the author of the IHP SG13G2 model example, and tried to debug your model now. Everything looks ok if we remove the metal and via definitions and meshing. To find out what actually causes your problem, I recommend that you build this step by step, one metal layer after another and one via layer after another. I suspect that you have some ultra-thin layer somewhere, due to a typo.
No, the warning is that you have no geometries in certain properties. That means you have no geometries on many of the layers that you defined. This is actually true and correct regarding metal and via layers, but the message also complains about Sub_Metal3 and Sub_Metal4 and Sub_Metal5 which are some of your inter-metal dielectrics. That last part looks definitely wrong, so check your dielectric stackup carefully before even adding metal and via layers! EDIT: this last issue is simple copy & paste mistake, you added the boxes to the wrong dielectric layer. So my advice here is really to go step by step, and check everything early in AppCSXCAD! Build your dielectrics, then build your metal layers one after another, and check that they appear at the correct z position, before you even add code to do the z-meshing of metals. Then add the vias, step by step. Best regards |
Beta Was this translation helpful? Give feedback.
-
|
Hello again, I stripped down your model, temporarily removed all the mesh line code in the metals and vias, and placed a metal polygon on each metal layer.
The metal positions look ok, but you see that we already have some z-mesh lines in the region from Metal1 to Metal5, although I had removed the additional z-mesh code that you added for each metal layer. Note that some mesh lines are very close to the top/bottom position of the metals. I think what went wrong with your original code is that you had a combination (overlap) of the mesh lines shown above plus the linespace() mesh lines across the metal height. The issue is that this can result in mesh lines which are extremely close (=> issue with FDTD time step!) and the SmoothMeshLines() then added another million graded mesh lines next to that super-tiny mesh cell. My advice is to re-structure the z-directed mesh, and also take out this line Hope this helps |
Beta Was this translation helpful? Give feedback.
-
|
@VolkerMuehlhaus , thank you so much for your attention and very in depth response! I think I didn't quite understood how to define the mesh in the Z direction. From what I understood from your example, you manually added (thinner) meshing inside the metal to model the skin effect, by adding |
Beta Was this translation helpful? Give feedback.
-
Yes, exactly.
Yes, I think somewhere in your code you place a mesh in z direction across the entire range, and then you add more mesh lines according to other rules, and now some of the combined mesh lines are getting VERY close and screw up things. I haven't yet figured out where it happens.
Yes
Yes, correct. I also went this way, adding mesh lines ONLY in the region below Metal1, then ONLY in the regio above Metal5, then ONLY in the metals, then checking if we need a few more mesh lines in between. And then do SmoothMeshLines at the very end. VIAS: In most cases, I would mesh vias with just 1 cell in z direction. AVOID anything than can place mesh lines at very small distance, by multiple mesh runs that with overlapping z range. |
Beta Was this translation helpful? Give feedback.
-
|
Here is my last try for today, where the ultra-dense mesh is almost gone, except for the bottom side of Metal1. That might be from placing a mesh line at top side of Sub_LI combined with the linspace() for Metal1, perhaps some rounding/precision issue so that this mesh line is not exactly identical.
|
Beta Was this translation helpful? Give feedback.
-
|
Dully noted @VolkerMuehlhaus , thank you so much again! By the way, by only one cell you mean two Z points, top and bottom? Or just the top (or bottom) one? |
Beta Was this translation helpful? Give feedback.
-
|
I meant one mesh cell = two mesh lines, top and bottom. |
Beta Was this translation helpful? Give feedback.
-
|
And here's a better meshing! Now to run the FDTD.
|
Beta Was this translation helpful? Give feedback.
-
|
Yesterday you posted that FDTD doesn't converge, but I can no longer find that comment. Problem solved? Some more hints:
So I would place "manual" mesh lines near the ports only, and let SmoothMeshLines() take care of the middle part of the line length. This will save a lot of mesh cells, with little effect on results.
|
Beta Was this translation helpful? Give feedback.
-
|
I deleted the comment because I wanted to let it finish before asking for help again. However, after some 7h the energy struggles to descend below -40dB (after taking about 2h to start decreasing). So, yes, mesh is over-dense, you're right. Today I plan to experiment with it before launching another run. Also, after your own experience, simplifying the dielectric leads to any speed improvement? |
Beta Was this translation helpful? Give feedback.
-
|
Simulation time depends on two parameters here:
We need to discretize into skin effect, so there is not much we can do about the smallest mesh cell, this will be around 0.5 um. For total number of mesh cells, we can certainly save a lot by lower mesh density in regions where "nothing happens", i.e. small field changes. So indeed I would use less mesh density in the "empty" region at Metal2-4, if there is nothing drawn on these layers. There is a transmission line example for SG13G2 for openEMS Python in the IHP OPDK project, maybe you want to have a look there. You can load the XML file into AppCSXCAD and see what mesh I used there. Good luck and have fun :-) |
Beta Was this translation helpful? Give feedback.
-
|
PS: Don't forget to fix the mistake with simulatenous excitation on both ports, that will give nonsense results. |
Beta Was this translation helpful? Give feedback.
-
|
Oh, thanks for pointing that out! That's what you gain by coding while being tired, I think :) I did try to give your microstrip example a run to study the mesh, but for some reason my python environment cannot find CSXCAD and thus I cannot plot the geometry. I'm clueless about what's causing it... Thank you so much for your help, @VolkerMuehlhaus . That's being invaluable! |
Beta Was this translation helpful? Give feedback.
-
|
To study the mesh, you can also start AppCSXCAD manually, and then load the XML file manually. |
Beta Was this translation helpful? Give feedback.
Hello again,
I stripped down your model, temporarily removed all the mesh line code in the metals and vias, and placed a metal polygon on each metal layer.
The metal positions look ok, but you see that we already have some z-mesh lines in the region from Metal1 to Metal5, although I had removed the additional z-mesh code that you added for each metal layer. Note that some mesh lines are very close to the top/bottom position of the metals. I think what went wrong with your original code is that you had a combination (overlap) of the mesh lines shown above plus the linespace() mesh lines across the metal height. The issue is that this can result in mesh lines which are extremely close (=> …