5 Replies Latest reply on Mar 3, 2010 8:55 AM by robert_davies

    Conversion process from ePD2005 netlist flow to EE2007 iCDB flow is cumbersome and difficult to use.

    avjohn

       

      As I've been attempting to convert a design from the ePD2005 Zuken netlist flow to an EE2007 Expedition iCDB flow, I've noticed that this is a difficult process to use and can be prone to many mistakes being made in trying to convert a design successfully. 

       

      This is just my opinion, but it looks to me that Mentor's DxDesigner/Expedition engineering group put most of their emphasis on the iCDB flow and didn't put much thought into how they were going to support the netlist flows in EE2007 and how to migrate from a netlist flow to the iCDB flow.  EE2007 is a great release if a customer is already using Expedition, but NOT if you are a customer who currently uses a netlist flow and would like to migrate to Expedition.

       

      The current process to convert a design from our Zuken flow to Expedition is not a workable solution.  The current process is cumbersome and difficult to use.  There are many reasons for this:

       

      • We would have to keep a copy of ePD2005.3 available as there is no method or process today to use EE2007 to convert a netlist flow design to the iCDB flow.  It first must be converted to the iCDB flow in ePD2005.3 before converting to EE2007.

      • We would have to install ePD2005.3 on separate PC systems other than the user's local PC so they wouldn't have to run the configurator to switch between the tool versions.  Since ePD2005.3 is a user based install (all the registry entries are entered by the configurator per user login), it will be difficult to have multiple people use the same system.  This will also be difficult to support.

      • We would have to train personnel on how to convert the designs for engineers as the conversion of the design can be easily corrupted unless you follow the steps exactly as written.  This introduces another hand-off in the design process and increases the design cycle time.

       

      While we have been successful in converting a Zuken flow design from ePD2005 to EE2007 there are issues here also.  When we release a schematic design into our PDM system, we do not store the "wir" files or the .dproj file as they can always be recreated when the design is checked out of PDM.  To get the wir files, you must do a "Save and Check" on the design in ePD2005.  The .dproj file can be created using a text editor because in the netlist flow, this file only has 2 lines of text. 

       

      Today, I would not recommend migrating to EE2007 for anyone using the netlist flow process at this time because there are too many issues with EE2007.

       

      We have thousands of designs done using the ePD Netlist flow.  Many of our new designs are spin-offs and/or improvements to a current design, or combining two designs into one.  If we migrate to EE2007, we need to be able to convert designs easily.

       

      If I was to design the ideal process to convert a netlist flow design to the iCDB flow it would be this:

       

      • User gets the design they want to convert (usually out of PDM).

      • User runs a program that creates the "wir" files, changes the viewdraw.ini file to point at the iCDB library and creates the .dproj file using EE2007.  ePD2005 would not be required for the conversion process.

      • User starts EE2007 DxDesigner and does a File > Open to find the .dproj file.

      • The design is converted to the iCDB flow.

      • The iCDB flow allows the user to netlist either to Expedition (and all it's capabilities) or to a netlist flow PCB tool (and it's limitations).

       

       

      What do the rest of you think?

       

       

        • 1. Re: Conversion process from ePD2005 netlist flow to EE2007 iCDB flow is cumbersome and difficult to use.
          robert_davies

          Tony,

          In the intervening releases we have significantly improved the process for migrating designs from EE2005.x and earlier to EE2007.x including the import of netlist based designs to fully integrated EE designs.  Do you believe there are other areas that we need to address in order to complete the process?

          Rob

          • 2. Re: Conversion process from ePD2005 netlist flow to EE2007 iCDB flow is cumbersome and difficult to use.
            avjohn

            Rob,

             

            Sure, I can think some things that would make the migration process better.

             

            1. Have the migration software use the WDIR variable to find the needed migration files, i.e. the property files, the map files and any other files it needs.  Currently I have to copy the files that I've changed the "standard" folder so the migration software will find them.  The migration software should find those files in our corporate WDIR folder.  It would also be great if Mentor could document what files the migration software uses so we could set them up in the our corporate WDIR folder.
            2. If there are no wir files for the design (we don't store them in our PDM system since we could easily recreate them), have the migration software create them and then do the migration.
            3. Don't remove the sch files when migrating a design.  Copy the folder to the BAK folder.  If there is a problem with the migration, the sch files are gone and it's difficult to fix the design in ePD2005 if there are no sch files.
            4. Store the grid setting in the .prj file instead of the .xml file.  We have libraries that use different grid settings.  If the grid was setup in the .prj file, the user would not have to remember to change the grid when changing libraries.
            5. When you have schematic files in the ePD2005 sch folder that are not part of the design, when the migration software finds those files, it stops the migration because there are no wir files for those extra schematic files.  If the migration software needs wir files for those schematic files, either:
                • Create the wir files for those extra schematic files and migrate them.
                • Or, give the user a warning that these schematic files will not be migrated and continue on, don't stop the migration.
              • If there are symbols missing from the design, the migration software stops.  It would be better if the software just put a white box where the symbol should be (like ePD2005 does) and notify the user that the symbol is missing and continue on, don't stop the migration.
              • Fix Scout so that it reuses the ePD2005 cross-reference properties.  If I migrate a design that used Scout and still has the ePD2005 Scout attributes in the schematic, the EE2007 version of Scout does not reuse these attributes.  They need to be deleted from the ePD2005 schematic before the design is migrated.  This is a problem if the design is hierarchical, a page number file was not used, and you need to keep the same page numbers.  Because Scout now uses a different page number algorithm the page numbers will be different.  On an ECO where we need to keep the page numbers the same, this is a big problem.
              • After the design has been migrated, the .prj file is not in a configuration which makes it usable in the EE2007 environment.  We would like the migration software to ask the user to pick from a list of project template files so the .prj file can be updated and the project made ready for use.  What happens now is that the user has to open up the project settings and change them.
              • Make the migration process faster.  It's way to slow.  On a 40 sheet flat design (netlist flow) we see migration times of 5 minutes or more.  Hierarchical designs take even longer.  Our schematics average 40-50 pages and 80-90 pages are not uncommon.
              • When something is wrong with the ePD2005 schematic, have the migration software do it's best to work around the problem, notify the user what the problem is, and allow the user to fix the problem in EE2007 and not have to go back to ePD2005 to fix the design.

               

              I'd be happy to discuss with you more about the migration process if you'd like.

               

              Regards,

               

              Tony

              • 3. Re: Conversion process from ePD2005 netlist flow to EE2007 iCDB flow is cumbersome and difficult to use.
                MarkP

                I've been thinking about this conversion process also.  My company also has a large number of stored designs in Netlist flow, that we will need to convert from 2005.3 to 2007.x.  The process of converting a netlist design to iCDB flow in my opinion is also too cumbersome, but I do agree with Mentor that it has become easier in later releases of 2007. But you still have to convert the design to CDB flow in 2005.3, which won't be feasible once 2007 is up and running (unless, as you suggested, we keep a copy of 2005.3).

                 

                Once we get everyone using 2007, another related question is how to convert a 2007 netlist flow design to iCDB flow (we do that right now with 2005, converting from netlist to CDB flow). One approach that I'm thinking about is to use the Copy/Paste feature - create a new iCDB flow project, then copy the netlist flow design into the new project. This seems to work on a simple test case.  For migration, it is easier to migrate the 2005.3 netlist project to 2007 netlist flow, then Copy/Paste the design to a new iCDB flow project.

                 

                I welcome any comments on this approach - especially if I missing some key task that will prevent doing this!

                • 4. Re: Conversion process from ePD2005 netlist flow to EE2007 iCDB flow is cumbersome and difficult to use.
                  avjohn

                  I think you're on the right track with the Copy/Paste method to bring in a netlist flow design to an iCDB design.

                   

                  Another thing you could try is to use the File > Import > Netlist Project.  I know this works for ePD2005 netlist designs.  I can't remember if it'll work for a converted EE2007 netlist designs.  Basically what you do is open an exisiting iCDB design and then import the sheets you want from the netlist design.  If there are no wir files, the import creates them.

                   

                  Tony

                  • 5. Re: Conversion process from ePD2005 netlist flow to EE2007 iCDB flow is cumbersome and difficult to use.
                    robert_davies

                    As Tony mentions an alternative and more efficient approach is to use the Import - Netlist Project option introduced in EE2007.7. This will also work for a 2007.x netlist design.

                     

                    Steps to use this are:

                     

                    1. Create a new Expedition Project

                     

                    2. Select an appropriate Expedition Template thus quickly defining Central Library, Special components, Ports, Drawing Borders, colours, and fonts

                     

                    3. invoke DxD Import Netlist command and select project(*.prj *.dproj) and then schematics to be imported

                     

                    4. Select sheets to import

                     

                    Note: Netlist Attributes are mapped to Expedition Common properties. Any User defined properties & Global nets are reported for you to update as appropriate. Aliased symbols referenced in the viewdraw.ini file with an equivalent in the Central Library will be used in preference to them being imported as local symbols. Any new symbols (not present in the Central Library) are added as local symbols. These can be exported from the design and imported to the Central Library post the conversion.

                     

                    Earlier ePD software does not need to be installed but library symbols pointed to in the viewdraw.ini must be present

                     

                    Rob