Before doing the migration review the settings in the viewdraw.ini file for the library pointers, there is an issue with capitalisation of some paths (now resolved in the forthcoming release of DxD). In the current version the drive letter needs to be specified as a Capital letter, so C:\ instead of c:\. Also ensure the libraries are where the viewdraw.ini file says they are, if during migration DxDesigner cannot correlate the symbols with the library names (aliases in 2005.x DxD) then it will move the symbols to be 'local' to the project and place them in the SYM folder co-located with the project directory.
Once you have replaced all the local symbols in any existing design you should be able to delete them from the local partition via the GUI, select the symbols and use the context menu on the Right Mouse Button - Delete Local Symbols.
Let me know if this solves the problem.
Product Marketing Manager
looks like this is very similar to what we're doing right now.
We've created new DxD libraries according to the latest rules (obsolete properties etc.), i.e. we can not point to the "old" libs.
Instead we're replacing the components via automation *after* migration - no problem so far.
The [local symbols] can be deleted via GUI as soon as the replacement is finished, i.e. they are not used any longer -> preview window is black.
All I want to do is to SelectAll->DeleteAll or do it via automation. Deleting >100 symbols step-by-step is not a reasonable way ...
How do you reference the 'new' libraries in the 'old' design. If you've changed the paths the migration will localise the symbols. It is important that you keep the paths the same or update the pre-migrated design to use the new symbols. In the GUI you should be able to select all of the local symbols and delete them in one step (in either View - Symbols or DxDataBook - Symbol View, depending on which vserion of DxD you're running).
I have some questions about your process, particularly about the changes you are making to the symbols, if you wish to discuss these further then email me directly at firstname.lastname@example.org
we do not reference the new libs in the old design at all.
non-iCDB Designs (PADS 2007 flow) are using "old" libs. Exactly those libs (specified in .dproj file) are still available.
During migration the localisation happens - it would be nice to prevent DxD from doing this.
Will have a look at the driver letters (case sensitive) as you've suggested ... but usually they are referred to as \\servername\share\subdir\lib, i.e. no letter at all.
After migration a script matches "old" symbols to new ones by symbol name and issues "ChangeComponentPreserveRefdes".
Since v2007 will keep on running (we won't migrate all projects !) the current DxD must not touch the libs.
DxDB ("CL View") doesn't allow multiple selections - delete all doesn' work. I have no view->symbols available either.
Will do some more tests and send an update.
Just to clarify, the new DxD doesn't touch the libs if you're using the PADS netlist flow. This is why I have questions about your process and what you are migrating to what! Is it simply upgrading PADS2007 (DxD 2005) to PADS 9.x (DxD2007) in the same flow? Are you moving from PADS netlist to EE iCDB flow or some other combination?
we're running PADS netlist flow and want to migrate from PADS2007 to 9.x.
Let's describe how the migration is done :
1. copy project folder
viewdraw.ini looks like this :
|8.1 GROUND_SYM UntestedLib:gnd.1
|8.1 POWER_SYM UntestedLib:vcc.1
DIR [p] .
DIR [w] \\triton\vision\hw\_MentorGraphics\UntestedLib (UntestedLib)
->no drive letters at all. Everything local to the project or in the distributed library (=UntestedLib) which is available.
2. Open DxD and load Project.
3. Start Migration
Looks like DxD doesn't know about properties created by other tools of the PADS Flow ... especially DxDB and OATs.
The following design attributes are not DxD common properties:
All definitions of common properties are stored in C:\MentorGraphics\9.0.2PADS\SDD_HOME\standard\netlist.prp.
Copy this file to another location, use the Properties Definition Editor to add
missing properties if needed, and point to the new file in the Settings dialog. See The DxDesigner Administrator's Guide in the InfoHub for details.
4. Examine Libs and Symbols :
UntestedLib and local library (unnamed) are available - ok.
[local symbols] has also been created containing all used symbols.
The picture shows a filtered view of a processor's fractured symbol - I would have expected no localisation.
What I have to do is visit each fracture and issue symbol replacement.
Afterwards I'm allowed to delete the localised symbol one-by-one.
That's tedious work.
If these steps are not performed I'm unable to get symbol updates from the distributed lib since the localised ones are valid forever.
Again : selection and removal of multiple localised symbols is not possible ... at least for me.
Let me know if I'm doing something utterly wrong.
You cannot selest the symbols in the local partition via automation and unfortunately in the version of DxD you currently have you can only delete one symbol at a time. In the version I am using you can select all of the symbols and delete them in one step.
We are continuing to improve the migration process to address issues as they arise, for the specific issues with local symbols that you are seeing it would be better to log an Service Request with your support organisation, that way we can track it in Mentor and try to reproduce the issues you are experiencing.
If I find out any more information I will post it back here.