[SOLVED] Uncomplete RC network

Hi guys,
When running the RC extraction with Encounter at the end of the PnR flow, I get the following messages:

**ERROR: (ENCEXT-3423): Detected 2 nets with incomplete RC network. Low-value resistances have been added by the software to complete the RC network of these nets. Review the list of affected nets in the 'ctrl_top.rc_typ.incomplete_res.net' file to ensure they are not along the critical path because results of timing analysis performed on nets with incomplete RC network can be inaccurate.

This happens only on 2 nets, that have nothing special from a design point of view.
Looking at the man of (ENCEXT-3423), this appears because the resistance for the given nets is not found in the SPEF.

But I am kind of stuck in tracing back the root cause of this problem.

Would you have hint about where to look?

Thanks!

brunope said:

Hi guys,
When running the RC extraction with Encounter at the end of the PnR flow, I get the following messages:

**ERROR: (ENCEXT-3423): Detected 2 nets with incomplete RC network. Low-value resistances have been added by the software to complete the RC network of these nets. Review the list of affected nets in the 'ctrl_top.rc_typ.incomplete_res.net' file to ensure they are not along the critical path because results of timing analysis performed on nets with incomplete RC network can be inaccurate.

This happens only on 2 nets, that have nothing special from a design point of view.
Looking at the man of (ENCEXT-3423), this appears because the resistance for the given nets is not found in the SPEF.

But I am kind of stuck in tracing back the root cause of this problem.

Would you have hint about where to look?

Thanks!

Click to expand...

this happens when routing fails to complete

ThisIsNotSam said:

this happens when routing fails to complete

Click to expand...

Thanks for your comment,

I ran a connectivity check, and it reports no Error... How can I check this problem after routing?

Thanks

brunope said:

Thanks for your comment,

I ran a connectivity check, and it reports no Error... How can I check this problem after routing?

Thanks

Click to expand...

read the execution log of the routing step

ThisIsNotSam said:

read the execution log of the routing step

Click to expand...

Thanks for this advice.That's what I did and I can't find anything relevant. I'll dig further there...Thanks

the connectivity check does not show problems because - read the warning message - the tool (most likely - extraction tool) placed artificial "connector" resistors to make net's R network connected.
These connectors have very small resistance (like 1 mOhm), and connect arbitrary nodes of disconnected R groups.
Since these nodes are arbitrary - you can easily get problem (timing, IR drop, current density,...).

Did you check file ctrl_top.rc_typ.incomplete_res.net'?
Can you show its content?

You can open and review SPEF file, or use some tools or write a script to analyze it, to find the connector resistors, and see if this poses a problem or not.

This can happen if net is not connected, or if a bug in extraction tool creates disconnected R network for connected net.
This problem is well known for one of the industry standard extraction tools, and it reports a warning, but does not help detect and debug where this connector resistor is placed and to judge whether this is critical or not.

- - - Updated - - -

By the way - what parasitic extraction tool is used in your flow?

Hi Timof,
Thanks for your message.

So if I get your point correctly, the rc extract is fixing the rc network, and therefore, the connectivity check does not report any Error. Is it correct? Should I then run the connectivity check after the routing but before the RC extract.

I checked the ctrl_top.rc_typ.incomplete_res.net,the content is :

# The following nets have got the unconnected resistances fixed
max_cnt_AI[2]
gen_ctrl_slices[0].ctrl_slice_x/n_11

max_cnt_AI[2] is a bit of a bus, all the other bits of the bus are (apparently) fine.
gen_ctrl_slices[0].ctrl_slice_x/n_11 is the net on the Z of a buffer whose input is max_cnt_AI[2].
So the 2 points are affecting the same path.

I a using the foundation flow from cadence, which invokes extractrc command in the scripts. I don't know if this is helpful enough.

Thanks!

Not exactly.
Extraction tool generates RC network, and if it sees that R network is not connected, for a net - it will add "connector" resistors.
There is also a small chance, that disconnected R network is due to layout - either a mistake, leading to a net not being connected, or a design with disconnected net (that may be connecting outside the cell, at the upper hierarchy level).

If you can, you should run connectivity analysis based on layout (polygons), and compare that with connectivity of extracted R network.

The header of post-layout netlist (SPEF or DSPF file) should tell the name of the vendor (EDA company) and the tool - let us know what they are.
I think Encounter may have its own extraction engine, different from the standard extraction tools.
What you can do, to debug this problem, is to run the extraction using a standard extraction tool, and see if problem persists.

You can identify the connector resistances by their small value (like 1 mOhm or 10 mOhm or so), if you inspect parasitic resistors section in the problematic net section of SPEF file.

What I normally was doing in such cases, is visualize parasitic resistors on top of the layout, locate the "connector" resistor, and see if disconnected R network is valid or not.
"Not valid" means the polygons in the layout are all connected, for that net, but resistors do not form a connected graph.

You can check layout connectivity in Virtuoso editor or in Calibredrv, these tools have such functionality.
I guess the routing tool should also have such functionality, but I am not that familiar with P&R tools and flows.

Hi timof,
Tanks for taking hte tme to explain this in detail.

What I get in the SPEF header is :

*VENDOR "Cadence Design Systems, Inc."
*PROGRAM "Encounter"
*VERSION "14.28-s033_1"

I'm reporting this point to the guy taking care of the integration of this digital block in Virtuoso.

This is on a non critical path, so I don't care about timing here. But I do care about functionality.

If there is a real connectivity problem,can it be caught by LVS in Virtuoso?

Thanks again!

brunope said:

Hi timof,
Tanks for taking hte tme to explain this in detail.

What I get in the SPEF header is :

*VENDOR "Cadence Design Systems, Inc."
*PROGRAM "Encounter"
*VERSION "14.28-s033_1"

I'm reporting this point to the guy taking care of the integration of this digital block in Virtuoso.

This is on a non critical path, so I don't care about timing here. But I do care about functionality.

If there is a real connectivity problem,can it be caught by LVS in Virtuoso?

Thanks again!

Click to expand...

Two points I have to make: if you are using Cadence-only flow, you generally trust the spef to be correct. The tool handles all of that for you, you don't even know that there is a spef file being used under the hood.

Now the fact that this file seems to wrong is probably because of some design mistake. Do a visual inspection on the nets, see if they are actually connected post route.

Second point is that yes, LVS would catch this connectivity issue very easily, if there is one, of course.

brunope said:

Hi timof,
Tanks for taking hte tme to explain this in detail.

What I get in the SPEF header is :

*VENDOR "Cadence Design Systems, Inc."
*PROGRAM "Encounter"
*VERSION "14.28-s033_1"

I'm reporting this point to the guy taking care of the integration of this digital block in Virtuoso.

This is on a non critical path, so I don't care about timing here. But I do care about functionality.

If there is a real connectivity problem,can it be caught by LVS in Virtuoso?

Thanks again!

Click to expand...

I think this SPEF file is generated by an extraction tool built-in into Encounter system, I think it's different from QRC.

I have seen situations when extraction tool created these connector resistors that can be safely ignored, but also seen other cases where such shorts between arbitrary nodes on disconnected R network groups (belonging to the same, connected net) was completely destroying the topology of the R network, distorting IR drop results and EM results.
So, I would suggest to sort this out, to be on the safe side.

If this is a real connectivity issue, yes, it may be detected in Virtuoso or in Calibre/LVS.
Also, in extraction tool, there should be settings to whether short disconnected parts of a net, or not.
But if the layout is fine, from connectivity viewpoint, and it is the extraction tool that behaves incorrectly - then Virtuoso and LVS would not help you, they will just confirm it is extraction tool problem.

If you are in a big and important (from EDA vendor mentality viewpoint) company - you can ask your EDA tool vendor (Cadence in this case) to help you resolve this issue.

Did you look inside SPEF file and see this connector resistor, in the problematic nets?
Also, did you have a chance to do the extraction with your standard extraction tool, to see if the problem would show up there as well?

One more place when such problem (connector / low value resistors) can happen, is if you do"hierarchical" extraction, by black-boxing some cells, and if these cells have a "large-area" (or "wide") connection at multiple points to the upper hierarchy layout - there may be shorts inserted by the extraction tool, to simplify connectivity of the cell (p-cell or black-boxed cell) to the top level cell. And this may cause big problems sometimes as well...

- - - Updated - - -

ThisIsNotSam said:

Two points I have to make: if you are using Cadence-only flow, you generally trust the spef to be correct. The tool handles all of that for you, you don't even know that there is a spef file being used under the hood.

Click to expand...

The keyword here is "generally".
Yes, most of the time it works correctly, and you do not need to look inside.
But, sometimes it does not work correctly (tool bug, PDK bug, design issue, violation of extraction algorithms' assumptions, ...) - then you are taking chances...
The more you know about the intrinsics (of the extraction), the less confidence you have that "everything is correct".
And this becomes increasingly important in advanced nodes (16/14nm and below), where parasitics (resistance especially) become a first order effect.

Sure, generally is the keyword.

OP, I still think your design has something odd that you should be able to visually inspect and rule out. If that is not the case, make sure to use the Encounter/Innovus version that is certified for the technology you are using. Without knowing much, I can tell you that your Encounter version is quite old.

Hi guys, sorry for the delay.

To keep you posted, yes, you were right, my design has problems. We were facing congestion problems, and the gds generated had plenty of problems.
We enlarged slightly the floorplan, and all the Errors are gone.

Indeed, Encounter is not very recent (2014), but the project I work on is on an old technology, (older than 2014).

Thanks all again for your help and for things I learnt !

brunope -

thanks for the update.

It's useful to know how your problem was resolved, just enlarging the floorplan.

This "plenty of problems" - how did you find about them? Did router give you some hints, or did you find out only from errors from downstream tools (extraction in this case)?

So, to complete the explanation:
-there were also some shorts on the gds, and looking at the routing, we could see that it was because of lack of routing space (we are using only few metals, and a lot of routing blockages for analog signals.
By enlarging the floorplan, everything got fixed.
Since the block size was not so critical, we haven't investigated further, and we went with the enlargement. I guess that it used to work in the first versions of the design, and went wrong during the phases of features adding (more digital content and more analog blockages).

A good lesson learnt...

Thanks all for your useful questions, comments, advices and support.

Good stuff

brunope -

thanks for these additional details.

Shorts in GDS layout problem should have been identified, captured, and resolved before proceeding to extraction, I think...

I would like to see more this sort of "stories from the trenches" - this is what takes years for people to learn, and you cannot pick this up from the literature, from the theory...