connectivity check after p&R

Hi,
Please check out this option before varifing for VC/VG.
Hope this will help you out.
Assigning power pins and power nets
Assigning power pins and power nets •
encounter> globalNetConnect VDD -type pgpin -pin VDD -inst *
encounter> globalNetConnect VSS -type pgpin -pin VSS -inst *
encounter> applyGlobalNets

USE :
Applies or restores the global net connectivity rules to the design and creates the necessary
connections between instances and these global nets.
(Or)
Example

The following command connects the specified component and pins to the global net:

connectToGlobalNet -tie_highs_lows 0 -to_global_net VDD -verbose 0 \
-override_prior_global_connection 0 -in_instances * -nets {} -pins VDD \
-connect Pins -under_module {} \

In this example, connectToGlobalNet connects all instances (*) in all modules with pins
VDD to the previously-defined global net VDD.

Reg,
Mohan

Hi;
Thanks for your reply
I put the following sentences in my script

globalNetConnect vdd -type pgpin -pin VDD -inst * -module {}
globalNetConnect vss -type pgpin -pin VSS -inst * -module {}
applyGlobalNets

connectToGlobalNet -tie_highs_lows 0 -to_global_net vdd -verbose 0 \
-override_prior_global_connection 0 -in_instances * -nets {} -pins VDD \
-connect Pins -under_module {}

connectToGlobalNet -tie_highs_lows 0 -to_global_net vss -verbose 0 \
-override_prior_global_connection 0 -in_instances * -nets {} -pins VSS \
-connect Pins -under_module {}


But, I still have the following message after the connectivity check

Net vss: unconnected terminal.

vdd has the similar problem.

Is this a real error? because due to the metal obstruction layers, there could be false DRC errors.

How can I resolve this problem?

Thank you so much

Hi,
I have few questions regarding your *.config file you are using .
-Have you defined right Power and ground names as applicable?In config file
- By physically have you checked out the locations (zoom).
- have you made sure about the rule section in lef file (if you treat as an false errors)
- You can ignore if reported as Terminal but not at pins.
- check the same after Physical placement.
Regards,
MOhan

Hi;
Here are my answers;
1. The names for power and ground is vdd and vss (Not VDD or VSS). But, as I described before, these nets are connected to VDD or VSS
2. I am not sure about positions. You mean the physical positions of power and ground?
I am feeding the power and ground with power and ground pads. I think these are OK
3. Actually, I understand that lef is supposed to be good because these are provided by the library company
4. Actually, it is reported as terminals.
Then, this is not a real error?
5. I checked. But I couldn't see any problems

Thank you so much

Hi;
The reason why I posted the question is that I have problems in LVS check.
I am using Calibre LVS.
Right after P&R, I generated netlist and gds files from first encounter. With these files, I did LVS. But, I have a lot of discrepancies. That's why I did the connectivity check after P&R and found it out that there was some problem with the connectivity especially with vdd and vss.
But you are saying that if this problems are with terminal, this is not a real problem in P&R tool. Then, all the LVS problems are associated with LVS step?
Is that right?

Thank you so much

Hi ,
Have you checked your top_svs.report file in calibre LVS. is it reporting to the corresponding power floating.
( check calibre rve)
I think better run Calibre ERC to identify if so for special nets.

Reg,

Hi,
Is your design bock or chip, and which technology??.
I was about to ask the encounter version you are using (4.1X).
If your setup for calibre is right and it reports as a violation it needs to be considered as a real violation.
Like as you know that sroute command has some swatches you need to select.
If you could not do so , then need manual work ( connecting using GUI)
I advice you to use the below command (but depends on you requirement)

like ex. :
# Sample power connection
sroute -noPadPins -noStripes \
-noCorePins \
-blockPinRouteWithPinWidth \
-noPadRings \
-jogControl { preferWithChanges differentLayer } \
-blockPin { boundaryPins } \
-extraConfig extra_mega.cfg \
-nets { vdd vss }
# extra_ub.cfg and extra_rl.cfg you
need to generate .

Thanks & regards

1. Hi; I checked out ERC rule. pwr/grd seems to be ok. There are some error reprots about NTAP and PTAP. I think this is all about the guardring. In addition, the lvs discrepancies are happening in some standard cells but not in other cells. But, when I took out the standard cells and did lvs only for the cells, there is no discrepancy. That's why I am so confusing.

2. Hi mohan;
encounter version : v04.10-s219-1
technology : umc 130nm
I think the lvs error is not about the power or ground. There are some extra ports in layout. But, when I looked into the ERC reports, there are no short connection. In addition, when I did lvs only about the standard cell, there is no discrepancy at all. Mentor is saying that there must be some connectivity problems in top level.
Based on the encounter connectivity check, only vss and vdd terminals seem to be unconnected. There are no connectivity problems.

I checked lvs options and ports. I think there is no problem.

Mohan : Do you think it is possible that encounter could make a wrong layout connections which can be different from the netlist that it generates?

semicond,

did you find a solution to the unconnected terminal problem in your design?  i am getting the same error from the verify connectivity check in Encounter. 

if those open are related to tie high/low, you might want to re-run routing again using "globalDetailRouteBatch". Aslo check for any warning message in the log file to see if you have any "bad net". One other thing, you are using soc41 (which might have some bugs in there) and you should try to upgrade to SOC61usr2.   You should talk to your AE if you are still having problem.

li siang