hi,

we are observing shorts over macro edges due to high pin density. but we have are observing channels which we gave is not fully utilized.

is there any settings to to fix shorts over macros with high priority? in Synopsys tool we have some settings to fix macro over shorts with high priority, like that do we have any special settings in innovus.

currenlty we are working on 6nm where pins are in the middle of SRAMs. please let us know if you have any special settings even if it degrades timing also ok for some extent.

Thanks & Regards,

PraveenKumar.

Hello,

I am trying to migrate my digital synthesis flow from Encounter (v12.00-p002_1) to Innovus (v19.14-s105_1) by updating the script that used to work with Encounter. After replacing the commands that become obsolete in Innovus (mainly updating CTS to the ccopt flow), I was able to let the flow run except for a hold time issue. Every time I use "optDesign -hold" to try to fix hold time issue, I get the following:

    -> "1 net: Could not be fixed as the net is considered as IPO ignored by the process".

This causes a lot of hold violation to be ignored. This happens no matter at which stage I invoke the "optDesign -hold" command, and I am testing this on a simple scan chain design. I did not face this issue before with Encounter.

I would appreciate any help on solving this issue, please.

Many thanks in advance!

Cadence tool versions:

- Virtuoso: sub-version  IC6.1.8-64b.500.11

- Encounter/Timing: v12.00-p002_1

- Innovus: v19.14-s105_1

Kindest Regards,

Nader Fathy

Hi all,

I am doing some digital implemtation staff. I used Innovus to do PnR, and export the layout using GDS format to virtuoso. 

Problem: All the label layers imported to Virtuoso appear to be drawing layers. As you can see in the figure below:

My thoughts: The mapping file for exporting Innovus layout to GDS format have some problems. Some layer definations(data type?) have errors. The thing is that I don't know how to modify the stream data types in mapping file, and I don't know how to map the purposes in the map file(such as NET, SPNET, PIN, etc.) to the technology file provided by my vendor.

Some additional information: I am using TSMC 0.18um GP technology. My map file and stream layer information are shown below:

========StreamUut Mapping File========

CONT PIN 15 0
CONT LEFPIN 15 0
CONT FILL 15 0
CONT FILLOPC 15 0
CONT VIA 15 0
CONT VIAFILL 15 0
CONT VIAFILLOPC 15 0
METAL1 NET 16 0
METAL1 SPNET 16 0
METAL1 PIN 16 0
METAL1 LEFPIN 16 0
METAL1 FILL 16 0
METAL1 FILLOPC 16 0
METAL1 VIA 16 0
METAL1 VIAFILL 16 0
METAL1 VIAFILLOPC 16 0
METAL1 LEFOBS 16 0
NAME METAL1/NET 16 0
NAME METAL1/SPNET 16 0
NAME METAL1/PIN 16 0
NAME METAL1/LEFPIN 16 0
VIA12 PIN 17 0
VIA12 LEFPIN 17 0
VIA12 FILL 17 0
VIA12 FILLOPC 17 0
VIA12 VIA 17 0
VIA12 VIAFILL 17 0
VIA12 VIAFILLOPC 17 0
METAL2 NET 18 0
METAL2 SPNET 18 0
METAL2 PIN 18 0
METAL2 LEFPIN 18 0
METAL2 FILL 18 0
METAL2 FILLOPC 18 0
METAL2 VIA 18 0
METAL2 VIAFILL 18 0
METAL2 VIAFILLOPC 18 0
METAL2 LEFOBS 18 0
NAME METAL2/NET 18 0
NAME METAL2/SPNET 18 0
NAME METAL2/PIN 18 0
NAME METAL2/LEFPIN 18 0
VIA23 PIN 27 0
VIA23 LEFPIN 27 0
VIA23 FILL 27 0
VIA23 FILLOPC 27 0
VIA23 VIA 27 0
VIA23 VIAFILL 27 0
VIA23 VIAFILLOPC 27 0
METAL3 NET 28 0
METAL3 SPNET 28 0
METAL3 PIN 28 0
METAL3 LEFPIN 28 0
METAL3 FILL 28 0
METAL3 FILLOPC 28 0
METAL3 VIA 28 0
METAL3 VIAFILL 28 0
METAL3 VIAFILLOPC 28 0
METAL3 LEFOBS 28 0
NAME METAL3/NET 28 0
NAME METAL3/SPNET 28 0
NAME METAL3/PIN 28 0
NAME METAL3/LEFPIN 28 0
VIA34 PIN 29 0
VIA34 LEFPIN 29 0
VIA34 FILL 29 0
VIA34 FILLOPC 29 0
VIA34 VIA 29 0
VIA34 VIAFILL 29 0
VIA34 VIAFILLOPC 29 0
METAL4 NET 31 0
METAL4 SPNET 31 0
METAL4 PIN 31 0
METAL4 LEFPIN 31 0
METAL4 FILL 31 0
METAL4 FILLOPC 31 0
METAL4 VIA 31 0
METAL4 VIAFILL 31 0
METAL4 VIAFILLOPC 31 0
METAL4 LEFOBS 31 0
NAME METAL4/NET 31 0
NAME METAL4/SPNET 31 0
NAME METAL4/PIN 31 0
NAME METAL4/LEFPIN 31 0
VIA45 PIN 32 0
VIA45 LEFPIN 32 0
VIA45 FILL 32 0
VIA45 FILLOPC 32 0
VIA45 VIA 32 0
VIA45 VIAFILL 32 0
VIA45 VIAFILLOPC 32 0
METAL5 NET 33 0
METAL5 SPNET 33 0
METAL5 PIN 33 0
METAL5 LEFPIN 33 0
METAL5 FILL 33 0
METAL5 FILLOPC 33 0
METAL5 VIA 33 0
METAL5 VIAFILL 33 0
METAL5 VIAFILLOPC 33 0
METAL5 LEFOBS 33 0
NAME METAL5/NET 33 0
NAME METAL5/SPNET 33 0
NAME METAL5/PIN 33 0
NAME METAL5/LEFPIN 33 0
VIA56 PIN 39 0
VIA56 LEFPIN 39 0
VIA56 FILL 39 0
VIA56 FILLOPC 39 0
VIA56 VIA 39 0
VIA56 VIAFILL 39 0
VIA56 VIAFILLOPC 39 0
METAL6 NET 38 0
METAL6 SPNET 38 0
METAL6 PIN 38 0
METAL6 LEFPIN 38 0
METAL6 FILL 38 0
METAL6 FILLOPC 38 0
METAL6 VIA 38 0
METAL6 VIAFILL 38 0
METAL6 VIAFILLOPC 38 0
METAL6 LEFOBS 38 0
NAME METAL6/NET 38 0
NAME METAL6/SPNET 38 0
NAME METAL6/PIN 38 0
NAME METAL6/LEFPIN 38 0
NAME COMP 220 0
COMP ALL 221 0
DIEAREA ALL 222 0

===================================

===========.tf stream layer file===

streamLayers(
;( layer streamNumber dataType translate )
;( ----- ------------ -------- --------- )
( ("ref" "drawing") 0 0 t )
( ("PWELL" "drawing") 1 0 t )
( ("NWELL" "drawing") 2 0 t )
( ("NWELL" "pin") 2 6 t )
( ("DIFF" "drawing") 3 0 t )
( ("DIFF" "dummy") 3 1 t )
( ("DIFF" "drain") 3 3 t )
( ("DIFF" "pin") 3 6 t )
( ("OD2" "drawing") 4 0 t )
( ("N3V" "drawing") 5 0 t )
( ("PIMP" "drawing") 7 0 t )
( ("NIMP" "drawing") 8 0 t )
( ("EPLY" "drawing") 9 0 t )
( ("BPLY" "drawing") 10 0 t )
( ("PDIFF" "drawing") 11 0 t )
( ("NDIFF" "drawing") 12 0 t )
( ("POLY1" "drawing") 13 0 t )
( ("POLY1" "dummy") 13 1 t )
( ("POLY2" "drawing") 14 0 t )
( ("CONT" "drawing") 15 0 t )
( ("METAL1" "drawing") 16 0 t )
( ("METAL1" "dummy") 16 1 t )
( ("METAL1" "slot") 16 2 t )
( ("METAL1" "BSL") 16 100 t )
( ("METAL1" "BSD") 16 101 t )
( ("VIA12" "drawing") 17 0 t )
( ("METAL2" "drawing") 18 0 t )
( ("METAL2" "dummy") 18 1 t )
( ("METAL2" "slot") 18 2 t )
( ("PAD" "drawing") 19 0 t )
( ("PAD" "BSL") 19 100 t )
( ("BPI" "drawing") 20 0 t )
( ("VIA67" "drawing") 21 0 nil )
( ("METAL7" "drawing") 22 0 nil )
( ("METAL7" "dummy") 22 1 nil )
( ("METAL7" "slot") 22 2 nil )
( ("VTM_P" "drawing") 23 0 t )
( ("VTM_N" "drawing") 24 0 t )
( ("VTDP" "drawing") 25 0 t )
( ("VTDN" "drawing") 26 0 t )
( ("VIA23" "drawing") 27 0 t )
( ("METAL3" "drawing") 28 0 t )
( ("METAL3" "dummy") 28 1 t )
( ("METAL3" "slot") 28 2 t )
( ("ESD" "drawing") 30 0 t )
( ("VIA34" "drawing") 29 0 t )
( ("METAL4" "drawing") 31 0 t )
( ("METAL4" "dummy") 31 1 t )
( ("METAL4" "slot") 31 2 t )
( ("VIA45" "drawing") 32 0 t )
( ("METAL5" "drawing") 33 0 t )
( ("METAL5" "dummy") 33 1 t )
( ("METAL5" "slot") 33 2 t )
( ("RPO" "drawing") 34 0 t )
( ("P2V" "drawing") 35 0 t )
( ("PTDIODE" "drawing") 37 0 t )

( ("METAL6" "drawing") 38 0 t )
( ("METAL6" "dummy") 38 1 t )
( ("METAL6" "slot") 38 2 t )
( ("VIA56" "drawing") 39 0 t )

( ("METAL1" "pin") 40 0 t )
( ("METAL1" "BSP") 40 100 t )
( ("METAL2" "pin") 41 0 t )
( ("METAL3" "pin") 42 0 t )

( ("METAL4" "pin") 43 0 t )
( ("DMEXCL" "dummy4") 150 4 t )
( ("SLTEXCL" "dummy4") 158 4 t )
( ("METAL5" "pin") 44 0 t )
( ("DMEXCL" "dummy5") 150 5 t )
( ("SLTEXCL" "dummy5") 158 5 t )
( ("METAL6" "pin") 45 0 t )
( ("DMEXCL" "dummy6") 150 6 t )
( ("SLTEXCL" "dummy6") 158 6 t )
( ("METAL7" "pin") 46 0 nil )
( ("DMEXCL" "dummy7") 150 7 nil )
( ("SLTEXCL" "dummy7") 158 7 nil )
( ("POLY1" "pin") 47 0 t )
( ("POLY1" "lvs") 47 1 t )
( ("HRI" "drawing") 48 0 t )
( ("BJTDUMMY" "drawing") 49 0 t )
( ("PSUB2" "drawing") 50 0 t )
( ("HOTWL" "drawing") 51 0 t )
( ("RWDUMMY" "drawing") 52 0 t )
( ("RWDUMMY" "drawing1") 52 1 t )
( ("VCDUMMY" "drawing") 53 0 t )
( ("RPDUMMY" "drawing") 54 0 t )
( ("RPDUMMY" "drawing1") 54 1 t )
( ("HVPRDMY" "drawing") 54 2 t )
( ("RP4TDUMMY" "drawing") 54 3 t )
( ("EXCL" "drawing") 55 0 t )
( ("DIODUMMY" "drawing") 56 0 t )
( ("SDI" "drawing") 58 0 t )
( ("TEXT" "drawing") 59 0 t )
( ("DRCDUMMY" "drawing") 60 0 t )
( ("N2V" "drawing") 61 0 t )
( ("prBoundary" "drawing") 62 0 t )
( ("marker" "error") 63 0 t )
( ("LMARK" "drawing") 63 1 t )
( ("LW" "drawing") 63 2 t )
( ("IP" "drawing") 63 63 t )
( ("marker" "warning") 64 0 t )
( ("DPDUMMY" "drawing") 65 0 t )
( ("PLDUMMY" "drawing") 66 0 t )
( ("CTM2" "drawing") 67 2 t )
( ("CTM3" "drawing") 67 3 t )
( ("CTM4" "drawing") 67 4 t )
( ("CTM5" "drawing") 67 5 t )
( ("CDUMMY" "drawing") 68 0 t )
( ("RMDUMMY" "drawing") 69 0 t )
( ("RMDUMMY" "drawing1") 69 1 t )
( ("RMDUMMY" "drawing2") 69 2 t )
( ("RMDUMMY" "drawing3") 69 3 t )
( ("RMDUMMY" "drawing4") 69 4 t )
( ("RMDUMMY" "drawing5") 69 5 t )
( ("RMDUMMY" "drawing6") 69 6 t )
( ("CELLIMP" "drawing") 70 0 t )
( ("PV_P" "drawing") 71 0 t )
( ("PV_N" "drawing") 72 0 t )
( ("BASE_N" "drawing") 250 1 t )
; ( ("BTC" "drawing") 73 0 t )
; ( ("VCC" "drawing") 74 0 t )
( ("RODUMMY" "drawing") 75 0 t )
; ( ("ESEXCL" "drawing") 76 0 t )
; ( ("CPDUMMY" "drawing") 77 0 t )
( ("PDIMP" "drawing") 78 0 t )
( ("PUIMP" "drawing") 79 0 t )
( ("CELLBRC1" "drawing") 80 0 t )
( ("BLBRC2" "drawing") 81 0 t )
( ("DNW" "drawing") 82 0 t )
( ("P1W" "drawing") 83 0 t )
( ("P1R" "drawing") 84 0 t )
( ("SAC" "drawing") 85 0 t )
( ("C1" "drawing") 86 0 t )
( ("C2" "drawing") 87 0 t )
( ("DPITCH" "drawing") 88 0 t )
( ("PLMIDE" "drawing") 89 0 t )
( ("1TDMY" "drawing") 90 0 t )
( ("HNVT" "drawing") 91 0 t )
( ("PO1" "drawing") 92 0 t )
( ("FLASH" "drawing") 94 0 t )
( ("FGT" "drawing") 96 0 t )
( ("HVII" "drawing") 97 0 t )
( ("HVNW" "drawing") 99 0 t )
( ("FLASH" "LLNW") 100 0 t )
( ("FLASH" "ODLL") 101 0 t )
( ("WELLBODY" "drawing") 103 0 t )
( ("MICO" "drawing") 106 0 t )
( ("VICO" "drawing") 107 0 t )
( ("OVERLAP" "drawing") 110 0 t )
( ("MTPCELL" "drawing") 115 0 t )
( ("PSUB" "drawing") 116 0 t )
( ("MCEL" "drawing") 122 0 t )
( ("SEALRING" "drawing") 126 0 t )
( ("LDDMY" "drawing") 127 0 t )
( ("CASDMY" "drawing") 127 1 t )
( ("ULLNW" "drawing") 128 0 t )
( ("ULLNLDD" "drawing") 128 1 t )
( ("NTN" "drawing") 129 0 t )
( ("DRC2DUMMY" "drawing") 130 0 t )
( ("CTMDUMMY" "drawing") 131 0 t )
( ("CTMDUMMY" "drawing2") 131 10 t )
( ("CTMDUMMY" "drawing3") 131 15 t )
( ("CTMDUMMY" "drawing4") 131 20 t )
( ("CTMDUMMY" "drawing1") 131 21 t )
( ("RHDUMMY" "drawing") 132 0 t )
( ("IMSOR" "CELLMV") 133 0 t )
( ("IMSOR" "CELLH") 133 1 t )
( ("IMSOR" "NPS") 133 2 t )
( ("IMSOR" "PL") 133 3 t )
( ("IMSOR" "GM") 133 4 t )
( ("IMSOR" "RM") 133 5 t )
( ("IMSOR" "BM") 133 6 t )
( ("IMSOR" "ML") 133 7 t )
( ("IMSOR" "PPS") 133 8 t )
( ("IMSOR" "NMOS_VT") 133 9 t )
( ("IMSOR" "CI") 133 10 t )
( ("IMSOR" "CIRPO") 133 11 t )
( ("IMSOR" "GM1") 133 12 t )
( ("IMSOR" "GM2") 133 13 t )
( ("IMSOR" "CELLD") 133 14 t )
( ("IMSOR" "MS") 133 15 t )
( ("IMSOR" "LS") 133 16 t )
( ("IMSOR" "YM") 133 17 t )
( ("IMSOR" "CM") 133 18 t )
( ("IMSOR" "MM") 133 19 t )
( ("IMSOR" "E_ML") 133 20 t )
( ("IMSOR" "BGP") 133 21 t )
( ("IMSOR" "BGN") 133 22 t )
( ("IMSOR" "CELL_TX") 133 23 t )
( ("IMSOR" "CELL_RS") 133 24 t )
( ("IMSOR" "CAP_IMP") 133 25 t )
( ("IMSOR" "CELL_TX2") 133 26 t )
( ("IMSOR" "MP") 133 27 t )
( ("IMSOR" "DPW") 133 28 t )
( ("IMSOR" "CF3D") 133 29 t )
( ("IMSOR" "SEL") 133 30 t )
( ("IMSOR" "FLD") 133 31 t )
( ("IMSOR" "NPS2") 133 32 t )
( ("RLPPDUMMY" "drawing") 134 0 t )
( ("NOOPC" "drawing") 135 0 t )
( ("ESD1DUMMY" "drawing") 136 0 t )
( ("ESD2DUMMY" "drawing") 137 0 t )
( ("VARDUMMY" "drawing") 138 0 t )
( ("VARDUMMY" "drawing1") 138 1 t )
( ("VARDUMMY" "drawing2") 138 2 t )
( ("VARDUMMY" "drawing3") 138 3 t )
( ("VARDUMMY" "drawing4") 138 4 t )
( ("INDDUMMY" "drawing") 139 0 t )
( ("INDDUMMY" "drawing1") 139 1 t )
( ("P3V" "drawing") 140 0 t )
( ("HV" "SH_P") 141 1 t )
( ("HV" "SH_N") 141 2 t )
( ("HV" "SH_PO") 141 3 t )
( ("HV" "HVIO") 141 4 t )
( ("HV" "OW") 141 5 t )
( ("HV" "DMYLD") 141 31 t )
( ("HV" "LDPW") 141 32 t )
( ("HV" "PDD") 141 49 t )
( ("HV" "NDD") 141 50 t )
( ("HV" "DPW") 141 51 t )
( ("HVDMY" "drawing") 141 52 t )
( ("PA24DMY" "drawing") 141 60 t )
( ("NLD24DMY" "drawing") 141 61 t )
( ("RS3TDMY" "drawing") 141 62 t )
( ("NLVT" "drawing") 141 63 t )
( ("HVTN" "drawing") 142 0 t )
( ("HVTP" "drawing") 143 0 t )
( ("SBDDMY" "drawing") 144 0 t )
( ("SGDUMMY" "SBDDMY") 144 1 t )
( ("MOMDMY" "drawing") 145 0 t )
( ("MOMDMY" "drawing1") 145 1 t )
( ("MOMDMY" "drawing2") 145 2 t )
( ("MOMDMY" "drawing3") 145 3 t )
( ("MOMDMY" "drawing4") 145 4 t )
( ("MOMDMY" "drawing5") 145 5 t )
( ("MOMDMY" "drawing6") 145 6 t )
( ("VIAEXCL" "dummy1") 146 1 t )
( ("VIAEXCL" "dummy2") 146 2 t )
( ("VIAEXCL" "dummy3") 146 3 t )
( ("VIAEXCL" "dummy4") 146 4 t )
( ("VIAEXCL" "dummy5") 146 5 t )
( ("VIAEXCL" "dummy6") 146 6 t )
( ("VIAEXCL" "dummy7") 146 7 t )
( ("VIAEXCL" "dummyf") 146 15 t )
( ("CODEP" "drawing") 148 0 t )
( ("DMP2V" "drawing") 149 0 t )
( ("DMEXCL" "dummy1") 150 1 t )
( ("DMEXCL" "dummy2") 150 2 t )
( ("DMEXCL" "dummy3") 150 3 t )
( ("DMEXCL" "dummyf") 150 15 t )
( ("ODBLK" "dummy") 150 20 t )
( ("POBLK" "dummy") 150 21 t )
( ("METAL1" "boundary") 151 0 t )
( ("METAL2" "boundary") 152 0 t )
( ("METAL3" "boundary") 153 0 t )
( ("METAL4" "boundary") 154 0 t )
( ("METAL5" "boundary") 155 0 t )
( ("METAL6" "boundary") 156 0 t )
( ("METAL7" "boundary") 157 0 t )
( ("SLTEXCL" "dummy1") 158 1 t )
( ("SLTEXCL" "dummy2") 158 2 t )
( ("SLTEXCL" "dummy3") 158 3 t )
( ("MD" "pin") 159 0 t )
( ("RFDUMMY" "drawing") 160 0 t )
( ("RFDUMMY" "drawing1") 160 1 t )
( ("RFDUMMY" "drawing2") 160 2 t )
( ("VIA12" "boundary") 161 0 t )
( ("VIA23" "boundary") 162 0 t )
( ("VIA34" "boundary") 163 0 t )
( ("VIA45" "boundary") 164 0 t )
( ("VIA56" "boundary") 165 0 t )
( ("VIA67" "boundary") 166 0 t )
( ("VIAD" "drawing") 167 0 t )
( ("MD" "drawing") 168 0 t )
( ("MD" "dummy") 168 1 t )
( ("MD" "slot") 168 2 t )
( ("CBD" "drawing") 169 0 t )
( ("CBD" "BSL") 169 100 t )
( ("UBM" "drawing") 170 0 t )
( ("UBM" "BSL") 170 100 t )
( ("CB2" "drawing") 177 0 t )
( ("CB2" "BSL") 177 100 t )
( ("LOGO" "drawing") 178 0 t )
( ("NBL" "drawing") 179 0 t )
( ("HVOX" "drawing") 180 0 t )
( ("WBDMY" "drawing") 183 0 t )
( ("DMN2V" "drawing") 184 0 t )
( ("CODEC" "drawing") 185 0 t )
( ("PSDMY" "drawing") 187 0 t )
( ("RV" "drawing") 188 0 t )
( ("RV" "BSL") 188 100 t )
( ("PPI" "drawing") 189 0 t )
( ("AP" "drawing") 189 1 t )
( ("AP" "BSL") 189 100 t )
( ("AP" "pin") 189 101 t )
( ("AP" "BSP") 189 102 t )
( ("ZERO_VTP" "drawing") 196 0 t )
( ("LEVEL" "drawing") 200 1 t )
( ("PBL" "drawing") 200 2 t )
( ("PPLG" "drawing") 200 3 t )
( ("NDN" "drawing") 200 4 t )
( ("NLV" "drawing") 200 5 t )
( ("BSOX" "drawing") 200 6 t )
( ("PXBA" "drawing") 200 7 t )
( ("NXBA" "drawing") 200 8 t )
( ("PEMO" "drawing") 200 9 t )
( ("PSIC" "drawing") 200 10 t )
( ("PLV" "drawing") 200 11 t )
( ("NEM" "drawing") 200 12 t )
( ("PEM" "drawing") 200 13 t )
( ("UBM" "pin") 207 1 t )
( ("LVGDMY" "drawing") 209 1 t )
( ("SRAM" "dummy1") 231 1 t )
( ("SRAM" "dummy2") 231 2 t )
( ("SRAM" "dummy3") 231 3 t )
( ("ESD3DUMMY" "drawing") 234 0 t )
( ("FW" "drawing") 235 0 t )
( ("PMDMY" "drawing") 236 0 t )
( ("OTP" "drawing") 237 0 t )
( ("HVPSW" "drawing") 241 0 t )
( ("TSV" "drawing") 251 0 t )
( ("TSV" "pin") 251 1 t )
( ("TSV" "dummy") 251 2 t )
( ("TSV_CB" "drawing") 252 0 t )
( ("TSV_PPI" "drawing") 253 0 t )
( ("TSV_PPI" "pin") 253 1 t )
( ("LUPWDMY" "drawing") 255 1 t )
( ("FFCDMY" "drawing") 255 2 t )
( ("CONT" "boundary") 0 0 nil )
( ("CONT" "net") 0 0 nil )
( ("METAL1" "net") 0 0 nil )
( ("METAL2" "net") 0 0 nil )
( ("METAL3" "net") 0 0 nil )
( ("METAL4" "net") 0 0 nil )
( ("METAL5" "net") 0 0 nil )
( ("METAL6" "net") 0 0 nil )
( ("METAL7" "net") 0 0 nil )
( ("VIA12" "net") 0 0 nil )
( ("VIA23" "net") 0 0 nil )
( ("VIA34" "net") 0 0 nil )
( ("VIA45" "net") 0 0 nil )
( ("VIA56" "net") 0 0 nil )
( ("VIA67" "net") 0 0 nil )
( ("boundary" "drawing") 0 0 nil )
) ;streamLayers

===========================

Thanks in advance.

Best,

OrangeHalo

Hello,

I am currently using Innovus to build a hierarchical design where the levels of hierarchy can range from 2 to 6/7. I'm having some issues right now getting the -extractBlockObs flag to work for the write_lef_abstract command. It does not seem to want to pull the obstruction information from my lower level LEF(s). I verified that they are marked as CLASS BLOCK. Any suggestions?

Also, on a side note, is there any way for write_lef_abstract to extract VIA information? This would be extremely useful in my current flow, but I have been unable to get this to work as of now.

Hey everyone,

First off, any help would be greatly appreciated and thank you to anyone who does respond.

I have a large design that uses a single VDD and VSS throughout, except for a single small portion that needs to be supplied by a separate power source.  The portion includes about 45 standard cells and a memory macro that will need their power pins attached to a different power supply that is given by a single pad's signal.  I have found some documentation on voltage islands, but I haven't been able to discern exactly how to apply it to my very simple design.  If you have done this or know how to, please HELP.

thanks

Hello,

I am seeing:
"**ERROR: (IMPLF-1000): Illegal value found for -design_boundary option."
when trying to use the -design_boundary flag with write_lef_abstract. The man page simply says to use a point list, which I have tried different methods of creating listed below:
as a string ("x0 y0 x1 y1")
as a string in a list ("{x0 y0 x1 y1}")
as the [dbGet top.fplan.boxes] returns ("{{x0 y0 x1 y1}}")
as a polygon-esque list of points ("{{x0 y0} {x0 y1} {x1 y1} {x1 y0}}")
And none of these have worked for me. Can someone please give me insight as to what a point list should look like?

Hi,

 In my design I have two power pins: VDD and VDD1 and two ground pins: VSS and VSS1.

While running static power how can i set the names and voltages of the different  power and ground pins??

Thanks and regards

     Varun M J

Hello Team,
Tool: Innovus 19.10 and 19.12
Running FEF PostMask and can successfully complete an ECO change, except for one tedious task: fixing or removing little Special Route metals labeled at ecoDefIn.

I am seeing a difference in how DefIn and ecoDefIn read in a def file. And this issue is making the deleting of nets incomplete and results in tiny metal blockages.
For example:  A section of the def file has the net segments (connection information) and an additional section of added metal shown below.

...

- FE_OFN54_FE_OFN0_compare_n
  + RECT METAL2 ( 25450 46000 ) ( 25850 46700 )
  + RECT METAL2 ( 26350 750970 ) ( 26750 751600 )
  + RECT METAL2 ( 30850 750970 ) ( 31250 751600 )
  + RECT METAL2 ( 31680 674460 ) ( 32220 675140 )
  + RECT METAL2 ( 53350 735700 ) ( 53750 736400 )
...

If I read in the def file with defIn the added rect metal2 are treated as object-type "Patch Wire" routed.  I am able to select net from any point along the net and highlight all the interconnect and via (including these added rect metal2).
However, when I use the ecoDefIn the rect metal2 in the same section are set differently.  They have object-type "Special Route" routed and Shape "None".  With this setting, when I click on a net, all segments of the net are selected except for these rect metal2 section.  

The ecoRoute will attempt to delete nets and reconnect based on the eco netlist, but with small blockages located either along the original net position or over a pin, these rect metal2 become blockages.  Note that each of these metal2 shapes have a original net name.  

1) I'm not sure why defIn and ecoDefIn handle these added rect metal differently.  Has anyone experienced this?

2) Any idea on how I can I select all of these Object-Type "Special Route" metal pieces to change them to Patch Wire or delete them.  (I believe these were added during Antenna Fixing and/or associated with connection to original instance pin via12 contacts. There are >800 of these rect metal shapes )

The original design was DRC/Connectivity/Geometry clean, and the issue comes forward only when ecoDefIn for ECO.  Manual ECO edits using defIn doesn't leave behind the Patch Wires.  
Also, in ecoDefIn flow, DRC/Connectivity/Geometry checks can identify these metal shapes in Violation Browser.  However, I don't have a way to select them as a group to apply a change (or delete).

Any thoughts on how to handle this?

I have no issue connecting my VDD and VSS (pwr/gnd) to my macros and std cells, but in this current iteration of my design, I have a SRAM and 45 std cells that I need to connect to a different power source.  The issue is that the power source, called VDD2 is an input from one of the I/O pads.  Every time I use

globalNetConnect VDD2 -pin VDD -type pigpen -inst "instance path/*" -override

but when I run sroute with just the area I fenced these cells into after placing rings and stripes, the VDD pin in the SRAM still only wants to connect to VDD, my global VDD and not the signal power source VBATT I am trying to attach it to.  Any help would be appreciated.

Hi,

there is a way to know why INNOVUS optDesign -postroure is not able to solve a max_tran violation ?

Hi everyone,
I have a very simple RC circuit made on Simulink and I would like to import it on PSpice so I should use the DMI to interface Simulink and PSpice. I used this link as a guide www.pspice.com/.../device-model-interface but I can't understand where the COPY.txt file comes from in the PWMContol model.Also, I wondered if there were other examples available as guidelines.

Thanks for the replies.

Hello,

I am building a clock tree with multiple generated clocks and would like to define different insertion delay for each skew group for an optimized balancing, how is this possible using CCOpt?

Another question, if the insertion delay of the main clock is larger than its period, is it  ok? if not, does simply delaying the data input solve the problem?

Thank you!

Dear all,

I have saved a synthesized design in genus using the write_design -basename basename -innovus and when I import the design into innovus I see that it has not connected some output ports. When invoking the schematic viewer in innovus several warnings appear related to those ports: WARN: (IMPSGN-2007) Failed to open Port  XXXXX. I have checked the verilog generated by genus and looks correct and furthermore Genus reads in he file correctly. I do not have any clue on what can be happening. Do you know what can be the problem?

Thanks in advance,

Luis.

Hi,

I am following a RAK Analog on Top (AoT) Mixed Signal Design Flow Using Virtuoso Analog and Innovus Digital Platforms: Rapid Adoption Kit (RAK) and the licenses required are: Virtuoso GXL, Innovus (or Innovus Basic), INVS100 or INVS95 , Innovus_Hier, INVS40 , Innovus_Mixed_Signal, INVS 30.

By runing lmstat I can verify that i have all the above licenses and specifically:
Feature                         Version     #licenses    Vendor        Expires
Virtuoso_Layout_Suite_GXL 6.18 240 cdslmd 31-dec-2020
Innovus_Hier_Opt 19.1 10 cdslmd 31-dec-2020
Innovus_Impl_System 19.1 10 cdslmd 31-dec-2020
Innovus_MS_Opt 19.1 10 cdslmd 31-dec-2020

However, while running innovus plug-in from Virtuoso I get an Error Virtuoso_Digital_Implem lecense checkout failed.

I can't find license Virtuoso_Digital_Implem but given that I have all the necessary licenses, shouldn't I be able to run the whole RAK.

Can I set virtuoso asking for license Innovus_MS_Opt  instead of Virtuoso_Digital_Implem?

Hi All,

How can I set a proper value for max_transition during PnR in Innovus ? Even if I use following commands (during MMMC analysis / OCV mode), Innovus seems to take the max_transition from the fast cell library (.lib) which I find too tight for lower frequencies. 

set_interactive_constraint_modes [all_constraint_modes -active]
set_max_transition 1.5 ${DESIGN_NAME} //1.5 in ns

Is there a way this can be done in the tool without touching library data ?

Thanks

Hello everyone. I tried to add a symbol of a battery holder. I had downloaded the footprint and STEP model. I've noticed that pins in that footprint were defined as mechanical, so I had to replace them by electrical ones. I created a symbol in my library, added 3 pins and when I try to synchronize schematics with layout, I receive such an error.

Cannot find primitive part for primitive instance: @MAIN_MODULE.MAIN_MODULE(SCH_1):INS600246@BATTERY_HOLDERS.WA-BCMC_79523141.NORMAL(CHIPS).

The footprint and the schematic symbol seem to be ok, but I can't upload my project because of the error given above. How can I solve it?

Both footprint and padstacks are located in respective directories.

Hi All,

When I using the innovus to synthesis the clock tree using the following command:

create_ccopt_clock_tree_spec -filename ccopt.spec

source ccopt.spec

ccopt_design -cts

I found the errors shown below:

**ERROR: (IMPCCOPT-3092): Couldn't load external LP solver library. Error returned:
libCDSCoinUtils.so: cannot open shared object file: No such file or directory
libCoinUtils.so: cannot open shared object file: No such file or directory
libCDSClp.so: cannot open shared object file: No such file or directory
libClp.so: cannot open shared object file: No such file or directory.
Failed to load LP libraries; retrying...
[07/10 10:35:19 73s] **ERROR: (IMPCCOPT-3092): Couldn't load external LP solver library. Error returned:
libCDSCoinUtils.so: cannot open shared object file: No such file or directory
libCoinUtils.so: cannot open shared object file: No such file or directory
libCDSClp.so: cannot open shared object file: No such file or directory
libClp.so: cannot open shared object file: No such file or directory.
Failed to load LP libraries; retrying...
[07/10 10:35:20 73s] **ERROR: (IMPCCOPT-3092): Couldn't load external LP solver library. Error returned:
libCDSCoinUtils.so: cannot open shared object file: No such file or directory
libCoinUtils.so: cannot open shared object file: No such file or directory
libCDSClp.so: cannot open shared object file: No such file or directory
libClp.so: cannot open shared object file: No such file or directory.
Unable to load LP libraries

It seems that some important library is missing.

The version I am using is Innovus v17.11-s080_1 (64bit) under centos 6.9

Could anyone meet similar problems before and have some solutions?

Best regards,

Hello,

Recently I find that in Genus is supporting function of declaration different clocking domains. Instead using clock groups and than add them as asynchronous, domains seems to ignore all cross-domain relations as well as skipping timing analysis path between them.

So what's the pure advantage of declaration of clock domains? I can set falsepath between clocking groups as well. And any kind of Cadences OTPG we don't use so all features are unable for us.

Also it's pretty strange to find using any kind clock domain settings most in Legacy IU (which I believe become too old for using).

What is the reason that power/ground ports that are added in the physical implementation flow have direction "inout" instead of "input"?  Is there a way to force them to be "input" instead without running some post-processing code?

a simple example is starting with something like this out of synthesis:

module mycell(A, Y);

    input A;

    output Y;

    INVX1 myinst(.A (A), .Y (Y));

endmodule

Then using things like this in the physical place/route:

set init_pwr_net "VDD"
set init_gnd_net "VSS"

globalNetConnect VSS -type pgpin -pin VSS -all
globalNetConnect VDD -type pgpin -pin VDD -all

and ending up with

module mycell(A, Y, VDD, VSS);

    input A;

    output Y;

    inout VDD;  // WHY INOUT

    inout VSS;  // WHY INOUT

    INVX1 myinst(.A (A), .Y (Y), .VDD(VDD), .VSS(VSS));

endmodule

The reason I care is in mixed signal sims (AMS) or even DMS sims, I want to avoid any possibility of bi-directional connect modules whenever possible.  To that end, I'd like to be able to simulate the post-physical design (that includes power/ground) but with those defined as "input" instead of "inout".