2 Replies Latest reply on Feb 7, 2014 6:26 AM by jtaylor

    refdes instance values not created in blocks after forward annotation

    jtaylor

      I have a hierarchical design that seems to be having packaging issue(s). Up to this point I have done only flat designs. PADs 9.5 update1/DxD.

       

      The design is two level, with one block repeated 4 times in the top level. The block has refdes assigned at the block level. After running pcbfwd to PADs, all components show up as they should in the pcb, but with unique refdes.

       

      Checking the schematic after forward annotaion reveals that refdes in each instance of the block are not updated to match the values assigned in the pcb. Back annotating does not alter anything on the schematic either. Pushing a block from the top level and looking at the refdes property of any symbol shows only a block value assigned. Pushing each block individually reveals that all the refdes match for a given symbol within the block.

       

      Also of note:

      * the block contains named nets. These are tied together between blocks in the layout (!!!) this is not the design intent

      * type 4 hetero symbols that have otherwise worked in flat designs are packaged individually

      * pcb.err shows many 6046 and 6049 notes (device conflict and duplicate slot, respectively)

      * adding the Refdes Suffix=x (x= A, B, C etc) property to the block symbols on the schematic has no impact on refedes (Refdes Renumber = Refresh appeared after doing this)

      * Assigning refdes at the top level does not change anything either

       

      As far as I understand, having multiple instances of the same block within one design is intended behavior - and from what I have read here and seen in tutorials, Support net etc. it works for others using DxD.

       

      My only thoughts are that the pads95.cfg file is not setup correctly - are the DoOats/BeginOatAtts/EndOatAtts required for this to work?

      Or do I need to manually assing instance values to each block?

       

      The crux of my query:

      -get unique refdes back from layout on schematic

      -uniquely identify each block on sch so when the full sch is printed, the seperate block sch can be referenced to its location

      -hetero parts packaged correctly

      -named nets not tied between blocks

       

      Any help/input is greatly appreciated.

        • 1. Re: refdes instance values not created in blocks after forward annotation
          robert_davies

          Based on the number of questions in this thread you should contact your customer support organisation to try and get resolution. We've not had any other reports of such issues and checking this morning we cannot reproduce similar issues. What does the .asc file list for the parts? Can you create a small block in a new project, add a few components, create another instance and package this design, going from DxDesigner to PADS but checking instance level REFDES before opening in PADS. It all seems to be working as expected in a simple test case, no interconnected nets between blocks even for nets with the same name that shouldn't be connected.

          Are you using the correct hierarchical port connectors inside the block to map between the block and the underlying schematic. Are the nets at the top of the design unique per block etc.

          The RefDes Suffix property is not intended for the PADS flow as far as I am aware, it isn used in the Expedition flow. Somebody with greater knowledge of PADS may correct me on this point if this is not the case.

          • 2. Re: refdes instance values not created in blocks after forward annotation
            jtaylor

            Robert,

            Thanks for the reply. As it turns out, the the pads95.cfg file was modified - possibly a previous user? Anyhow, a quick diff in a text editor showed a few issues, the key being that the "pkg device" property wasn't listed under specific attributes to pass, but under general. Fixing that got the refdes and backannotation working just fine.

             

            As for the hetero devices, I misspoke - it was a type 2, NOT a type 4. From what I understand, a type 2 can't be used in this type of design - when the external nets are resolved into the block instance, they end up conflicting with the net names on the signal properties assigned to the type 2 hetero devices. A net alias might work or if the power nets weren't connected to IO pins. My solution was to change them into type 3 devices.

             

            As for uniquely identifiable information on eash block instance, I added a refdes to the block.