Forum Replies Created
-
Posts
-
You should be able to. Either when you import a techfile, specify database units/micron as 1000000, or if just importing a GDS with database units of 1e-12, make sure you have set the 'Set library dbu/UU from GDS' checkbox.
Edit: just checking the code, it will set any gds with database units less than 1nm to 1nm. I guess this could be changed (a warning will still be given though).
This version fixes a serious bug that seems to have existed for quite a time in that when importing DEF, certain segments of the nets could get dropped.
OK, it is actually quite trivial to fix the selection box issue.
Non-rotated labels are currently just that – there is no distinction between the handling of rotated and mirrored ones. That will be a task for another day…
Tricky. Ignoring rotation is easy, coming up with scenarios about what rotation is allowed and what is not is harder.
The selection box stuff is more complex still – the label has a bounding box depending on its orientation and 'size'. Changing this do depend on what the current displayed cell options are will need some far-reaching changes.
I wonder whether its worth what will be a complex implementation for a cosmetic feature?
#1 is probably quite easy to implement. Handling all the orientation/presentation options of GDS2 is a real pain.
#2 – on which level? Show only labels on the top level, if all levels are displayed?
#3 – in non-OpenGL mode, 'real' fonts are used. They have the downside of being rather slow. In OpenGL mode, vector fonts are used, which I agree are not pretty but are very very fast.
There is a small bug in the code that reads properties when opening a library – if the property is boolean, it causes all other properties to be skipped. I'll fix this.
The duplicated class property will not give any errors as far as I can tell.
If the core_hd cell has a layout view created for it, that's because it must exist in the gds2 you imported.
About the other things you mention, I will need to check.
The message
CellAreas and totalCellWidth are 0
looks suspicious. I'd check if the tmp.def looks OK – maybe therre are no cells to place, or maybe there are no rows to place them in. Hard to say but something's wrong with it.
The placer has crashed, but its impossible to tell why just from the logfile. If you can send the tmp.lef/tmp.def it may be possible to find out why.
Detail routing requires a multilayer maze router, which for simple design rules is not rocket science, but it was never a design goal for Glade. If you hear of any publically available ones with a LEF/DEF interface let us know, as interfacing would be simple.
The 'Create Rows' combo box is filled according to the following rule:
– the view name must be 'site'
– there must be a boolean property for the site cellView called 'site'
During Import LEF, any site definitions in the LEF result in a cell with name according to the site name, and the view name/cellview property as above.
However, you shouldn't have a 'layout' view for the site, maybe this is causing the problem?
Well some good news and some bad.
Create Rows needs to find a valid site in order to know the row geometry. A site is normally defined in your lef file(s) as e.g.
SITE core
SIZE 0.14 BY 1.26 ;
CLASS CORE ;
SYMMETRY Y ;
END coreHowever… Glade is not a P&R tool. True is does read LEF/DEF etc and has a link to the Capo placer and also has a (rather primitive) global router, but it does not have a detail router (i.e. the part that produces the actual wiring between cells). In effect you can do some floorplanning and that's it. Sorry.
