Forum Replies Created
-
Posts
-
This appears to be a known Fedora bug:
Are you exporting both regular nets and special nets? If you query the path and select the net tab, does it have instance pins? Also did you create the path using the 'net' purpose?
I tried it on an example here and it seems to work for me – if you want to add a path to an existing net, select the net, then click on 'Create Path'. It will automatically assign the net to the path. There's currently a bug in that the created path width / extent is equal to the existing selected track's width times the database usnits/micron, so you'll need to change it in the 'Create Path' dialog.
Not a lot to go on here, however I do see one thing – you are running the Mesa implementation of OpenGL. This is a software implementation and performance is likely to be poor. It would be better to set the env var GLADE_USE_OPENGL to NO to turn off OpenGL in this case.
The 'import site' error usually occurs if you have not got Python set up correctly – check your PYTHONDIR / PYTHONPATH.
As to the _IceTransSocketUNIXConnect error, this has something to do with session management (try googling it). Check that you have permission to display on a remote host (xhost cmd).
No plans for a Mac port – I'd need a Mac Qt license (I only have a dual Windows / X11 one) plus suitable hardware. As Glade is free yet not open source this is unlikely to happen. Sorry.
Strange it works fine for me if I load the example.tch techfile, open a new cell, and create a via. You do have vias defined in your library?
Not clear what the problem is, however I do see something strange in the library you are opening – the error about the inst master not found. That is not normal and indicates there is invalid data in the saved library.
You could also try setting the env var 'GLADE_NO_EXCEPTION_HANDLER' to 'YES', it will crash rather than handling the exception, but it may give more info.
This could be done, also the field could be made editable so you can type in the name rather than search for it. I'll put it in the enhancements list.
Are you running OpenGL? To check, look at the log file. If you see any messages about OpenGL Vendor / OpenGL Version etc. then you are.
There aren't, but I will try and put something together. Currently the extraction code is preliminary and only MOS devices have really been tested – the generic extractDevice command needs testing and/or bug fixes. Also general device parameter measurement is not implemented yet.
What's wrong with your top cell? I suspect you have something else wrong, but its hard to say what. Its possible you deleted something else at the same time?
This will not corrupt the GDS2 data you exported. Basically you have a polygon in the database with 0 vertices (actually the code flags any polygon with less than 3 vertices as an error). There will be no polygon written to the GDS2 file, so the output GDS2 is not corrupted.
The real question is how you managed to create a polygon with 0 vertices in the first place?
