Stats

  • Locked Locked
  • Replies 8
  • Subscribers 167
  • Views 16189
  • 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

Library part management

DAAS

 Hi everyone....brand new to 16.6 Pro...no CIS. I've managed to get far enough on my own with it to send some test gerbers (a few issues came up that I'll post later on) to the pcb house and they said everything looked fine. But now I'm backing up to figure out how to organize everything with converting over the 1000's of the library footprints that were made over the years by other designers and making new ones. I "translated" some of the old footprints/symbols from old Orcad 9.2 over to the new package...and made some new ones both with 16.6 and EDA builder. 

When I look at what comes with the package, Orcad has the pad's mixed in with the symbol "dra" files...no matter what they are.

Right now we have all the Molex connectors under their own library/folder.....Tyco....SMD devices...ect. I like to keep it the same way but now the "pads" are separate from the symbol/footprint unlike in 9.2.

Whats everyone doing? Could I have a folder with all the pads in it (then I can easily reuse them for any future part) and nothing else....then I can setup "dra" symbol folders for the components like I have now? (making sure the paths are pointing to those folders)

Or just do what Orcad has done....just have a symbol folder with everything in it and come up with a file naming system to tell me what each symbol is?

Just looking for ideas on the best way to do this...

TIA!
DA

Parents

  • Hi Dass having the pads in a seperate folder is indeed a good idea. For certain things such as vias etc I do the same. The main reason I left the pads in with the dra's was because when you export Layout Footprints the physical Pad gets assigned the old layout pad name
    such as 55_1_4 etc. In the layout tool this was ok as you could click on the spreadsheet and see what the pad was fairly easily.

    But having a pad that says 55_1_4 is kind of meaningless eh ?, even looking at this in explorer gives no real clue to what it is..

    Now in the older layout tool if you did give your pads a name such as S100X100 that might indicate a square pad that is 100x100 mils so that would be ok...

    If you go ahead and export any of the footprint libs from layout, lets say the SMD one that contains passives you will see what I mean..

    Going forward I think it makes things easier if you come up with a standard for naming pads. In that case if all of those pads were in one folder it might be fairly easy to figure out what they are for re-use in creating new symbols.

    Many years ago we had to do this with PCAD.. Allegro is pretty much the same :)

    Thanks Scott. 

     

     

Reply

  • Hi Dass having the pads in a seperate folder is indeed a good idea. For certain things such as vias etc I do the same. The main reason I left the pads in with the dra's was because when you export Layout Footprints the physical Pad gets assigned the old layout pad name
    such as 55_1_4 etc. In the layout tool this was ok as you could click on the spreadsheet and see what the pad was fairly easily.

    But having a pad that says 55_1_4 is kind of meaningless eh ?, even looking at this in explorer gives no real clue to what it is..

    Now in the older layout tool if you did give your pads a name such as S100X100 that might indicate a square pad that is 100x100 mils so that would be ok...

    If you go ahead and export any of the footprint libs from layout, lets say the SMD one that contains passives you will see what I mean..

    Going forward I think it makes things easier if you come up with a standard for naming pads. In that case if all of those pads were in one folder it might be fairly easy to figure out what they are for re-use in creating new symbols.

    Many years ago we had to do this with PCAD.. Allegro is pretty much the same :)

    Thanks Scott. 

     

     

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.