[Keith]

Hi Paco,

I've already added an option for (a) since it seemed quite useful anyhow. (b) will take a little more time, but probably won't get done before I am on vacation.

regards

Keith

[Keith]

Right, a bit more detail from investigations last night:

1. The negative areas came from those poly gate shapes. Internally 'holes' in polygons are represented by sets of clockwise edges, as opposed to normal polygons which are sets of counterclockwise edges. So the area calculation gives negative values for the holes….

We could just ignore processing the holes, but then the reported capacitance of these poly gates would be too high. So the 'recognition region' i.e. the poly shape is smashed to trapezoids before reporting the capacitance. This has 2 side effects – firstly a lot more caps are reported and secondly the runtime is a bit slower.

It might be desirable to have the export CDL function (a) ignore caps below a certain value of (b) find all parasitic caps between pairs of nets and merge them into a single cap.

2. The missing capacitances problem has been fixed.

I've put patched versions of win32/64 and ubuntu 64 on the weebsite, the other platforms to follow.

[Keith]

Hi Paco,

From a very quick look:

1. The negative numbers come from the capacitance of the poly gates to some lower layer. Your poly gates are complex shapes with holes in them. I suspect the area calculation in extractDeviceN is a bit simplistic (it's similar to the one in your cnm25poly.py pcell) and getting this wrong. But this needs verifying.

2. I'm not sure you need to extract all these caps. For example extracting m1 to pdiff is only really going to be relevant if you are having metal1 running over e.g. pdiff resistors. Normally metal1 will be contacted to pdiff over transistors i.e. shorted.

3. Metal2 to Metal1 caps seem to be missing in the extracted view, this needs to be investigated.

I'll keep you updated,

regards

Keith

[Keith]

Hi Paco,

4.3.48 is ready for download on win32/64 and Ubuntu 64 bit. Rest to follow.

regards

Keith

[Keith]

I managed to fix this one. You can now pan with middle mouse drag during e.g. a move or copy command and the move will work as expected i.e. the outline of the object is not affected by the pan.

Will be in 4.3.48.

[Keith]

Hi Paco,

I completed the extract with intervening layers last night. The syntax is

extractParasitic3(lowerLayer, upperLayer, areaCap, perimCap, [layer1, …. layerN])

it basically does:

upperLayer AND NOT layer1 AND NOT layer2 etc

Currently there is no intelligent checking to see if layer1-N are sensible layers i.e. metal layers between the lower and upper layer.

I've also fixed the Export CDL issue so that parasitic caps are always reported with values rather than modelname.

This will be in 4.3.48 later this week.

[Keith]

Hi Paco,

Yes, this probably needs fixing too. There are several other areas to tidy up too. Hopefully I can have something ready by the end of the week (I am on vacation 13th-20th and 26th-3rd).

regards

Keith

[Keith]

OK I fixed the bug with naming layers in saveInterconnect. It now extracts all parasitic caps correctly.

Next job is to check how to do the layer processing to avoid e.g. M4 to M2 parasitics where there is intervening m3…

[Keith]

Hi Paco,

2 problems I see with the extract file:

1. you load the cnm25modn pcell twice, I think you need to change one to cnm25modp. This is not affecting the parasitic cap extraction though.

2. You don't need to save non-derived layers with a layer name in saveInterconnect. You should use:

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

I think actually this is a bug in saveInterconnect because it *should* be OK the way you did it, but for some reason is doesn't…

You also need to write the pwell to an existing techfile layer (create one called 'pwell') else you will get the same problem trying to extract caps to this layer.

I'll see if I can fix this bug (I can see where it's going wrong).

regards

Keith

[Keith]

It's much easier to scale the image in Glade to what you need, dump a screenshot and put this in a document rather than trying to write out a SVG file – which could be HUGE.

Does anyone else in the EDA world dump SVG files?

[Keith]

Using the MMB to pan was never intended to work within an active command. It may be possible to get it to work, but for the present I suggest avoiding it as it does not work as expected.

[Keith]

Hi Paco,

This requires some detailed thought. I was aware of this issue when the extractParasitic/extractParasitic2 code was implemented. There is no elegant solution. There are several messy ones, which I'd like to avoid if possible, so it will require time to consider the correct action.

Actually, although as you mention you need to have a geomConnect() before a saveDerived() or any extract…() commands, there is nothing to stop you putting layer processing commands *after* geomConnect. I've not had time to check it, but e.g. geomAndNot() ought to pass on net info to its output. However, there may be side effects of doing this.

regards

Keith

[Keith]

Hi Paco,

It's easy to print to PDF or Postscript format just by changing QPrinter's outputFormat property and giving a filename. The output still looks a bitmap to me though, as you zoom into the PDF you see diagonal lines eventually as pixels. SVG drawing looks a bit more complex, but I haven't had time to read the docs fully.

regards

Keith

[Keith]

Hi Paco,

It's a bug. They should be flattenned by geomGetShapes() but are not. I should be able to fix by next week.

Also Edit->Convert to Polygon could flatten them as now done for MPPs.

regards

Keith

[Keith]

Hi Paco,

At present when printing, a QImage is grabbed from the screen and this is printed. I'll have to look at the Qt docs to see what's involved in printing – or dumping graphics – to another format.

regards

Keith

[Author]

Posts