• 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. Processing cadence result data from psf folder

Stats

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

Processing cadence result data from psf folder

RFStuff
RFStuff over 11 years ago

 Dear All,

 There is a Spectre & MATLAB interface for plotting psf data. But this somehow not working in my case with latest MATALB2014.

So I use Ocean Script for saving simulation data in text file in two column format. This then being used some other plotting tools like MATLAB. But when we run Spectre in our central server, we can't run OCEAN but only spectre ( i.e. spectre input.scs).

The raw data files are created in a folder called psf. I can copy this folder to my local macine.

Is there any way, OCEAN can read the raw data in the psf folder and write into a .txt file 

Kind Regards,

  • Cancel
Parents
  • Andrew Beckett
    Andrew Beckett over 11 years ago

    This is a question about namespaces. In OCEAN data access functions (e.g. v(), i(), getData(), pv() etc), the net name/terminal name can be specified either as a "schematic" name or a "netlist" name. If the name begins with a "/", then it refers to a "schematic" name - i.e. the hierarchical name of something within the Virtuoso database. Otherwise it refers to a name that is in the netlist - in which case it has to refer to spectre's naming rules (i.e. dot "." as the hierarchy separator, and ":" for terminal access or operating point parameter access).

    When the schematic is netlisted, you end up with directories called map and amap in the netlist directory which contain the information about how schematic names are mapped to netlist names (in particular this is important if reserved words or illegal characters are used). The names you ask to save get translated via this mapping informaton into corresponding netlist names - so if you ask to save /V2_OUTP_Q/PLUS in OCEAN, it will correspond to a "save V2_OUTP_Q:p" in the netlist. Similarly post-simulation, it uses this mapping information to allow you to access signals using the schematic names (the result database itself only ever contains netlist names).

    In order to do that mapping however, OCEAN needs to know where the amap directory is. The simplest way of achieving that is to ensure that you have:

    someDirectory
      --> netlist
              --> amap dir
              --> map dir
              --> input.scs
      --> psf

    You run the simulation from inside the netlist dir, and then use "spectre -raw ../psf input.scs"

    The expectation from the OCEAN access functions is that you have netlist and psf alongside each other. There are ways around that if OCEAN runs the simulation because it can create a runObjFile in the psf dir to tell it where the netlist dir is, but if running spectre standalone that won't be created and it will then fall back to the default assumption of the structure above.

    Regards,

    Andrew.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • Andrew Beckett
    Andrew Beckett over 11 years ago

    This is a question about namespaces. In OCEAN data access functions (e.g. v(), i(), getData(), pv() etc), the net name/terminal name can be specified either as a "schematic" name or a "netlist" name. If the name begins with a "/", then it refers to a "schematic" name - i.e. the hierarchical name of something within the Virtuoso database. Otherwise it refers to a name that is in the netlist - in which case it has to refer to spectre's naming rules (i.e. dot "." as the hierarchy separator, and ":" for terminal access or operating point parameter access).

    When the schematic is netlisted, you end up with directories called map and amap in the netlist directory which contain the information about how schematic names are mapped to netlist names (in particular this is important if reserved words or illegal characters are used). The names you ask to save get translated via this mapping informaton into corresponding netlist names - so if you ask to save /V2_OUTP_Q/PLUS in OCEAN, it will correspond to a "save V2_OUTP_Q:p" in the netlist. Similarly post-simulation, it uses this mapping information to allow you to access signals using the schematic names (the result database itself only ever contains netlist names).

    In order to do that mapping however, OCEAN needs to know where the amap directory is. The simplest way of achieving that is to ensure that you have:

    someDirectory
      --> netlist
              --> amap dir
              --> map dir
              --> input.scs
      --> psf

    You run the simulation from inside the netlist dir, and then use "spectre -raw ../psf input.scs"

    The expectation from the OCEAN access functions is that you have netlist and psf alongside each other. There are ways around that if OCEAN runs the simulation because it can create a runObjFile in the psf dir to tell it where the netlist dir is, but if running spectre standalone that won't be created and it will then fall back to the default assumption of the structure above.

    Regards,

    Andrew.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
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.

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

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