• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Custom IC Design
  3. Spectre: Possible to avoid "dangling node" removal when...

Stats

  • Locked Locked
  • Replies 2
  • Subscribers 125
  • Views 4524
  • 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

Spectre: Possible to avoid "dangling node" removal when using "deepprobe" elements?

dontpanic
dontpanic over 9 years ago

Hello! Is there any way I can tell spectre not to remove some dangling nodes in my circuit? I would like to keep some dangling nodes that I connect to "deepprobe" elements for observability purposes, as explained below.

I am trying to use deepprobe components to "alias" internal nodes in my circuit hierarchy to names that won't change depending on which views I use for the internal modules (e.g. schematic or extracted), so that I can use them later in calculator expressions and/or the waveform viewer. For example, if I simulate my DUT with only schematic views for every block, then the following node exists:

DUT.module1.submodule1.voltageA

However, if I simulate with the extracted view of submodule1, then the proper way to access that same node becomes:

DUT.module1.submodule1_voltageA

Furthermore, if I use the extracted view of the whole module1, in the netlist this node becomes:

DUT.module1_submodule1_voltageA

And so on. So my attempted solution is to use in the topmost schematic (i.e. my testbench) a modified deepprobe element with 3 CDF parameters where I can put these 3 different hierarchical node names,  and use a netlisting procedure that generates the following entries in the netlist:

MYPROBE1_1   (DUT.module1.submodule1.voltageA     my_alias_name_for_this_node)    iprobe
MYPROBE1_2   (DUT.module1.submodule1_voltageA    my_alias_name_for_this_node)    iprobe
MYPROBE1_2   (DUT.module1_submodule1_voltageA   my_alias_name_for_this_node)    iprobe

This works fine since in any given simulation only 1 of the entries will correspond to an actual existing node, so the other 2 result in "iprobe" instances with one dangling node, and are therefore removed by the simulator.

The problem is that since the deepprobes are actually connected to nothing (in the schematic I just connect them to wires with the desired alias names and terminate these to  "noConn" elements to avoid floating node warnings), upon simulation spectre detects that these nodes are dangling, removes them, and as a consequence I cannot access to these signals!

In case it's not possible to make spectre keep the dangling nodes, I guess the only alternative would be to load the dangling nodes with some dummy element, but since I have lots of these probes in my (already heavy) testbench, I would like to do this in a way that will complicate the netlist as little as possible and/or that would minimize the possibility to create convergence problems. If I add a small cap I think I will add more nodes to the circuit; if I add a small conductance I would probably want it to set this to whatever the "gmin" simulator value is set, but I don't know how to do this.

Thanks in advance for any ideas on how to best overcome this problem!

Cheers,

Jorge.



  • Cancel
  • Andrew Beckett
    Andrew Beckett over 9 years ago

    Hi Jorge,

    If you save the node then it shouldn't get removed - so I think you should be able to get your netlisting procedure to just write:

    save my_alias_name_for_this_node

    as well...

    This is without any testing whatsoever, but I think it should work. Explicitly saving should prevent dangling node removal, I believe.

    Regards,

    Andrew.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • dontpanic
    dontpanic over 9 years ago
    Thanks for your reply, Andrew; it was totally my bad this time!

    Turns out I had a bug in my code that was preventing the right hierarchical names to be generated, so the save statements, even though present, were not enforced. After correcting the bug now things work as intended.

    Cheers,

    Jorge.
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel

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.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information