Stats

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

Ocean script that calls other ocean scripts. Is that possible?

C4n0s4
Hi! Everyone! Im doing a verification for LNA and i made 3 scripts for 3 different kinds of simulation. What i would like to do is: Use an ocean script to call the other 3 scripts but the design path need to be a global variable acessible to all scripts. Just to make shure the script is running on the same design. Is that possible? Similiar solutions are welcome.... Best Regards Canosa
Parents

  • Lawrence,

    Whilst your suggestion is quite appealing, it has a number of drawbacks. One is that it requires the simulator to be the same in all script (because calling simulator('somethingElse) will reset the session and hence lose the design), but the main one is that it would require each script to use the delete() function to delete everything before running. For example, imagine I had one script which did analysis('ac ...), and another which did analysis('tran ...). If I ran the first script, and then the second script, using Lawrence's suggestion for avoidance of calling simulator() or design() if already called, it would run an ac analysis in the first script, and then a tran and an ac in the second. The analysis calls (like many other things are cumulative). Since you've no idea what ran before, you'd have to assume you needed to delete everything (and not quite everything can be deleted). So it's really safer to call simulator() each time to start a fresh session.

    You could then declare a global variable:

    MYdesign="/path/to/netlist"

    and then in each script:

    simulator('spectre)
    design(MYdesign)

    If you wanted to allow it to specify the design as a lib/cell/view triplet, you could do:

    MYdesign='("/path/to/netlist")

    or

    MYdesign='("myLib" "myCell" "myView")

    and then do in each script:

    simulator('spectre)
    apply('design MYdesign)

    And of course if you want to avoid the global variable, you could use SKILL++ to create a closure (but I won't complicate things with that suggestion this late on a Friday night (well, it is for me)!).

    Regards,

    Andrew.

Reply

  • Lawrence,

    Whilst your suggestion is quite appealing, it has a number of drawbacks. One is that it requires the simulator to be the same in all script (because calling simulator('somethingElse) will reset the session and hence lose the design), but the main one is that it would require each script to use the delete() function to delete everything before running. For example, imagine I had one script which did analysis('ac ...), and another which did analysis('tran ...). If I ran the first script, and then the second script, using Lawrence's suggestion for avoidance of calling simulator() or design() if already called, it would run an ac analysis in the first script, and then a tran and an ac in the second. The analysis calls (like many other things are cumulative). Since you've no idea what ran before, you'd have to assume you needed to delete everything (and not quite everything can be deleted). So it's really safer to call simulator() each time to start a fresh session.

    You could then declare a global variable:

    MYdesign="/path/to/netlist"

    and then in each script:

    simulator('spectre)
    design(MYdesign)

    If you wanted to allow it to specify the design as a lib/cell/view triplet, you could do:

    MYdesign='("/path/to/netlist")

    or

    MYdesign='("myLib" "myCell" "myView")

    and then do in each script:

    simulator('spectre)
    apply('design MYdesign)

    And of course if you want to avoid the global variable, you could use SKILL++ to create a closure (but I won't complicate things with that suggestion this late on a Friday night (well, it is for me)!).

    Regards,

    Andrew.

Children
No Data

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.