3 Replies Latest reply on Dec 11, 2013 6:46 AM by randall_myers

    the need to rename pcb symbols


      Is there any plan to change I/OD so pcb symbols do not have to be renamed when pins are added or removed after initial exportation?

        • 1. Re: the need to rename pcb symbols

          Hi John - I work with I/O Designer in a couple of different design flows within Expedition Enterprise. 


          My favorite is "schematic update" where the PCB symbols on the schematic are generally fixed and the changes to pin assignments are reflected in the schematic by changing the nets connected to the pins of these PCB symbols.  Generally all the pins of the FPGA are on a PCB symbol somewhere, but pins can be moved around between symbols by updating the symbol set and part, preferably in the library.  I don't see a need to rename PCB symbols with this use of I/O Designer. 


          With schematic update, you could generate the whole set of fractured symbols for the FPGA (and the part "PDB") from I/O Designer, or you could build it from scratch.  You could leave these symbols fixed and instantiate them as a generic part in multiple projects and keep the design specific optimization done in the net connections.  This means you don't need to change your PCB symbols, but you could.  The only limitations there are the normal schematic, DxDesigner, rules.


          Another method is schematic generate, giving I/O Designer a whole schematic block to re-write the FPGA symbols and connections.  Since these are re-written and controlled by I/O Designer on a schematic page the user is not supposed to edit, I don't concern myself with the PCB symbol names much.  So, this doesn't sound applicable to your question.


          FPGA's are so flexible it is hard to spell out each way they can be used.  The Expedition Enterprise design tools are also pretty flexible, allowing different approaches to solve the same design challenge.   If you have a stumbling point that is likely common, let's go further on the forum.  If you want to go deeper into a specific way of using Expedition to design with FPGA's, my email is randall_myers@mentor.com


          -- Randall

          • 2. Re: the need to rename pcb symbols

            Hi Randall,

                 Thank you for your answer.  I know the preferred method in I/O Designer is to use Schematic Update.  But, our engineers are stuck at Export > Schematic and Symbols.  My reason for asking the question is because I am considering submitting an Idea suggesting the software be changed/updated so it is not necessary to rename symbols when certain changes are made to them, such as the pin count.  Or the part number, for that matter.  If this code change is totally impossible and that is known, I would refrain from submitting the idea and just tell my users they have to deal with it.  But, if it is a possibility, then at least presenting an Idea gets it on the table and lets other I/OD users chime in.



            • 3. Re: the need to rename pcb symbols

              Submitting ideas for improvements - YES

              We like customer posted ideas; definitely don't hold back.  We have developers working on improving the FPGA design process.  At least a couple of us have FPGA development experience, so you can get technical / specific.   An adjustment to a current design flow is a very focused idea.  When you submit this idea, it may help to add a little about why.  For product definition we ask the general question - What causes the user pain or tedium that we could alleviate with a feature or change.


              And - creative ideas

              You can also submit, "would be nice" general ideas, such as - I would like schematic update better if you moved the pins instead of the nets.  Or -- Could you make unravel within a group available as a push-button tool within ExpeditionPCB...  and I should stop there before I promote too many of my favorites.


              And - Forum & Beta

              Speaking up helps.  The technical lead, product manager, and I have regular meetings.  Another avenue of influence is being a beta reviewer.  I'm pretty enthused about what is in in the pipe for 2014.


              And - AE's

              Our field engineers are sharp, they listen, and in turn give development an earful when needed.