[Keith]

Hi Paco,

It may be possible to change this behaviour, I'm not sure. When using the MMB drag to pan, the world coordinate space is moved.

It may be possible to modify the start coord used for commands by a similar amount, but there could be a whole host of unwanted side effects. I'll try a few quick things to see.

regards

Keith

[Keith]

4.3.47 should be up on the website for download shortly…

[Keith]

Fix is done and working. I will need to build you a ubuntu 64 bit test version, if that is OK and runs through the regression tests, I will release 4.3.47 by the weekend…

BTW your code:

geomConnect( [
[ptap, pwell, pdiff],
[ntap, nwell, ndiff],
[cont, ndiff, metal1],
[cont, pdiff, metal1],
[cont, polygate, metal1],
[cont, polycap, metal1],
[via12, metal1, metal2]
] )

can be simplified to

geomConnect( [
[ptap, pwell, pdiff],
[ntap, nwell, ndiff],
[cont, ndiff, pfiff, polygate, polycap, metal1],
[via12, metal1, metal2]
] )

as you only need 1 via layer to connect to all the other layers it connects to. No real harm doing it your way though, except it will be slower as you're duplicating cont<-> metal1 checking 4 times…

regards

Keith

[Keith]

Hi Paco,

Right now, the code assumes the cell name of the device is the same as the model name, i.e. it will first look for a cell called 'cnm25cpoly_xtr', view 'extracted'.

If that cell is not found it will create a cell <model_name> 'extracted' and create a recognition region on the Y0 layer. It will also create nets/pins as specified e.g. T and B.
A property 'type' is added to the cell depending on the first letter (prefix) of the model name e.g. if 'C' or 'c' then type = "cap", if 'M' or 'm' type = "mod" etc.

Then an instance of name of the form <prefix>nnn is created where n is an incrementing number from 0.

For each terminal name / layer in the list it then looks to see if any shapes on that layer touch/abut the recognition region, and if so creates an instPin to connect to the pin in the inst master.

Now this code needs updating to be the same as the other extract… devices i.e. to accept an extraction pcell of view type 'layout'.

The reason it's failing is that it expects the instance master to be of viewName 'extracted'. I don't know if a temporary hack would be to copy the cellView to the same cellName, but different viewName i.e. extracted.

The real solution will be changing the code to make it the same as the other devices, as above. That should be possible by tomorrow.

regards

Keith

[Keith]

Hi Paco,
extractDevice() has never been fully tested; also it needs converting to the model of other devices to accept a pcell extraction inst master. Do you have a simple example?
Regards
Keith

[Keith]

Hi Paco,

geomLabel() only works with text labels – not pins. I would not try to create pins in layout views unless you have specific reasons, e.g. to create abstracts.

regards

Keith

[Keith]

Hi Paco,
I have put a patched Ubuntu 64 bit version on the website at https://www.peardrop.co.uk/glade/glade4_linux64_ub10.tar.gz.
Please test and let me know how you get on with it.
Thanks,
Keith

[Keith]

Hi Paco,

Thanks for the feedback.

#1 – this is due to trying to be clever and remember the last MPP type/net name on subsequent create MPPs. Needs a small change to allow you to change it in the dialog correctly.

#2 – yes this is still not optimal. I'll see if this can be improved, at least to remove the DRC…

#3 – have already fixed this.

#4 – how are you trying to flatten them? You should use Edit->Convert to Polygon, not Edit->Hierarchy->Flatten… as MPPs are not instances.

regards

Keith

[Keith]

This should be all fine now in 4.3.46.

[Keith]

Hi Paco,

You need to specify 4 arguments if you wish to specify the message:

num = geomOffGrid(layer1, grid, marker_size=0.1, const char *message=NULL)

In your example you spcified three – missing the marker size.

regards

Keith

[Keith]

Hi Paco,

I'm not sure this is a good idea. I guess it is a pain that multiple logfiles are generated (originally only a glade.log file was, but this wqas changed after user requests). However, it is useful for bug resolution. I'm concerned that if this mechanism can be turned off, people will turn it off, and valuable crash data may be lost.

regards

Keith

[Keith]

Errm it should be in the 4.3.46 version released today. If not let me know, maybe the build step went wrong somewhere and failed to update the swig bindings…

regards

Keith

[Keith]

Latest version now out with many fixes to MultiPartPaths (MPPs) plus other enhancements and fixes.

[Keith]

The MPP entry should be fixed now – certainly the bug with creating 2 point MPPs is, and several other issues while testing and running DRC checks on the results are. The MPP code now is SWIG wrapped – although I still have to write the documentation for this, but creating MPPs in Python is pretty straightforward.

DRC originally ignored MPPs completely, fixing this involved fixing several other bugs. Also the contact spacing algorithm has been improved so that as many contacts as possible are created for each MPP path segment, yet consistent with DRC rules.

There is still work to do on the MPP rules e.g to support multiple contacts along a path using an offset parameter to determine where they are relative to the path centreline. But this can wait until another release.

[Keith]

Hi Paco,

It's already done. I just need to add in another test, run the regression tests and then build on all platforms.

The windows port is already up there (I didn't yet update the version number on the web page).

Have fun!

regards

Keith

[Author]

Posts