Stats

  • Locked Locked
  • Replies 1
  • Subscribers 91
  • Views 17873
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Innovus DefIn and ecoDefIn handling of metal shapes differently.

RTP MikeM

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?

  • Let me update based on my understanding and after some additional reading: 

    In Innovus I found these to items in the documentation-

    **WARN: (IMPDF-1008): The routing has wire-patches (that requires DEF 5.8 NETS RECT statements) in the signal routing that cannot be represented correctly in DEF 5.6 or 5.7. They will be converted to SPECIALNETS routing RECT shapes instead. This output is suitable for RC extraction tools, but this DEF should not be read back into Innovus as the routing data will not be correct. You should use DEF 5.8 to represent this routing data correctly by using "set dbgLefDefOutVersion 5.8".

    **WARN: (IMPDF-1018): The routing has wire-patches (that require DEF 5.8 NETS RECT statements) in the signal routing that cannot be represented in DEF 5.5. They will be lost and the routing data will be incomplete with missing shapes, because there is no DEF 5.5 syntax that can correctly represent them. You should use DEF 5.8 to represent this routing data correctly by using "set dbgLefDefOutVersion 5.8".

    Note: if your PDK does not support def 5.8, then the NETS RECT (shapes) will not be added when you DEFIN to Virtuoso layout.  In this case, write out your def as usual (ie 5.7 or 5.6) for Virtuoso; but include a defOut in v5.8 which can then be read back by innovus for ECO at a later time.

    1) The difference of why the defIn and ecoDefIn:  ... I believe is just how the tool targets nets when reading a def file (in Innovus).  The ecoDefIn doesn't know how to handle special route nets (when the database is output with <def 5.8).
         In other words, if I "set dbgLefDefOutVersion 5.8" and  then "defOut -floorplan -netlist -routing mydesign_def5p8.def"  and read this def 5.8 version file back in with  "ecoDefIn -postMask -reportFile ecoDefIn.rpt mydesign_def5p8.def", the Innovus tool correctly knows the special route RECT are part of the net.

         a.) Restore original design if a defOut version 5.8 is not available.   And "set dbgLefDefOutVersion 5.8" and "defOut -floorplan -netlist -routing mydesign_def5p8.def"

         b.) ECO Flow:   follow eco template and make sure the ecoDefIn points to the defOut version 5.8.   "ecoDefIn -postMask -reportFile ecoDefIn.rpt mydesign_def5p8.def"

    2) There is an old post somewhere in the Cadence Forum about running DRC or GEOMETRY to get the target markers on the violations.  The script they presented takes the marker data and selects the target shapes.   I'll try that at some point... but my solution above worked to resolve the Innovus ecoDefIn issues. so I no longer have any rect metal hanging around causing blockages or drc/geo issues.

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.