4 Replies Latest reply on Sep 9, 2015 4:10 AM by george.jaray

    Migration from Netlist based design to Central library based


      Migration from Netlist based design to Central library based is proving to be impossible , mostly because of the packager related errors.


      Starting from square one, dancing around the issues would be easy BUT!!!!

      I have a very large database of symbols , in both dxdesigner and pads that is linked by a dxdatabook tables of more that 3000 parts.


      I used the Central Library Migrator to create the central library, there were a lot of warning and some errors. I assumed I would  be able to work around them.


      This is where my problems start,

      I took a completed and in production design created in netlist flow and converted it to Integrated.

      It is just one giant bucket of errors. though all the data needed is there and good.


      The biggest problems is the "PART" area,its associations and the need foboth symbol and decal to be correctly associated.


      many parts are not associated to symbols. simply because the "GATE" and  "CAE DECAL" are missing, wrong or incomplete in pads.


      Most of out part database does not have or need this info , and the schematic goes forward and backwards fine without it in netlist flow.


      Because the Packager insists on validating this info, and in a certain set of cases, it is impossible to set it correctly.


      problem 1: some of our symbols , use ".1,.2,.3,.4" ' still very selectable in dx designer part and still works in integrated mode for part selection.

                     ,cannot be import into central library because there are no extension , schematic entry still works, packager fails and cannot be made to work, no extensions on symbol names importable, so only the ".1 "version will ever exist in the central part library.


      problem 2: I have some duplicate and identical symbols {not on purpose} in two or more partitions ,

                     schematic entry still works, packager fails and cannot be made to work. no partition info in part name so it cannot set symbol from correct partition. works if lucky , else never works ,


      problem3: MUST have a "cae decal" defined,  does not do anything I can see that is useful, but cannot be possibly be  set right if problem 1 or 2 applies .


      problem4: MUST have a Gate and correct pin names, does not do anything I can see that is useful, can be a massive manual editing job  on large I.C. and cannot be set right if problem 1 or 2 applies .


      Most of the migration process left symbols and decal association unset because of the previous problems. we are talking like way more than 1/2 of my database is not usable .....


      Most of the problems are based on rules and input that applies to pads schematic entry and has no bearing on dxdesigner.

      as a matter of fact my base Pads library has NO schematic decals at all, but all of the packager test against this hierarchy which is not compatible to dxdesigner in many cases.


      Remember this is a design that was fully forward and back annotated and built using netlist flow but I cannot get past packager forward without a lot of errors ,

      all the errors are rooted in the packager verifying that PADS schematic symbols as correct for the part, and schematic symbols are not really relevant to layout, but it keeps me from going to layout.


      simple  question , can I turn off the packagers check of the schematic symbol to part db integrity????

        • 1. Re: Migration from Netlist based design to Central library based
          Marty Fouch

          Hi George,


          You have done a great job laying out your dilemma with your migration to the integrated flow. I am the support manager of the PADS support team and someone from my team could certainly help you with this issue. I would suggest if you need some dedicated help from my team, please open a service request on https://supportnet.mentor.com/  and we can help you sort these issues out.


          Best Regards,

          Marty Fouch

          PADS Support Manager

          • 2. Re: Migration from Netlist based design to Central library based



            If I am understanding you correctly:


            You listed a couple of requirements that you say you see no use for.  Schematic symbol assignment to parts, pin assignment to symbols......  Things the packager pretty much handled for you before.


            I'm working on making the migration from PADS Flow (Logic - Layout) to Central Libraries.  So my perspective is that if all thing you see as useless are done well, I see no use for a packager.


            And that might be the confusion created by the new Central libraries.  They are trying hard to merge the best of both worlds, but those worlds were quite divergent.


            Coming from my perspective, I think it's easier to understand the concept.  PADS Flow libraries started with a Part Type.  For example, a 74LS03 NAND gate.  A Part Type is created, I'll call it 123456 (company part number).  I add whatever properties I need (Part number, description, etc).  I attach to that a NAND symbol.  I can also attach another symbol, with a different graphic representation of a NAND gate.  Then I assign pin numbers to the symbol.  Then assign a PCB Decal, say a SOIC14.  This lets me use that same NAND symbol with many different parts, with different pinouts (Quad, dual, single) and I can assign that SOIC14 to any other number of parts.  As soon as you place the first gate on a  schematic, all of the part information is there.


            This is why you must have everything assigned in the Central Library.


            Now, where it gets dicey is that xDxDesigner is symbol based, not part based.  So the Central library is still driven by the symbol.  So it's hard to resolve things like multiple symbols that describe one part, or duplicate symbols used to describe different parts.


            The Mentor team took on quite a task to create Central Libraries that can be migrated to from both a symbol based, packager driven and a part based, library driven scheme.  They are listening to users to get this right, but it's not going to be easy.  I'm glad I read your post.  I've been talking to Mentor about the frustrations I'm having migrating from PADS Flow, it's helpful to remember others are migrating from Netlist Flow.



            • 3. Re: Migration from Netlist based design to Central library based

              I understand there goal,


              make the central library match the pads flow,


              but lets face it , the PADS layout needs only DXdesigner attributes translated to PADS layout attributes. and dx designer needs nothing all all from PADS layout.

              Forcing Pads schematic nomenclature and rules onto  dxdesigner simply makes a ton of legacy Dxdesigner stuff that worked fine now completely unusable.


              If the packager ignored schematic related stuff like the netlist flow currently does , I would have no problem.


              My Large scale problem is ,  I have a dxdatabook with 1200+ parts , schematic symbols with 2500+ parts, and a PCB decal library with 2000 + parts. I admit  not all of this is correct and properly linked , BUT in a netlist flow, it all works on pretty complex designs, and is easily corrected when a problem is identified , AND none of it contains any Pads schematic related things.

              We never used Pads schematic entry and as a NOTE: in the latest VX , they do not even include it in the install. so why force me to reference an incompatible AND ALSO NOW  obsolete format for migrating data to a central library. remember , the central library data still has the same symbol data base and Pads pcb data it had before. my issue is forcing the use of the packager which is obviously from Pads Schematic to Pads PCB and not making it work with the dxdesigner architecture, which is going to be the new long term entry standard anyway.


              They also tossed in another wildcard as well , they are integrating Expedition into this mix. It appears to me that expedition is the final goal in the long run. so now 3 things to mix up and muddle the process.

              • 4. Re: Migration from Netlist based design to Central library based

                ...Deleted reply I, did not realize it would be posted, I just replied to a email.....