0 Replies Latest reply on Mar 29, 2016 3:52 PM by urb

    PADS Integrated flow issues - Noob

    urb

      I've started using xDxDesigner again after a five year absence. Previous I used a netlist flow, the DxDesigner tool stored the data in an ASCII format. This allowed direct manipulation of the schematic sheet and component 'database' using perl and VBS scripts without using the COM API. The output of the schematic was a netlist and BOM, which was handed off to an outside layout shop where Allegro was used for PCB layout.

       

      I'm now using PADS Standard Plus, and the xDxDesigner schematic tool tool flow alone is quite a departure from the legacy flow, which is expected. I've inherited a design that has the following heritage:

      1. Schematic design was originally created in DxDesigner version 9.5 using a netlist flow
      2. PCB layout was done in PADS 0.5
      3. Schematic design was converted to VX1.0 integrated flow, non-DxDatabook

       

      I will be using this design at the basis for a derived design. One thing we want to do is to preserve all of the DDR3 routing to the FPGA, as this is critical routing and already proven in production. At the time the design was handed off to me the legacy PCB layout had not be synced to the xDxDesigner schematic project that had been migrated to a an integrated flow. Before modifying the design I wanted to be certain that I was starting with a clean, integrated, schematic+PCB PADS project without errors.

       

      As the design was handed off to me we upgraded our tools from VX1.0 PADS Suite to VX1.2 PADS Standard Plus. My first attempt to integrate/sync the legacy PCB design with the VX1.2 integrated flow using forward annotation to PCB generated a number of (at the time) puzzling changes to the layout.

      1. All of the DDR3 signals were unrouted. A closer examination of the net names in the PCB file and those created by xDxDesigner had the following difference: all of the PADS layout nets had a $1I866~ prefix while the exported DxDesigner netlist didn't have the prefix. Just to add to the confusion, prior to using the PADS 'Setup->Project Integration', the DDR3 net prefixes were '$1I866\' - note that the prefix separator changed from '\' prior to the first project integration attempt to '~' after the integration attempt. Here are two example nets from xDxDesigner and PADS after the integration attempt.
        • xDxDesigner:  DDR3_DQ45
        • PADS:  $1I866~DDR3_DQ45

       

      QUESTION 1: How can I change the PADS net names in an automated way so that the prefix can be eliminated and thus the PCB layout netlist will match the schematic? I assume there's a way to supply a was/is list of netnames to PADS Layout. If someone would kindly point me to the correct place in the documentation where this is described that would be most appreciated.

       

      In the process of attempting to sync the newly integrated flow schematic to the PADS layout I noticed that many of the referenced designators in the schematic had been reset to X?, where X is the appropriated device prefix (R, C, U, ...). The crazy thing is that some of the schematic sheets half of the reference designators on a page retained the values from the legacy design (the desired behavior) while the others were reset. I painstakingly restored all of the reference designator in the schematic that had been reset to those of the legacy design (and hence in the legacy PADS design). After I did this a future attempt in PADS to set up Project Integration with the schematic reported some differences in decal names between schematic and PCB for a handful (less than 10) component instances.

      In examining the schematic I could see that the PKG_TYPE attribute value in the schematic symbol indeed didn't match the PADS decal name. In fact, there were no decals in the central library that matches the name in the xDxDesigner PKG_TYPE attribute value for the component instances in question. Further examination showed that there was no decal name defined for the central library parts in question. My attempted solution was:

      1. Examine the decal name assigned in PADS Layout for the parts in question
      2. Verify that these decal names exist in the central library decal folder
      3. Add these decal names to the central library parts in question
      4. Attempt to repackage the xDxDesigner schematic.

      My assumption was that the central library decal value for the parts in question would override the PKG_TYPE values from the symbol, but this was not what happened. The netlist created by DxDesigner used the PKG_TYPE values from the symbol for the package type. I changed the 'Cell Name' attribute on the schematic for these components to match the decal values, but when running packager I got errors about a mismatch between symbol and schematic level attributes. I finally realized (after reading packager error messages closer) that I needed to check the 'Update Local Library Data with newer central library data'. After selecting this I was able to get the packager to run without any errors.

       

      QUESTION 2: Why is the 'Cell Name' property on an instantiated component used to pass the decal name to PADS Layout (or other layout tool)? I read the 'Cell Name' description in the PADS Schematic Design Properties Glossary, PADS VX.1.2 document and it wasn't obvious or clear to me.

       

      After making the above decal associations with the central library parts in question, I was able to get the packager to run without errors. Now here's the puzzling part... When I attempt to 'Setup Project Integration' in PADS Layout to the xDxDesigner schematic and 'View report' for Forward Annotation I get the following error message from PADS Layout.

      1. Copied legacy PADS 9.5 file and renamed.
      2. Opened renamed PADS 9.5 file in PADS VX1.2
      3. Setup->Project Integration
      4. Select project name and board name from project
      5. Wait for PADS layout to sync to project. It's after this step that the instance part of the PADS nets changes from '\' to \~'

      For context, I'm including all of the messages that result from 'Setup Project Integration'. Here are the steps I used to attempt to sync the legacy PADS 9.5 layout file to the VX1.2 Integrated project.

      Rule conversion report file saved - -- C:\projects\Phase 1\Electronics\pz_carrier\schematic_layout\pz_carrier\pz_carrier_RuleConversionReport.log
      Net conversion report file saved - -- C:\projects\Phase 1\Electronics\pz_carrier\schematic_layout\pz_carrier\pz_carrier_NetConversionReport.log
      Can not access connectivity data. Make sure the project is packaged.

      For reference, here's the last few lines of the packager for the project that I'm attempting to integrate the PADS Layout design with.

      No errors in Existing Schematic Packaging.
      Packaging has been successfully tested with no errors or warnings.
      Copied from Log File: Integration\PartPkg.log

       

      QUESTION 3: Why is PADS Layout unable to access connectivity data from the xDxDesigner schematic for the purpose of forward annotation, even though the packager reports no errors.

       

      GENERAL QUESTION: What is the recommended reading material that gives a higher level/philosophical view of how all of the various pieces of PADS Standard Plus all fit together when doing a design? I'm sure it's all in the docs, but there are so many moving parts - symbols, decals, central libraries, DxDatabook, integrated flow, netlist flow, attributes, properties, system properties, common properties, etc, - that at times it's not clear how it all fits together...unless one already knows how it fits together. I've been through the PADS Standard Plus evaluation training. Maybe I should revisit this. Any suggestions are welcome.