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
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
Parents
  • EvanShultz

    Hi Jerry,

    Thanks for the reply!

    Using Global Modify isn’t an option because of the variety of parts that would need to be changed to completely clean up our library. Only an automated solution will prevent unacceptable “lost time” for my engineers. So, as you suggest, let’s pop the hood.

    Fixing the example project
    To review, the 10.0k resistor was changed from the "resistor2" cell to the "resistor" cell. It stays in the same "mylib" library. It appears that CSA files only contain properties annotated during placement, which makes sense, so I searched for “10.0k”. On page 404 of page1.csa, I find:
    FORCEADD RESISTOR2..1

    Thinking this is pointing out the source cell, I changed line 404 to:
    FORCEADD RESISTOR..1

    But I got the same packaging error. I then deleted the CSB, CSV, and CPC files in the sch_1 directory, leaving just the CSA file. A File > Save Hierarchy later, and I was able to package successfully. Is that the correct process? I attached the fixed page1.csa with a .txt extension.

    Advanced schematics
    Are there special considerations for dealing with multipage and hierarchical designs, with and without subdesign modules and variants? Any solution must work OK in this situation for us to use it.

    After snooping through a design using subdesign modules, it appears I just need to do the same thing as above for each page*.csa in each sch_1 folder, and each sch_ folder, within the project’s top-level folder. Is that correct?

    Since we annotate our internal part number as a part property, which therefore ends up in the CSA files, it becomes much easier to find parts than in the example project attached to this post. This sounds like a great job for Perl! I'll begin experimenting to see what results I get.

Reply
  • EvanShultz

    Hi Jerry,

    Thanks for the reply!

    Using Global Modify isn’t an option because of the variety of parts that would need to be changed to completely clean up our library. Only an automated solution will prevent unacceptable “lost time” for my engineers. So, as you suggest, let’s pop the hood.

    Fixing the example project
    To review, the 10.0k resistor was changed from the "resistor2" cell to the "resistor" cell. It stays in the same "mylib" library. It appears that CSA files only contain properties annotated during placement, which makes sense, so I searched for “10.0k”. On page 404 of page1.csa, I find:
    FORCEADD RESISTOR2..1

    Thinking this is pointing out the source cell, I changed line 404 to:
    FORCEADD RESISTOR..1

    But I got the same packaging error. I then deleted the CSB, CSV, and CPC files in the sch_1 directory, leaving just the CSA file. A File > Save Hierarchy later, and I was able to package successfully. Is that the correct process? I attached the fixed page1.csa with a .txt extension.

    Advanced schematics
    Are there special considerations for dealing with multipage and hierarchical designs, with and without subdesign modules and variants? Any solution must work OK in this situation for us to use it.

    After snooping through a design using subdesign modules, it appears I just need to do the same thing as above for each page*.csa in each sch_1 folder, and each sch_ folder, within the project’s top-level folder. Is that correct?

    Since we annotate our internal part number as a part property, which therefore ends up in the CSA files, it becomes much easier to find parts than in the example project attached to this post. This sounds like a great job for Perl! I'll begin experimenting to see what results I get.

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.