connectivity check after p&R > Forums

Unanswered

Active Topics

Forums

Forums > Digital IC > Floorplanning, Place and route

Subject: connectivity check after p&R

Posting to forums is available to community members only.
Login or Register

Rate this topic:

Author

Messages

semicond
Posts: 7
Online: User is Offline

11/21/2005 11:20 AM
Hi; Thank you for the help. Since this is my first time to use encounter, I have many problems. When I am done with P&R and did connectivity check, I have connection problems with vdd and vss. I have already done the following. sroute -nets {vdd vss} but still have this problem. Can I check if this is a real problem? If so, how can I solve this problem? Thank you so much

mohanch007
Posts: 52
Online: User is Offline

11/21/2005 5:31 PM
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

semicond
Posts: 7
Online: User is Offline

11/21/2005 10:21 PM
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

mohanch007
Posts: 52
Online: User is Offline

11/21/2005 10:34 PM
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

semicond
Posts: 7
Online: User is Offline

11/23/2005 6:34 AM
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

semicond
Posts: 7
Online: User is Offline

11/28/2005 10:11 PM
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

mohanch007
Posts: 52
Online: User is Offline

11/28/2005 10:24 PM
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,

mohanch007
Posts: 52
Online: User is Offline

11/28/2005 10:48 PM
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

semicond
Posts: 7
Online: User is Offline

11/30/2005 8:52 AM
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?

umdcdn08
Posts: 3
Online: User is Offline

1/31/2007 12:02 PM
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.

lisiang
Moderator
Posts: 48
Online: User is Offline

1/31/2007 1:00 PM
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

umdcdn08
Posts: 3
Online: User is Offline

2/01/2007 12:53 PM
I am running First Encounter v06.10-p005_1 (7/2006) for Linux. I am using ARM 90nm wirebond for the I/O and want to do the power planning. I create the global power nets with: globalNetConnect VDD -type pgpin -pin VDD -inst * -override -verbose globalNetConnect VSS -type pgpin -pin VSS -inst * -override -verbose globalNetConnect VDD -type tiehi -inst * -override -verbose globalNetConnect VSS -type tielo -inst * -override -verbose Then I route the special nets and followpins with: sroute -noCorePins -noPadRings -noBlockPins -noStripes -jogControl { preferWithChanges differentLayer } -nets {VSS VDD} After this is complete, I run verify connectivity and get: Net VDD: unconnected terminal, special open, antenna. Net VSS: unconnected terminal, special open, antenna. I think it is because of this that I have problems routing the tie high/low pins because the entire VDD/VSS nets are open/unconnected. Am I missing something obvious?

lisiang
Moderator
Posts: 48
Online: User is Offline

2/01/2007 1:10 PM
not sure what you are trying to connect if you used "-noCorePins -noPadRings -noBlockPins -noStrips". If you just want to have only M1 follow pin then it is ok. With that, all the M1 follow pins are not connected since you told "sroute" not to connect them thru either padRing or Strips and you will have open VSS/VDD nets. li siang

umdcdn08
Posts: 3
Online: User is Offline

2/01/2007 2:39 PM
Sorry, the sroute command was one of a series from the script. Later it was called with: sroute -noPadRings -jogControl { preferWithChanges differentLayer } -nets { VSS VDD } I solved the problem, actually. I had several blocks with block rings and there were stripes that were routed very close to the block rings. The followpins were routing to the stripes and not the block rings causing the open net. By increasing the value of the -merge_stripes_value option for addStripe, stripes that are too close to the block rings will merge and the problem was solved. Thank you for your help.

Posting to forums is available to community members only.
Login or Register

Forums > Digital IC > Floorplanning, Place and route > connectivity check after p&R

ActiveForums 3.6