@Adi Teman Could you show how to add labels for Power/Ground IO in innovus? In my design, Power/Ground IO are created by innovus command as physical only, so there is no terminal/ports for them. I used to use "LAYOUT TEXT" to add label, or add label in Calibredrv GUI. I am quiet cuirios about how to add in innovus.
Hi Jieyan, This is a bit odd, since in general, when you create a global net, there is usually a toplevel pin that is created for this in Innovus. In fact, this raises some concern if you don't see such a port in Innovus and you don't see an appropriate label on the GDS. That being said, there are a few manual ways to add pins and the best way to find the updated way (since these commands tend to be tweaked) is on Cadence Support (or in the manuals, such as the text command reference). For example, recent versions of Innovus have a "create_hport" command that should take care of this, but I must say that I haven't yet tried it out. The previous way was with the "create_hpin" command with a "-" option (just a dash with nothing else...) and then connecting the net to some module or net. If you have a global power net, I think it would work to supplement this with "connect_hpin - -pin_name VDD -net VDD" for example. Another option you should know is to write out a text file with the names of the toplevel pins. The legacy command was genPinText.
Hi Grannyw777, Sorry for the (very) later reply. I actually hadn't been dealing with this for quite a while and couldn't pull an answer out off the top of my head, but I've just finished running LVS on a complex chip and now I can give you a reliable answer. The "hcells" file is a way to tell the LVS tool where to maintain hierarchy - kind of similar to "don't ungroup" in synthesis. If you define a hierarchy as an hcell, it will keep that hierarchy during extraction, such that a .SUBCKT of that module/instance will appear in the extracted (layout) netlist. Otherwise, there is a good chance it will be flattened and you won't be able to recognize that specific hierarchical name or find it in the netlist. This can help debug (from experience - it is a lifesaver). Then, during comparison, the hierarchies defined in the hcells file will be compared standalone and show if there were discrepancies at their level. In other words, the tool will report that a lower level block did not pass LVS. This has two uses: 1) It can tell you that whoever provided this block didn't pass LVS or if it is not an IP, it can point to where an error may be occuring. 2) If the block does pass standalone LVS, it can tell you that something is screwed up in its connection to the toplevel. Again, these kinds of "hints" can focus you towards the problem and help you find it. Otherwise, you may be lost. Note that you can also "blackbox" an hcell and the tool will report to you if the connections to it are correct without checking the content of the block.
@Adi Teman Could you show how to add labels for Power/Ground IO in innovus? In my design, Power/Ground IO are created by innovus command as physical only, so there is no terminal/ports for them. I used to use "LAYOUT TEXT" to add label, or add label in Calibredrv GUI. I am quiet cuirios about how to add in innovus.
Hi Jieyan,
This is a bit odd, since in general, when you create a global net, there is usually a toplevel pin that is created for this in Innovus. In fact, this raises some concern if you don't see such a port in Innovus and you don't see an appropriate label on the GDS.
That being said, there are a few manual ways to add pins and the best way to find the updated way (since these commands tend to be tweaked) is on Cadence Support (or in the manuals, such as the text command reference). For example, recent versions of Innovus have a "create_hport" command that should take care of this, but I must say that I haven't yet tried it out. The previous way was with the "create_hpin" command with a "-" option (just a dash with nothing else...) and then connecting the net to some module or net. If you have a global power net, I think it would work to supplement this with "connect_hpin - -pin_name VDD -net VDD" for example.
Another option you should know is to write out a text file with the names of the toplevel pins. The legacy command was genPinText.
hcells, could you please elaborate on that?
Hi Grannyw777,
Sorry for the (very) later reply. I actually hadn't been dealing with this for quite a while and couldn't pull an answer out off the top of my head, but I've just finished running LVS on a complex chip and now I can give you a reliable answer.
The "hcells" file is a way to tell the LVS tool where to maintain hierarchy - kind of similar to "don't ungroup" in synthesis. If you define a hierarchy as an hcell, it will keep that hierarchy during extraction, such that a .SUBCKT of that module/instance will appear in the extracted (layout) netlist. Otherwise, there is a good chance it will be flattened and you won't be able to recognize that specific hierarchical name or find it in the netlist. This can help debug (from experience - it is a lifesaver).
Then, during comparison, the hierarchies defined in the hcells file will be compared standalone and show if there were discrepancies at their level. In other words, the tool will report that a lower level block did not pass LVS. This has two uses:
1) It can tell you that whoever provided this block didn't pass LVS or if it is not an IP, it can point to where an error may be occuring.
2) If the block does pass standalone LVS, it can tell you that something is screwed up in its connection to the toplevel.
Again, these kinds of "hints" can focus you towards the problem and help you find it. Otherwise, you may be lost.
Note that you can also "blackbox" an hcell and the tool will report to you if the connections to it are correct without checking the content of the block.
@@AdiTeman Hey Adi, thanks for elaborate explanation!