Forum Replies Created
-
Posts
-
In 4.3.46 there will be an offgrid checking capability:
geomOffGrid(layer1,
grid, marker_size=0.1, const char *message=NULL)Checks all layer1 vertices of
edges to see if they are on a multiple of the grid specified in microns by grid.
marker_size is the size of the marker in microns (shown as a '+' centered on the offgrid
vertex) on the drcMarker layer. An optional message
will be written to the error marker flag if specified.In 4.3.46 there will be
geomLabel(drcEdgeFile * lyr, const char *layerName, const char *purpose="drawing", bool createPin=true)
and
geomSetText(drcEdgeFile *edgeFile1, db_Float64 x, db_Float64 y, const char *labelName, bool createPin=true)
In 4.3.46 there will be a function geomGetTotalCount() which will return the total number of DRC errors since a geomBegin().
Hi Paco,
It's easier to have a single function:
geomLabel(drcEdgeFile * lyr, const char *layerName, const char *purpose="drawing", bool createPin=true)
(note you could already specify different purposes, just the default was "drawing")
So if you want to label a net but not create a pin:
geomLabel( layer, "METAL", "drawing", 0)
regards
Keith
geomGetCount() as you see gets the error count of the previous step. There is no total error count kept although this would be fairly easy to add.
geomGetShapes() will merge shapes, so e.g. two abutting DRC markers will be reduced to one. Hence what you see, the total number of (merged) markers is likely to be less than the total number of errors.
You could use the undocumented geomGetRawShapes() which takes the same args as geomGetShapes() but does no merging. However even then you may get some slight differences as some DRC checks e.g. geomMargin() return two marker shapes for what is essentially one error.
geomLabel() will assign a net name to a shape prior to connectivity extraction, and when determining connectivity will use these net shapes as the starting trace points. This way e.g. shorts can be detected.
geomLabel() will also create a pin for this net, so the CDL writer will add them to the .subckt header as pins.
I guess there may be cases where you want to label internal nets that are not pins, so an option could be added NOT to create the pin in this case.
(The other way round – having a pin but no net – is not allowed; all pins must have a net, even if the net has no physical shapes).
Hi Paco,
I will need to check this on Linux, currently I'm running on Windows here.
I found another bug in MPPs – the shapes are ignored in DRC checking. I am currently fixing this. Then I'll check the cases you have on Linux.
regards
Keith
I just tried:
>1. Trying a linear 2-point MPP (left click for the first point + space for the >second) does not seem to work. Glade complains:
># ERROR: MPP has 1 points – will not be created!and it worked fine for me – left click for 1st point and return or double click for second (space does nothing). You should see in the logfile something like:
>>> # INFO: Adding MPP point #1 at (-2.385, -12.508)
>>> # INFO: Adding MPP point #2 at (46.601, -12.508)>>> # INFO: Created MPP with 2 points
For the 1st contact placement, you need a BEGEXT for the contact (WINDOW) layer of -1.25, not +1.25, as the contact needs to be placed centred on the first vertex of the path.
regards
Keith
Sorry just corrected #3. Yes, you have to have a library of the same name open, but it should not have the techfile read into it as dbOpenLib() reads the binary techfile from disk (the glade.lib file).
regards
Keith
Hi Paco,
1. I recall this bug existed before with Create Path, and the Create MPP code is similar. Should be easy to find and fix before 4.3.46 release.
2. No, at least not yet.
3. Are you trying to open an existing lib (on disk) or create one from scratch? If the former then just use:
Code:# Opening libs
libName = "fred"
lib = library(libName)
lib.dbOpenLib("./"+libname)If you want to create a new one:
Code:# Opening libs
libname="mylib"
gui.importTech(libname,"./mytech.tch")
lib=getLibByName(libname)I'll have a look at the contact problem. The contact placement code needs improvement to space the contacts symmetrically on the MPP segments.
regards
Keith
Hi Paco,
Alas what you appear to have done is to re-load the techfile into the library. If you select and query one of the MPPs you will see that you have the original negative extenstions plus the new positive ones.
Currently the way that MPPs are defined in the techfile means that they are alaways added to. This needs fixing so existing definitions are deleted if present but this is not done yet.
regards
Keith
Hi Paco,
That simplifies things and makes sense. I'll just write the .gladerc to the home directory.
BTW – as to the local .gladerc containing just a subset of options, this will work. Just delete the lines containing the ones you don't want to keep. The parser just looks for:
<keyword> <value>
lines, and if some keyword lines are missing then they will not get set and the default used.
Now this may not be what you want – if you want the ~/.gladerc file to contain all options (where some are not default values), and have the local .gladerc read and overwrite some subset of all options, then it would be necessary to read both files. Not really a problem – let me know if this is what you need.
regards
Keith
Hi Paco,
Thanks for the examples. BTW I don't think you have the techfile set up quite right. The BEGEXT values should not be negative but positive. They are the extensions at the beginning of the path, in the direction away from the beginning.
One ther thing, MPP contact cuts only work for manhattan angles. In theory the cuts could be turned into polygons and rotated, this may be OK for 45 degree paths, but I'm not sure it would be manufacturable for any angle paths.
regards
Keith
