[Keith]

Hi Francesc,

Sorry I missed seeing this yesterday. I'll take a look.

regards

Keith

[Keith]

Hi Paco,

If you open an existing layout created before the fix, the bounding box of the cell will be the same. So I would expect this behaviour.

As mentioned before, you should be able to reset it by opening the layout view, then typing the following Python commands:

cv = getEditCellView()

cv.updateBbox()

and then it should reset the bounding box to the true value – at least it did for me

regards

Keith

[Keith]

Hi Paco,

This, and a few other minor bugfixes, has been put in 4.3.54.

regards

Keith

[Keith]

Hi Paco,

'endl' by definition writes a 'n' and flushes the output stream (there is an argument for not using it and writing 'n' directly).

I am not sure if it's worth having the system output in two different file formats depending on platform.

regards

keith

[Keith]

Hi Paco,

By 'Windows applications', do you mean Notepad, which can't display this correctly, or Wordpad, which can (or better still gvim)?

I use a QTextStream to write lines, followed by an 'endl', which writes a 'n'. I don't think you can tell it to write out a different line ending.

regards

Keith

[Keith]

Hi Paco,

I've managed to devise an algorithm for the path bounding box that is still fast (i.e. doesn't convert the path to a polygon) yet gives more accurate results for manhattan paths, i.e. truncate paths are handled correctly.

For diagonal or any angle paths the convert to polygon option should probably be used – hopefully the speed impact will be small as no-one is going to use non-manhattan paths in large numbers on real designs.

regards

Keith

[Keith]

Hi Paco,

I will look into changing the path bounding box calculation to be more accurate. It's not good to restrict the path style, in general a halfwidth extension should be the default, but many people do not like this.

I don't believe anyone uses the varExtend capability (start extent can differ from end extents. There is no realistic use for this in IC design; really only truncate and extend mode are ever used. The GDS2 option of round ended paths is not applicable for IC design although it might ve useful for PCBs. The LEF/DEF styles extension is probably more useful, although it is not widely supported.

regards

Keith

regards

Keith

[Keith]

Hi Paco,

Hmm that's tricky.

To calculate the exact bounding box of a path with either truncate, extend or varextend styles may be be slow. And since the bounding box is used to locate the path in the spatial tree, that will slow everything down.

At present the bounding box of a path is just the centre line coords, plus half the path width. Figuring out whether the start and stop edges of the path begin/end on edges of that box and not inflating it, well I am open to suggestions for a fast algorithm to do that!

regards

Keith

[Keith]

Other thing to check is that you have removed all your .pyc files as these will be used instead of any .py file…. when I did this on Ubuntu, it worked correctly.

[Keith]

Odd. It seems to be different under Windows than Linux.

Note I did change the capacitor pcell code from dbReplaceProp to dbAddProp, as the property 'type' needs to be created in the pcell submaster – not replaced.

regards

Keith

[Keith]

Hi Paco,

I uploaded it a couple of hours ago. You won't see any obvious indication that it's changed alas, as it involved only a couple of lines change in the extractDevice reporter code. If you are having problems it may be your browser is caching downloads… happens to a few people including me!

regards

Keith

[Keith]

Hi Paco,

New builds are up now.

regards

Keith

[Keith]

Hi Paco,

is it caused by the fact that extractDevice() is setting the 'type' property *after* your pcell submaster is built.

I've changed the code now, so that if a 'type' property already exists on the pcell submaster, then extractDevice will not try and change it based on the device name.

As it's a very minor change, I will put it into the 4.3.53 build and let you know when it is ready for (re)downloading.

regards

Keith

[Keith]

Hi Paco,

In the extraction code I use:

subMaster->dbAddProp("type", "cap");

i.e. I am just adding the property to the submaster, so it should work… I don't think I have an example lib with an instance of the capacitor to test it on, though.

regards

Keith

[Keith]

Hi Paco,

It looks at the model name you give it and takes the first character as being the device type, according to the SPICE convention, and sets the 'type' property accordingly.

i.e. "C" or "c" -> "cap"
"R" or "r" -> "res"
"M" or "m" -> "mos"
"D" or "d' -> diode
"L" or "l" -> "ind"
"J" or "j" -> "fet"
"Q" or "q" -> "bip"

Anything else just sets the type to 'dev'. Of cource you can override this by (re) setting the "type" property.

regards

Keith

[Author]

Posts