• 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. Config Editor : create spectre netlist with different views...

Stats

  • Locked Locked
  • Replies 3
  • Subscribers 125
  • Views 3781
  • 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

Config Editor : create spectre netlist with different views for an iterated instance

MikeA
MikeA over 1 year ago

Hello,

this question is present in this forum already - in a few instances actually. Just citing one of them for reference.

The issue is with the netlister for Spectre I believe, that has a problem dealing with iterated instances (e.g. my_circuit<n:0>) having, possibly, different views on a single-item basis.

This is the kind of error that pops up:

The relatively old answer talks about a `potential project' removing this issue for Spectre.

Given that working with iterated instances is a very convenient flow and I would not like to give it up, a few questions arise:

1 - is any sort of support available for just straight using spectre netlister/engine, overcoming the limitation?

2 - if not, setting aside the extra license topic, the fact that we are not performing mixed-signal sims but fully analog and excusing my ignorance:

would the AMS results be guaranteed to match those by Spectre, for the same underlying circuitry (again, full analog, no verilog-A code). In other words,

is the simulator used Spectre for both cases?

Thanks!

Michele

  • Cancel
  • Andrew Beckett
    Andrew Beckett over 1 year ago

    Michele,

    The major project (mentioned in the other post) was to add the ability for the hierarchy editor to define bindings for sub-elements of iterated instances, and for the netlister to consume those bindings. This was done (at the moment) just for AMS (it wasn't there at the time of the oder post you mentioned) because that was where the biggest demand was. Supporting this in all netlisters is more work - and that hasn't happened yet. There's a long-standing enhancement request, CCR 1652895 asking for this, but some of the duplicate requests may have been resolved by people really wanting this for AMS.

    If you want this specifically for Spectre, you should contact customer support for a request to be made.

    For AMS, if there's no digital content and it's just transistor level, then the results should be equivalent (I wouldn't ever say that would exactly match, because there's always the possibility that the netlist being ordered differently could cause a difference in convergence; however, for a circuit with a single stable operating point, the results should be to the same accuracy). The engine is the same (Spectre) in both cases, so the results should be equivalent.

    Regards,

    Andrew

    • Cancel
    • Vote Up +1 Vote Down
    • Cancel
  • MikeA
    MikeA over 1 year ago in reply to Andrew Beckett

    Thanks Andrew,

    I'll file the request but if AMS uses the same Spectre engine for this specific `overqualified' job only containing analog/transistor level circuitry (no Verilog-*), then it's just a matter of using the license but we can operate with full confidence under AMS for the simulations involving Spectre.

    I assume this would be true - in case - for RF specific sims like HB too, right?

    Thanks,

    Michele

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Andrew Beckett
    Andrew Beckett over 1 year ago in reply to MikeA

    Michele,

    AMS only supports a subset of analyses - dc, tran, ac, noise, xf and stb - no RF analyses. The reason being is that RF analysis would make no sense if there's digital as part of the circuitry (the small signal analyses that are supported are run at a single operating point, whereas the RF analyses require a time-varying operating point).

    Regards,

    Andrew

    • Cancel
    • Vote Up +1 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