[Keith]

Hi Paco,

Yes, it's a bit of pwell above the nwell.

(btw your saveDerived should explicitly label the pwell layer:

saveInterconnect( [
[pwell, "PWELL"],
nwell,

as ALL derived layers that you want to save must be saved to a declared layer – there is no need for original layers e.g. nwell, since we know their layer names from the geomGetShapes() function, however when a derived layer is formed, it has a python 'name', but this is no way the derived layer can find out what this is – its just a limitation of python itself.)

As far as I can see is is a sliver of pwell exactly 1um above the original nwell.

I'll take a look. The bounding boxes of the layout and extracted cell are the same, sosomething else is causing this… It's perhaps significant that the sliver is exactly 1.0um high…

regards

Keith

[Keith]

This marks the (official) end of the Red Hat 4 Linux version, so not there are RH5 and 6 versions.

It's still possible to compile RH4 versions if you're really desperate, but the last Qt version I could get to compile was Qt 4.8.0. And you really shoud be moving one…

Any problems with RH6, let me know.

– Keith

[Keith]

In 4.3.50 the parasitics below the filter value are removed completely from the resulting netlist. Also I have added the option to merge parasitics on net pairs into a single parasitic on the net pair (and filtering works on the merged caps too).

[Keith]

The good news is that this is fixed in 4.3.50. I've run through several examples and they all seem OK.

The slightly bad news is that for any designs with holes (e.g. where you have a guard ring in metal/diffusion enclosing many devices) then runtimes are longer. It may be possible to improve this, else using multithreaded extraction will help if you are running on a machine with several cores.

[Keith]

Hi Paco,

Hopefully it will be all solved by then and 4.3.50 will be released all with the fixes to extraction.

It also gives a bit more time for testing and QA, and some performance improvements to the connectivity extraction.

Have a nice vacation!

regards

Keith

[Keith]

Hi Paco,

Just an update, I have been able to solve all the problems with floating contacts, and also found some problems with text labelling that was giving some shorts. This has required quite a major re-write of the connectivity extraction to handle holes more rigorously.

Now there is just one remaining false short which I'm looking into. Not sure if this will be fixed this week – in which case it will have to wait until the beginning of August now – but let's see.

regards

Keith

[Keith]

OK #2 was in fact an easy fix, so those self-intersecting shapes are handled.

#1 needs more work…

[Keith]

Well the good news is that I know what the problem is. In fact there are several problems:

1. The first example fails geomConnect with shapes that are complex polygons with holes. The bad news is that this may be tricky to fix.

2. The second example has some problems with merging polygons which have self-intersection. In theory the code should handle this (geomGetShapes merges all input data by default), at least it works on other examples. Debugging this is tedious but given the simple nature of the shapes it should be possible to simplify it to a case that is not too bad.

It's possible that #2 is causing the problems with #1, but hard to say yet.

Stay tuned!

[Keith]

Hi Paco,

I have looked at this a bit more and the problem for the second case is that the input polygons on TestLib2 example2 are self-intersecting. Also, for some reason there are 2 identical polygons for each shape in this example, although I don't think that will cause problems.

I presume you created this using the Edit->Convert to Polygon function on a MPP? In which case this needs to be modified to avoid self-intersecting polygons.

regards
Keith

[Keith]

Hi Paco,

I think this is similar to a bug I fixed a way back on extraction that showed similar effects. There was a certain situation in which a contact would either not be recognised as overlapping a metal layer, or would be incorrectly found to overlap a shape on another net.

The two testcases I have for that still pass regression so this is something different but I suspect related. Thanks for the reduced testcase, this does help.

regards

Keith

[Keith]

Hi Paco,
If you can simplify it at all to a smaller example that still shows the problem, it will help debugging.
Regards,
Keith

[Keith]

Hi Paco,

There is something going wrong in extraction. I see in the logfile warning messages like:

# WARNING: Layer 6: Changing net from vdd to vcomm
# WARNING: Layer 6: Changing net from vss to vload
# WARNING: Layer 6: Changing net from vload to vinter
# WARNING: No text labels on layer METAL2 purpose net

which means that a labelled net is shorting to another labelled net. However running the net tracer on the original layout shows no problems.

The likely issue is that the extractor is thinking a contact is connecting between the nets when it shouldn't – I suspect it's an issue with MPPs again but will need to check.

I'll take a more detailed look when I'm back from vacation.

regards

Keith

[Keith]

…and fixed #1. Processing of MPPs in instances was incorrect.

Fix is be in 4.3.49, available now.

[Keith]

Found the problem with #2 (MPPs but no pcells) and fixed that. But the remaining one (#1 – MPPs and PCells) is proving a bit more tricky.

[Keith]

1. TestLib-example-layout = MPP and PCell example

Definitely something weird here. Most probably some missing transformation stuff.

2. TestLib-example_nopcell = same example without PCells

Yes something else weird here.

3. TestLib-example_nompp = same example without MPPs

Not sure what the problem is here. I get 84 offgrid errors, which are all due to contacts on a divice being off the 1.0um grid.

[Author]

Posts