• 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 SKILL
  3. mapping schematic terminal name to simulation name to read...

Stats

  • Locked Locked
  • Replies 3
  • Subscribers 143
  • Views 16132
  • 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

mapping schematic terminal name to simulation name to read terminal current with a skill script

marcelpreda
marcelpreda over 7 years ago

Hi *,

I have some problem when reading with a skill script the currents of the instances' pins.

I need a way to translate the schematic hierarchical names to simulation names.

Reading the docs (IC6.1.7)  I've found there is a procedure asiMapTerminalName(dataDir list_hier_pin_names) that does what I want.

But there seems to be some exception: e.g. a vpwl instance from analogLib the return value looks like (FUNCTION minus(root(\"PLUS\")) see below. And a getData() call on the return value  generates an error.

Question: what is the more reliable (and consistent) way to get the terminal name from simulation and to read the associated current?

asiMapTerminalName(asiGetDataDir(asiGetCurrentSession()) list("/IT7/p"))
("IT7:p")
asiMapTerminalName(asiGetDataDir(asiGetCurrentSession()) list("/C0/p"))
("C0:1")
asiMapTerminalName(asiGetDataDir(asiGetCurrentSession()) list("/Vgate/PLUS"))
("Vgate:p")
asiMapTerminalName(asiGetDataDir(asiGetCurrentSession()) list("/Vgate/MINUS"))
("Vgate(FUNCTION minus(root(\"PLUS\")))")

getData(car(asiMapTerminalName(asiGetDataDir(asiGetCurrentSession()) list("/Vgate/MINUS"))))
*Error* parseString: argument #1 should be either a string or a symbol (type template = "SSg") at line 53 of file "*ciwInPort*" - nil

I assume that it means current value of "MINUS" is the opposite value of "PLUS", to save some space in the psf database. The question is if there is any skill procedure to do the respective calculation.

Also, we have try a different approach: to get the terminals order, to associate the schematic name to the number and to read the data using the terminal number.

E.g. in the example above the name "/C0/p" is mapped to "C0:1", and getData("C0:1") works.

But for other devices this mapping does not work. E.g. the pins of IT7 are (p m), but a call like getData("IT7:0") returns nil.

Is there any setting in ADE-L to say: for all the pins save the currents also based on terminal number, not only names.

Best Regards,

Marcel

  • Cancel
  • Andrew Beckett
    Andrew Beckett over 7 years ago

    Hi Marcel,

    If your goal is to read the data (e.g. with getData()) then there's no point using the asiMap functions, because that's done internally for any name that begins with a "/" anyway - plus it handles the other mappings as defined in the CDF.

    Unfortunately this is one of those things that has long been a problem; in an ideal world, spectre (if it's spectre that is the simulator) would write out the terminal currents with both the pin name and the position - using an alias in the results database. Unfortunately aliases are not really supported in all results formats (I think PSF XL does, but it's only used for a few analyses; most all back to PSF). There's an option in spectre to control whether it uses names or numbers for terminals by default (see "spectre -h options" and see the useterms parameter). This has got a little better in recent versions because explicit save statements aren't affected by it - but you can find that if the setting contradicts the definition in the termMapping in the CDF, then you can't probe the currents if you've saved all currents rather than explicitly saving them from ADE.

    I'll push for us to spend some effort on getting this sorted out once and for all. For now you probably just have to take care to ensure that your CDF termMapping matches how it's actually saved...

    Regards,

    Andrew.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • marcelpreda
    marcelpreda over 7 years ago in reply to Andrew Beckett

    Hi Andrew,

    Thanks a lot for reply.

    The problem is that we have to support spectre and some other simulator; and getData("/INST/pinName" ?result 'tran) always return nil in the other simulator.

    I want(ed) to have a code which does not depends by simulator once I have open the psf database.

    I'll check your hints. As info: it is a transient simulation, and in spectre the saved format is psfxl.

    Best Regards,

    Marcel

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Andrew Beckett
    Andrew Beckett over 7 years ago in reply to marcelpreda

    Hi Marcel,

    Given that each simulator would normally have its own simulation information section in the CDF, there should be control over the termMapping for each simulator. Of course, if that other simulator is re-using the simulation information from a different simulator, then that might be a problem. However, if it's not something you can fix with some simulator-specific CDF setting, then it's a problem with either that other simulator or its integration into ADE. As I said before, if the mapping performed by getData doesn't work, it's also not going to work if you use the asiMapTerminalName calls either because they're both using the same mapping.

    Currently I don't think we save the aliased names for terminal currents in spectre even with PSF XL (which does support signal aliasing as far as I know). The main problem is that we sort-of need to do it everywhere otherwise it could just end up even more confusing.

    Regards,

    Andrew.

    • 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