Does anyone know if there is a configuration file somewhere that controls this? I will have to touch every part to fix this and other parts fields that were thrown away in the migration process.
It's not a configuration, there is an issue. I found that when I import a part with a CLK pin, some other pins in the part are zero length, the decal outline is affected. I've been working with Mentor on this, there are a couple workarounds being documented, and they are working on the problem. It would be a big help if you contact support so you can share your library for their investigation.
Try importing just a couple parts, see if you get zero length pins. You may be able to narrow down the problem a bit.
Depending on the size of our library, and how you use Logic symbols (shared, or new for each part), you may be able to get better results using the Netlist flow to convert symbols, then the Library Migrator to assign them to Part Types.
I have been trying to contact other users who are migrating from Logic to xDx with the new VX release. I have started another discussion for this topic: Anyone else migrating from Logic to xDxDesigner?
I have been talking with tech support about the zero length pins. Some symbols make it and some don’t make it correctly. The guy I talked with said they are working on publishing a paper about the problem.
Things seen to work better going from Logic ==> Netlist Flow ==> then Integrated. I have several user properties that I would like to keep and that is the only way to do so. It seems no decals make it through when you do this way. How do you assign a decal if none make it through the netlist to integrated migration ?
If I import my libs into the migrator I end up with almost double symbols for each library. I think I finally figured how to import and get the correct decal info for the symbol. I still have improper pin length issues to deal with.
I guess marketing made the schedule for the central library migration tool!!
It has not been dull for sure.
I get the impression there are not a lot of us who are trying to migrate PADS Logic libraries into the new Central Library.
The real problem is that Logic libraries are Part Type driven, and xDx libraries are CAE Symbol driven. Many of us built libraries with a lot of Part Types using a few CAE symbols. xDx doesn't like that. See the link to the other discussion for more detail.
The Netlist Flow translator seems to be MUCH better, and more complete. But it then wants to use each symbol for one part type only. Using that conversion created hundreds of exactly identical resistor symbols, all with different names and all Part Type information in each symbol. Using the Central Library Migrator allowed me to create hundreds of resistor Part Types that use one CAE Decal, but each have their own attributes and footprints. But then, the translation problems on some parts. I've been using a combination of Netlist translation, copying files, Central Migration, VB scripting, manual massaging - and I still can't get the library I had with Logic. I still haven't decided if I'll use it or wait for another update.
I guess it would have been too much - a fundamental change to the xDx structure - to use the Part Type driven library. But that's really what needed to be done to get people to finally move out of Logic. It's just a much more sensible way to structure a library.
Actually xDX Designer is not really CAE Symbol driven when used in a Central Library flow, but is of necessity in a netlist flow. However, we are aware of the issues you are having and working to address them, the main issues lie in the translation process as it currently stands.
First, I DO appreciate all of the effort that is going on to fix this. Everyone I've been in contact with has been very helpful, and they seem to have a good understanding of the issues.
The reason I say the Central Library is schematic symbol driven is this: The pins for a particular part must be assigned to the schematic symbol. For instance, in Logic, I can take a generic 6 pin box symbol, assign it to 3 different Part Types, then assign different pin names and numbers, even adding different quantities of signal pins if I want. I can make different sets of pins swappable if I want. I can assign this box as one of multiple gates in another Part Type, and make those swappable, even if I have alternate symbols for each gate. But in xDx using the central library, since the pin names must be assigned in the schematic symbol, I can only use a generic symbol if I use the same pin names for all Part Types using that symbol. As xDx wants a specific symbol for each Part Type, with all part information in that symbol, I can not use alternate gate decals for gates and have the gates be swappable.
In PADS Logic, schematic symbols carry generic place holders for pin information that is assigned by Part Type. There is no electrical information in the symbol, it is only graphical. In xDx, the electrical information is in the schematic symbol, which then restricts the way it can be used.
Am I missing something?
That's the point I was making, the Central Library is designed for generic symbols in the Expedition flow and was from inception 15 years ago. It is the current implementation for PADS that is the issue and one of the things being looked at by engineering to improve the process for Logic users migrating to xDX Designer with PADS. The issue is under the hood when managing the PADS library structure in the Central Library, you should expect to see improvements in the future.
Sent from my HTC
That's good to hear! I never used Expedition, only Board Station and PADS. So I've been used to different sorts of structure than the Central library under VX. I do want to move to xDx, I'm just reluctant with the current implementation. If the underlying architecture is right but the implementation still needs work, I can wait.
Reading you post in more detail (not on my phone) then there are some differences in the way 'generic' symbols appear in xDX Designer with a central library. The one difference appears to be that xDX Designer requires pin names to map to the PCB Decal, but that is all. It does (should) not need pin numbers, these are assigned from the definition in the part mapping (hidden behind the PADS UI). So providing the shared symbols have the same pin names the pin numbers can be different after packaging as can the swap rules. So if you have a single Op Amp symbol as an example, it can be used in different parts or with alternate PCB Decals (different pin-outs) providing the mapping uses the symbols Pin Names. In the netlist flow this is not the case as the pin numbers and PCB Decal must be defined (the net list is after all full packaged net list). Whether we are able to solve the 'no pin names' issue you have remains to be seen.
However, I didn't want PADS Logic users to be left with the impression that we cannot support a single 'generic' symbol used by multiple different part types, even if it requires as a minimum 'Pin names'..
I had a successful part library migration after working with mentor Tech Support. For me the biggest help was adding the pin decals to the library plus the customized library property file. Everything came over nicely at first glance.
Lyle, can you explain bit about adding pin decals to the library? I didn't think the Central library used pin decals.
I did find that the clock pin decal in the Logic library was causing the zero length pins. If I edited that decal, pins were created correctly in the migration.
It is not easy for sure.
I have been creating decal only part libraries in 9.x pads and saving them then import them into the new central library to marry my symbols and parts and it appears to work. This is just the start since we will end up touching every part as we go ☹…
I still have other issues to deal with.
I don’t mind the new concept. I have a fair quantity of unique parts that have been created as we went. I just wish they had done it better since they want us off of logic.
In the LOGIC library manager click on the "logic" button. I found most of the pin decals in the SSD_HOME\COMMON library and copied them into the library I was going to migrate. This fixed the error messages I had seen in earlier migration about not finding certain pins. I pulled in a library again yesterday after I removed most of the forbidden chars embedded in the name. So far all the symbols I have looked at are good. Symbols came through in the past with zero pin length looked good now. Bill in tech support has been a GREAT help in working through this. Also I copied PIN150_INV,PIN150, PIN50, PIN_050, PINEB.
hope this helps, sorry for the late response.
I did export pins with my library. I thought maybe you were referring to something else. I'm not sure how that makes any difference, since symbols in xDx don't use pin symbols, just lines. I still had problems with PINCLK causing corrupted symbols. Not only zero length pins, but the box outline was also wrong. I removed one of the angled lines from the pin symbol, the CAE symbols imported properly.
I have almost 4000 parts, individual edits on each part are prohibitive. I exported the libraries to ASCII, then wrote some VB to fix invalid characters, rename "Free Label"s, clean up pin names so the Migrator would re-use generic symbols, a few other clean ups. I am considering writing some post migration scripts to fix things like pin name locations and display, inverted pins, etc.
I've also had great help from the Mentor guys. They get that this is an issue and they want to fix it.
Thanks for all your input!
Retrieving data ...