Stats

  • Locked Locked
  • Replies 5
  • Subscribers 163
  • Views 3012
  • 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
  • Jerry GenPart

    Hi Evan,

    Interesting scenario. I downloaded the ZIP file attached and see the Export Physical error you’re getting. I’m sure you realize why you get this – the PTF files contain part (“comp” as you call it below) rows based on the cell’s PART_NAME property. So, while each cell’s PTF file is read by Export Physical, it matches the cell’s PART_NAME property before reading PTF rows in that file’s part section.

    Could you clarify why you’re moving PTF part rows from one part name (PART_NAME) to another? I’m a bit confused on the end goal.

    Jerry

     

  • EvanShultz

    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.

  • Jerry GenPart

    OK Evan – this helps.

    So, you’d have a single new part (3pinconn) that would contain all the PTF rows from the original 3 pin connectors.

    You will need to update the schematic and replace the 2 other named parts with the new 3pinconn part. There would be a single part.ptf file under the 3pinconn containing a single PART_NAME section (3PINCONN) and all the rows from the original 3 parts.

    Now – to update the schematic, you can use the Global Modify command. Or (but be VERY careful), you could write a small script to update the sch_1 page.csa files and replace the 2 other parts with the 3PINCONN part.

    Should work just fine – let me know.


    Jerry

  • 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.

  • Jerry GenPart

    Correct Evan!

    I forgot to mention deleing the .csb file after editing the .csa and doing a Save Hierarchy. Only the .csb file

    needs to be deleted. Just edit these file across all pages of the hierarchy and you should be good to go.

    Obligatory CAUTIONARY statement – EDIT .csa FILES AT YOUR OWN RISK.

    Jerry

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.