I would like to open a discussion regarding transitioning from DC to Dx Designer for schematic capture:
At National Instruments we have been using Design Capture since the days of when it used to be Aceplus/Cadnetix; so needless to say we have an extensive
Library and engineering product folders with the following:
15,926 individual schematic symbols
3,452 cell footprints
12,141 PDBs (Parts Databases)
I have heard a mix of user opinions in the past such as "wait as long as you can- until you have to move" or wait a few more revision cycles because of the quantity of code changes/enhancements. We are willing to move forward to Dx if the translators are stable, quality of data is clean without need for workarounds etc.
I personally have concerns about the "ease of translation" if they are using EDIF to migrate schematics. I have seen allot of other tools turn some features into garbage with the 2.0 formats.
I understand Mentor will continue to support DC as long as the customer base is paying support but we don't want to be in a situation where there is an abrupt change in policy or stay on a capture tool that is "dormant" if all of the development is focused towards Dx.
If you have experienced the growing pains & Gains what are some of your observations?
Q. What pitfalls did you discover in your attempt/success in migration?
ex. requirements in reviewing all symbols (did you find problems with mirror views etc), issues with buss rippers going from DC>EDIF>Dx translator.
Q. Did you require an on-site AE in order to run the translators?
I really wanted to see a seamless translator that anyone could run (comparable to the VB98 migration tool) vs. ton of scripts & manual tasks.
Q. How long did it take you to actually translate and roll out Dx to your teams?
Q. Have you experienced problems since Dx is CES only vs. DC which still allows netclasses/netproperties (stability factor)
Q. What where the gains vs. losses in the migration (symbol wizards, script abilities)
Feel free to share whatever you deem to be reasonable & Thanks
Application Support Analyst
I would also like to know if you had to contact Customer Support for any help? If so can you remember why?
Thanks Chris for getting this started.
I'd like to echo Chris' concerns here. We have AE help, but the migration wizard is far from producing migrated designs and libraries that will package in Dx.
With a huge archive of legacy designs and a library of over 25K partnumbers, I need to present my users all over the world a migration methodology that a casual user can point at a schematic and produce a Dx version with as few workarounds as possible. It sounds like a fantasy at this point. I understand that Mentor engineering resources are targeting their legacy Mil-Aero customers now and we'll have to wait our turn, but this is gating our migration and any effective engagement with DxD to scope the work needed to get us through this transistion successfully.
We make extensive use of subcontractors for PCB layout. A key part of our process separates the PCB from the schematic up to forward anno and db load.
I'm catching a bit of odor here that this may no longer be possible. To the question- Is it possible to maintain the schematic and PCB data separately up to integration or is it necessary to store our "seedjobs" as templates in a central library structure?
I would like to answer your question specific to "process separates the PCB from the schematic up to forward anno and db load".
The 2005.X DC/DV Expedition PCB flow supported Foreign CDB flow that allowed users to separate the schematic and layout projects. With the introduction of the 2007 flow this methodology is still supported and called the Foreign iCDB flow. The delivered documentation has a section called "Working with Foreign Databases" that explains this flow and how the schematic user runs File > Export > Foreign Database to generate the information Expedition PCB needs to forward annotate. Then when there are pending back annotation changes from Expedition PCB, the user can use File > Import > Foreign Database to pull these layout changes back into the schematic.
Also, this 2007 Foreign iCDB flow methodology has been enhanced over the 2005 allowing constraint changes to occur within the schematic and layout concurrently. The process of importing the Foreign Database will use a merge process that did not exist in the previous releases.
I hope this information dispels and "odor" about supporting this type of flow in 2007.
ExpeditionPCB/XtremePCB Product Marketing Manager
I do not understand fully the foreign icdb flow as I think that the pcb designer should also have the schematics for understanding the design and cross probing.
I always want to keep an integrated design structure even if I want to do some work out of the company.
I am thinking that I would send the PCB designer a full copy of the design.
While the designer is working on the PCB, the engineer may work on the schematics on his original directory.
Than when I get back the work, tools>foreign icdb>import the icdb from the designer's copy of the design (resolve conflicts)?
Merge the PCB directory by copying it to the original directory (forward annotate)?
does it make sense?
Does this relate to DC, DX or both?
I'd like to provide a little information about the DC to DX translation process. My job here at Mentor Graphics is to help customers migrate to our latest software so I have worked with many customers making similar transitions.
Our goal for the translators is as Chris mentioned - they are intended to be as simple as possible, out of the box. As translators go, DC to DX is one of the simplest I have ever seen. It definately is not a bunch of scripts, it is one menu-driven application.
In the 2005.3 version of the translator, we use EDIF behind the scenes as part of the translation. But the EDIF is enhanced by the translator to adapt it better to the task. It is not the same as simply writing EDIF from DC and importing it into DX.
In the 2007.4 version of the translator, soon to be released, we have removed EDIF from the process altogether. This simplifies the translation and makes it even more accurate. My team, and AE's working with companies like National Instruments, are using pre-released versions of this new translator with good success.
What we normally recommend is that an AE or support person help the customer through the first translation as a learning exercise. After that, the goal is for the customer to be able to convert designs themselves with little assistance. It sounds like our approach is aligned with what those in this forum have in mind. We are open to suggestions for additional improvements to make the translation as seemless as possible. You can log these suggestions through the normal customer support processes.
Customer Migration Team
Systems Design Division, Mentor Graphics
We have been migrating designs from DC2005.3 to DxD7007.3 for some time. It is far from being a simple automated process and frequently requires manual intervention. For example, there is a problem with the way that the migration tool handles the conversion of bus rippers. Admittedly, some of the problems that we have seen are 'problems of our own making' but this just serves to highlight the fact that DC was more tolerant than DxD is.
My advice would be to wait and see what the next release of translator brings before you make the decision - especially as the next version is imminent.
Yes its DC2DX translator is really working fine. Following are the difference we found when we translate DC library to Dx
1. Font in DC is Default will be get converted to nearest match to sanserif.
2. size of the font in Dc (0.080) will be scaled 1:1 but unit displays is 8
can we make these above two items as same as DC.