Home
  • Products
  • Solutions
  • Support
  • Company

This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  • Products
  • Solutions
  • Support
  • Company
Community RF Design nport device S-parameter data file relative path

Stats

  • Locked Locked
  • Replies 6
  • Subscribers 63
  • Views 4924
  • 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

nport device S-parameter data file relative path

DKaraca
DKaraca 11 months ago

Hi,

In our design team, we're looking for a strategy to make all cell views self-contained. We are struggling to do so when nport devices are involved.

The nport file requires a full path, whereas what we need is a relative path to the current path of the cell in which we're using the nport.

I have browsed through the forums & cadence support pages, but could not find a solution.

1) There is a proposal from Andrew to add the file directory in ADE option "Simulation Files." :https://community.cadence.com/cadence_technology_forums/f/rf-design/27167/s-parameter-datafile-path-in-nport . This, however, is not suitable, because the cell is not self contained.

2) The new cadence version off DataSource "cellView" in nport options:

This however is not suitable for us due to two reasons:

i- Somehow we don't get this option in the nport cell (perhaps some custom modification from our PDK team)

ii- Even if we had this option, it requires to select the library, which again makes it unsuitable: We often copy design libraries for derivative products using "Hierarchical Copy" feature. And when the library is copied, the nport will still be pointing to the old library. Thus, it is still not self-contained.

In principle, it should not be difficult (technically) to point to a text file relative to the cell directory (f.ex we can make a folder under the same cell with name "sparFiles" & place all spar files under this folder), however it does not seem to be possible.

Could you perhaps recommend us a work-around to achieve our goal: making the cells which contain nport devices self-contained so that when we copy a cell, we do not have to update all the nport file destinations ?

Thanks in advance.

My Cadence Version: IC23.1-64b.ISR4.51

My Spectre version: 23.1.0.362.isr5

  • Cancel
  • Andrew Beckett
    Andrew Beckett 11 months ago

    The method in point 2 is the best solution, which is precisely why I initially prototyped it and we had it added to the nport shipped in analogLib some time back (IC6.1.8/ICADVM20.1 ISR16, so well before the version you're using). To answer your points i and ii:

    1. Presumably you are not pointing to analogLib in the IC23.1 installation, but some outdated version. That is not a good idea, and it seems silly trying to come up with a complicated workaround for something that is probably wrong in your setup. You should fix the cds.lib to include something like this
    2. This was fixed a while back too - as described in this article (which gives a workaround for older versions, but you're using a new enough IC version that his would be bult-in). See nport using cellView to define location of s-parameter file is not updated after copy/rename in the Library Manager

    Your suggestion of creating folder called sparFiles at the view level and putting all the files there wouldn't work, because the library manager (for copy) and design management would know nothing about these files. Similarly the nport wouldn't know that it needed to resolve relative paths relative to the location of the cell containing the nport instance. This is precisely why the lib/cell/view was added to nport...

    Regards,

    Andrew 

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • DKaraca
    DKaraca 11 months ago in reply to Andrew Beckett

    Hi Andrew,

    Thanks for your prompt reply. I'll check with the PDK team regarding the nport device settings (to fix the device referring to an older version).

    Regarding my suggestion, you're right, it does not work with the way nport device normally behaves.

    However, if it had been possible to point to the relative directory of the same cell, it would have worked. We wouldn't even have to make a new directory called sparFiles, we could place the .snp file simply under the schematic view. For example:

    Cell name:cell_test
    viewName: schematic_spar
    & we place the sparameter file inside the schematic_spar directory: .../cell_test/schematic_spar/sparam.snp

    If the nport device allowed us to define the file location relative to the cell it is placed in, we could simply set the file as sparam.snp (which then would be interpreted as .../cell_test/schematic_spar/sparam.snp). 

    In this case, if we copy the schematic_spar view, the .snp file is copied together with it (because it's in the same dir) & the cell would be self-contained.

    For example the copied cell is

    Cell name:cell_test_copy
    viewName: schematic_spar

    then the nport inside would point to  .../cell_test_copy/schematic_spar/sparam.snp

    I hope this clarifies what I meant.

    BR,

    Denizhan

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Andrew Beckett
    Andrew Beckett 11 months ago in reply to DKaraca

    Hi Denizhan,

    I forgot to give the suggested cds.lib entry:

    DEFINE analogLib $(inst_root_with:tools/dfII/bin/virtuoso)/tools/dfII/etc/cdslib/artist/analogLib

    If you create s-parameters using EMX or Clarity in the Electromagnetic Assistant in Virtuoso Layout Suite EXL, then it does store the data under the schematic or smartview views, and the nports know to reference them from the cellView. However, this would also require a current analogLib - so fixing that would be required anyway. This is because the netlist procedure knows where to look for the files - but this is not generally available for arbitrary s-parameters. There are also specific s-parameter views which are self-contained - these two are created by the Electromagnetic Assistant.

    The supported flow for generic s-parameters is to use the cellview-based nport, and so enabling that is the right way forward. I'd be surprised if this is anything to do with PDKs - it just sounds as if your cds.lib is not set up correctly?

    Regards,

    Andrew

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • DKaraca
    DKaraca 11 months ago in reply to Andrew Beckett

    Hi Andrew,

    When I said PDK team, I was actually referring to the Design Enablement team who sets up the design environment for us. They arrange all the tooling options, default settings when cadence is start-up etc.

    Thanks for your remark.

    BR,

    Denizhan

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Andrew Beckett
    Andrew Beckett 11 months ago in reply to DKaraca

    I suspect it might also be that you're using a customised analogLib for a non-Cadence simulator rather than the version we ship. This might be elderly and not up to date.

    Andrew

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • DKaraca
    DKaraca 11 months ago in reply to Andrew Beckett

    I suspect the same scenario. I'll check this with the design enablement team. I'm sure they have the answer :)

    • 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