• 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. PCB Design
  3. DE HDL - can I move a part from one cell to another?

Stats

  • Locked Locked
  • Replies 5
  • Subscribers 162
  • Views 3568
  • Members are here 0
More Content
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

DE HDL - can I move a part from one cell to another?

EvanShultz
EvanShultz over 15 years ago
The problem
Over the years, we've realized we didn't structure our library in the best possible fashion. However, it's very troublesome to make sweeping changes to the library, as that will affect many users. Most of our problem lies in unnecessarily subdivided cells. So instead of going to one cell, I have to search in many cells to find the comp I want. Or I have to select many cells and filter. It would be better if I could take similar cells and combine all their parts into a single cell. Or, rather, take all the comps from one cell and move them to a different, already existing, cell. Does that make sense?

To experiment with my options using a project I can release for your experimenting pleasure, I used the example project from Solution ID: 11015438. I added a second cell in the classlib/mylib library called "resistor2". This cell contains unique comps. First, I placed a couple comps from the "resistor2" cell and packaged the schematic (no PCB updates). All was well.

Moving a cell to a different library: OK
I know that I can move the "resistor2" cell from the classlib/mylib library to the standard library without trouble. When I open the schematic after moving the cell, I see:
WARNING(SPCOCN-1343): Design Name: NS_TEST.SCH.1.1Component RESISTOR2.SYM.1.1 not found in library mylib, added from library standard.
in the Console. DE HDL is smart enough to look for a cell that has been completely moved to a different library. While the this warning is innocuous, I can update the paths by running File > Save Hierarchy; the warning goes away because DE HDL then remembers in what library to look for the "resistor2" cell.

So, as I'd discovered a few years ago, I can move cells from one library to another without causing packaging issues and frustration for the users. I can make my changes and the users may never notice (although it does slow down DE HDL invocation); but all that's required is running a simple menu command and everything is happy again.

Moving a comp to a different cell: Fail
However, that's not exactly what I want to do. I want to move comps from one cell to another cell. So if I open part.ptf in the "resistor2" cell, cut a comp, and paste it into the part.ptf in the "resistor" cell, I should get an error. Sure enough, I can open the schematic and see the comp that was moved (since the primitive cell info remains), but when I try to package I see the following error in pxl.log:
ERROR(SPCOPK-1053): Cannot find a ppt part that matches the instance properties.
Ppt Name: RESISTOR2

and the error continues in more detail.

And thus we know that I can't move comps from one cell to another and still package the design. It appears DE HDL, or rather PXL, doesn't search within other cells for a specific comp when it sees a missing comp. And this means major irritation and work for my users. Trying to clean up and improve our library isn't worth this pain.

Am I stuck?
But, is there a solution? Can the comps in one cell be moved to another, already existing cell without causing this trouble? I can't be the only person who found out far too late that there's a better way to structure the library. But perhaps everyone else in the same situation just lives with it??

I've attached the zipped (it was already archived) project with my changes. If you want to get it back to a working state, simply cut the following line from part.ptf in the "resistor" cell and paste it into part.ptf in the "resistor2" cell (part.ptf is at \part_table):
10.0K(10.0K) = 24707-008-74 | 10.0K | "1%" | SMDRES | .25 | "10.0K RESISTOR"

Thanks for any help or guidance on this issue!
netshort.zip
  • Cancel
Parents
  • EvanShultz
    EvanShultz over 15 years ago

    Hi Jerry!

    Thanks for clarifying the exact nature of the issue.

    We have many cells with only a few comps that could be combined. For instance, instead of a single 3 pin connector cell, there are several cells for 3 pin connectors of different physical styles. This causes users to either know and remember exactly what they're looking for, or else search around (manual searching or using filters in Component Browser). Since all 3 pin connectors I'm concerned with have the same logical/sch symbol, putting them into the same cell simplifies our library structure and makes finding parts easier.

    In another example, there may be a new, unique part that gets a new cell. In the fullness of time, similar parts are added and now the cell name is confusing/inappropriate. Or a component is discontinued and the replacement part, which can live in the same cell since it's logically identical, has a different manufacturer part number; in that case looking for the cell name doesn't match the parts within. Having the ability to rename cells makes comps most easily discoverable. Not knowing what parts our library will contain years down the road, it's impossible to plan the library structure and cell names perfectly.

    In both cases the solution is the same: the same comp(s) need to be in a cell with a different name. While we've learned from our (unknown) mistakes when we first switched to the SPB tools, we can't correct anything without unacceptably breaking all previous and current SPB projects.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • EvanShultz
    EvanShultz over 15 years ago

    Hi Jerry!

    Thanks for clarifying the exact nature of the issue.

    We have many cells with only a few comps that could be combined. For instance, instead of a single 3 pin connector cell, there are several cells for 3 pin connectors of different physical styles. This causes users to either know and remember exactly what they're looking for, or else search around (manual searching or using filters in Component Browser). Since all 3 pin connectors I'm concerned with have the same logical/sch symbol, putting them into the same cell simplifies our library structure and makes finding parts easier.

    In another example, there may be a new, unique part that gets a new cell. In the fullness of time, similar parts are added and now the cell name is confusing/inappropriate. Or a component is discontinued and the replacement part, which can live in the same cell since it's logically identical, has a different manufacturer part number; in that case looking for the cell name doesn't match the parts within. Having the ability to rename cells makes comps most easily discoverable. Not knowing what parts our library will contain years down the road, it's impossible to plan the library structure and cell names perfectly.

    In both cases the solution is the same: the same comp(s) need to be in a cell with a different name. While we've learned from our (unknown) mistakes when we first switched to the SPB tools, we can't correct anything without unacceptably breaking all previous and current SPB projects.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Children
No Data
Cadence Guidelines

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.

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

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