Stats

  • Replies 3
  • Subscribers 149
  • Views 596
  • Members are here 0

Symbol Editor Navigator Pins not updating

Trevor F

Good evening,

I'm creating a tool which renames pins attached to a given cell. This walks the hierarchy, updating various view types.

Specifically on the symbol view, I've encountered an issue. I am able to update the pin names via renaming the labels, and applying various check and save/database operations. I've confirmed the pin order via schGetPinOrder(symId), and it matches perfectly. I've also confirmed the cdsTerms, nets, and pins are renamed. The ONLY issue I'm encountering is the Pins menu via the Navigator. The old pin name changes to a "Symbol" rather than a "Symbol Pin" on the Property Editor, selecting it doesn't highlight any pins (expected), and it displays the old name.

I've combed through the list of warnings, and there is no pin order mismatch, port mismatch, or anything of value.

Through further investigation I found two properties that still hold the old name after the rename:

1. cellView~>sigNames — a cached list of signal names on the cellview object itself. This is separate from the terminals and does not update automatically when terminal names change.

2. parentCv~>conns[N]~>inst~>instTerms[N]~>name — instance terminal name caches on every parent schematic that instantiates the renamed symbol. These appear to be read-only (DB Cannot set attribute - name), so we have not been able to update these directly.

For (1) we are attempting dbReplacePropList(symId list(list("sigNames" "stringList" newList))) but have not yet confirmed whether sigNames is a writable named property or a read-only computed attribute in OpenAccess.

For (2) we are unsure of the correct mechanism to refresh instance terminal caches after a master cell's terminals are renamed programmatically.

Any guidance is appreciated. I'm knowingly not deleting/adding pins to rename, as it doesn't fit our tools specs.

Thanks,
Trevor

Parents
  • Andrew Beckett

    Trevor,

    It would help if you showed what your code is doing right now to rename the terminal names. Essentially what you need to do is:

    1. term=dbFindTermByName(cv "inm") ; say the terminal was called inm and you want it to be inmnew
    2. newNet=dbMakeNet(cv "inmnew")
    3. term~>name="inmnew"
    4. dbMergeNet(newNet term~>net)
    5. Fix the labels (cdsTerm, etc)

    You'll find (because you fixed the net names as well as terminal names) that cv~>sigNames will be correct.

    You'll need to perform an schCheck() in parent cellViews - that should (I think, from my experiments too) fix the instTerms.

    There's not really any caches here - it's just that the instTerms belong to the parent, and have to be reconstructed.

    I don't see any problem with the navigator if I do the above.

    Andrew

  • Trevor F
    in reply to Andrew Beckett

    Hi Andrew, I've added your suggestions. What I was doing before was walking the cell properties and editing terminals and labels. I'm fairly certain the navigator issue is a visual bug, as I created a procedure to walk through a cells properties, and find occurrences of a string, and there are no old tags.

    A more pressing issue I've now met, is the layout case. When I switch terminal names, it is reassigning my net to nil. See the before and after of renaming i_dts0 to i_dts00:





    I've referred to an older article concerning renaming the layout pins, and the flow follows as such:

    dbOpenCellViewByType - layout
    dbFindTermByName - old pin name
    term~>name = newName
    walk the figs~>children hierarchy and update old labels

    I'm wondering what I'm missing as to preserve the connected value of i_dts0 when it changes to i_dts00.

    EDIT: This is performed on Layout EXL, IC23.1. 


    Thanks, Trevor



  • Andrew Beckett
    in reply to Trevor F

    Assuming you are talking about what happens to the connectivity in the layout containing an instance of your cell for which you have changed the terminal names, you'd need to get it to reconstruct and reconnect the instTerms. Typically this would be done using Update Components and Nets (presumably the schematic connectivity has changed, and the layout connectivity needs to update to reflect that). I think the extractor would take care of it after that (so I don't think an explicit re-extract would be necessary), but using UCN would be the sensible way to update the connectivity correctly.

    Changing the terminals on a device/cell does not alter the instTerms on the level above (same as in a schematic, which is why the schCheck was needed).

    Andrew

Reply
  • Andrew Beckett
    in reply to Trevor F

    Assuming you are talking about what happens to the connectivity in the layout containing an instance of your cell for which you have changed the terminal names, you'd need to get it to reconstruct and reconnect the instTerms. Typically this would be done using Update Components and Nets (presumably the schematic connectivity has changed, and the layout connectivity needs to update to reflect that). I think the extractor would take care of it after that (so I don't think an explicit re-extract would be necessary), but using UCN would be the sensible way to update the connectivity correctly.

    Changing the terminals on a device/cell does not alter the instTerms on the level above (same as in a schematic, which is why the schCheck was needed).

    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.