A nice feature enhancement would be the ability to export layers to FastCap and FastHenry.
I think that this can be done with the Ruby scripts so maybe I will take a whack at it. If anyone else has already done this it would be great if you can share.
I had a brief look into the documentation but I am not quite sure about the tesselation issue. There seems to be a tool that generates a mesh for a rectangular geometry and create .qui files that you can include, but I understand that it's more common to generate the mesh directly.
Is there any more material I could look at? In particular I assume there are some guidelines how to choose the mesh density or the tesselation strategy for example.
I am trying to make myself familiar with FastCap and FastHenry. I wonder what to do with non-rectangular features - I assume that decomposing them into rectangles and triangles would be a good starting point.
I'm aware this comment is from a while ago ... I'm currently working on finding a program to breakdown these non-rectangular features into the FastCap .qui format. Did you find a way to do this or is this an unsolved problem?
no sorry - I did not pursue this thread much further. Decomposition into parts is available but I don't know the requirements of FastCap. I understood this is tessellation and not just decomposition. I assume that a dumb trapezoid decomposition is not really helpful.
I don't know if this might help, but FastCap is integrated into another open source ASIC toolset: https://github.com/wrcad/xictools. Possibly, it may be an inspiration how to implement FastCap&FastHenry into Klayout.
A better link is : https://github.com/yuchsiao/caplet :
-. caplet_gds2geo is python script to change the .GDS file into a .geo file (ascii 3D file)
-. caplet_geo has to be compiled (C++) and is changing .geo file into .qui that can be read by FastCap
I succeeded to compile all the files, get the .geo file, ... but failed to get the .qui file
thanks for the link. Just to confirm, the caplet_geo generates .qui files, you must specify "--type pwc" for "caplet_geo_cli" program or you can execute FastCap directly from gui. I tried it with FastCap from xictools.
Did you succeeded to make a proper C extraction from a GDS ? or someone else ?
If yes, can you share some example files (GDS, qui and spice file) ?
It seems that xictools is the software to use ...
FastCap and FastHenry integration / interfacing is on my to do list. However, as of now, I have not taken a deeper look into that topic yet. I feel that in order to be useful, some integration on a lower level is required - specifically within the netlist extraction framework.
Did you succeeded to make a proper C extraction from a GDS ? or someone else ?
If yes, can you share some example files (GDS, qui and spice file) ?
It seems that xictools is the software to use ...
Automated preparation of input files for field solvers like FastCap or FastHenry sounds like a fun and useful functionality.
However, I have a question - what would be the main usage model of this functionality?
Where does it fit, in the spectrum of tools, on one end of which is a fully automated approach (used in IC design world), and on the other end - fully manual, hand-crafted (one time) preparation of the input and running the simulation?
In IC design world, people use parasitic extraction tools - very sophisticated, heavyweight, powerful tools, supported by big EDA vendors, foundries, PDKs, etc. They fit well into the IC design flow, and rely heavily on LVS (output form LVS is an input for parasitic extraction).
They are fully automated (once someone - a CAD or methodology engineer - sets up the flow), and perform their job with a click of a button.
They are very expensive as well (one license may cost tens and hundreds of thousands of USD).
On the other end of the spectrum - various field solvers, many of them - free.
The input is tedious and time-consuming. The tools many not be very stable and robust, and may not have a good customer support.
These tools are used relatively infrequently, and/or in situations where time is not a priority (time to market, engineering time, etc.).
What would be the scenarios and usage models for the discussed automation of input data preparation, from Klayout, to various field solvers?
Comments
Hi Oliver,
is there any specification about the format required by these programs?
I am not familiar with those myself.
Best regards,
Matthias
They are both open formats. See this link:
http://www.fastfieldsolvers.com/links.htm
FastCap has a particularly simple file format, but it would benefit from pre-tessellation.
This would allow folks to model their GDSII files better.
Oliver
Hi Oliver,
I had a brief look into the documentation but I am not quite sure about the tesselation issue. There seems to be a tool that generates a mesh for a rectangular geometry and create .qui files that you can include, but I understand that it's more common to generate the mesh directly.
Is there any more material I could look at? In particular I assume there are some guidelines how to choose the mesh density or the tesselation strategy for example.
I have to admit that the topic is new to me.
Best regards,
Matthias
A parameter to control the mesh density would be nice.
I would think that breaking things into rectangles would work well for GDSII files.
Oliver
Hi Oliver,
I am trying to make myself familiar with FastCap and FastHenry. I wonder what to do with non-rectangular features - I assume that decomposing them into rectangles and triangles would be a good starting point.
Best regards,
Matthias
Mike
Hi Mike,
no sorry - I did not pursue this thread much further. Decomposition into parts is available but I don't know the requirements of FastCap. I understood this is tessellation and not just decomposition. I assume that a dumb trapezoid decomposition is not really helpful.
Any inputs?
Matthias
Hi all,
I don't know if this might help, but FastCap is integrated into another open source ASIC toolset: https://github.com/wrcad/xictools. Possibly, it may be an inspiration how to implement FastCap&FastHenry into Klayout.
Regards,
Michael
A better link is : https://github.com/yuchsiao/caplet :
-. caplet_gds2geo is python script to change the .GDS file into a .geo file (ascii 3D file)
-. caplet_geo has to be compiled (C++) and is changing .geo file into .qui that can be read by FastCap
I succeeded to compile all the files, get the .geo file, ... but failed to get the .qui file
Laurent
Hi Laurent,
thanks for the link. Just to confirm, the caplet_geo generates .qui files, you must specify "--type pwc" for "caplet_geo_cli" program or you can execute FastCap directly from gui. I tried it with FastCap from xictools.
Michael
Hi Michael,
Did you succeeded to make a proper C extraction from a GDS ? or someone else ?
If yes, can you share some example files (GDS, qui and spice file) ?
It seems that xictools is the software to use ...
Laurent
Dear all,
thanks for the pointers.
FastCap and FastHenry integration / interfacing is on my to do list. However, as of now, I have not taken a deeper look into that topic yet. I feel that in order to be useful, some integration on a lower level is required - specifically within the netlist extraction framework.
Matthias
Hi Michael,
Did you succeeded to make a proper C extraction from a GDS ? or someone else ?
If yes, can you share some example files (GDS, qui and spice file) ?
It seems that xictools is the software to use ...
Laurent
Automated preparation of input files for field solvers like FastCap or FastHenry sounds like a fun and useful functionality.
However, I have a question - what would be the main usage model of this functionality?
Where does it fit, in the spectrum of tools, on one end of which is a fully automated approach (used in IC design world), and on the other end - fully manual, hand-crafted (one time) preparation of the input and running the simulation?
In IC design world, people use parasitic extraction tools - very sophisticated, heavyweight, powerful tools, supported by big EDA vendors, foundries, PDKs, etc. They fit well into the IC design flow, and rely heavily on LVS (output form LVS is an input for parasitic extraction).
They are fully automated (once someone - a CAD or methodology engineer - sets up the flow), and perform their job with a click of a button.
They are very expensive as well (one license may cost tens and hundreds of thousands of USD).
On the other end of the spectrum - various field solvers, many of them - free.
The input is tedious and time-consuming. The tools many not be very stable and robust, and may not have a good customer support.
These tools are used relatively infrequently, and/or in situations where time is not a priority (time to market, engineering time, etc.).
What would be the scenarios and usage models for the discussed automation of input data preparation, from Klayout, to various field solvers?