0 Replies Latest reply on Aug 19, 2014 1:28 PM by dave_brady

    The IOD "Flow Styles"

    dave_brady

      If you are a new user of I/O Designer it may not be apparent that there are multiple methods (or "styles") of deploying I/O Designer across your flow.

       

      I/O Designer supports two primary flow styles:

       

      • Schematic Generation Flow style

       

      • Schematic Update Flow style

       

      The Schematic Generation Flow style was the first style implemented in IOD (I/O Designer). While this is a powerful design flow style it does have some limitations that users should be aware of. This article will describe both the strengths and limitations of this flow style.

       

      The Schematic Update Flow style grew out of working with and listening to our customers to meet their diverse needs. From my perspective the schematic update flow style is a superior style and from an enterprise deployment perspective it is the "only flow style" but before I make that argument I should lay out the capabilities of each style.

       

      Schematic Generation Flow Style:

       

      • As the name indicates IOD "generates" the FPGA connectivity schematics including instantiating the FPGA symbol (fractures) on the schematic

       

      • This flow style requires a hierarchical design structure

       

      • The FPGA symbol fractures are local to the project (FPGA symbols are customized for each project)

       

      • The PDB (or part mapping -- symbol pins to footprint pins) is local to the project: If you are not careful you may delete the local FPGA PCB when you package the design (not too big of a deal as you simply re-generate the PDB from within IOD)

       

      • The generated schematics may NOT be edited by the user: Since they are generated (and re-generated) any user edits will be lost when re-generation is run from IOD

       

      • This flow style requires more user expertise with IOD: You need to know WHEN to run synchronization tasks and you also need to leverage the rich feature set of IOD to work through the complete flow process.

       

      • FPGA components are not included in DMS (if you use DMS) since they are project specific (local).

       

      Schematic Update Flow Style:

       

      • This IOD flow style simply "updates" the connectivity of schematic

       

      • This flow style supports both FLAT and Hierarchical design structures

       

      • The FPGA Symbol fractures are normally placed in the Central Library (and are re-used across multiple PCB projects) -- the option exists to use the symbol fractures locally (within the project)

       

      • The PDB (or part mapping) is normally placed in the Central Library (and re-used across multiple PCB projects) -- the option exists to use the PCB locally (within the project)

       

      • One of the advantages of this flow style is that the FPGA (as seen by the PCB) is a normal component in your library just like any other component you may use on your PCB

       

      • FPGA Components are supported by DMS (if you use DMS) since they are normal PCB components.

       

      • FPGA Symbol (Fractures) are manually instantiated into the design (just like any other component in the design) --- this may be the only significant limitation of the schematic update flow style when compared with the schematic generation flow style.

       

      • FPGA Symbol (Fractures) may be mixed with any other components on the same schematic sheet (the update process "updates the connectivity" it does not re-generate the schematic so user edits are never lost)

       

      • This flow style divides the design process along traditional team boundaries: Component Librarian, PCB Functional Designer, PCB Physical designer aligning with historic (traditional) design practices.

       

      • IOD usage within this style is greatly simplified (both from a learning perspective and a command set perspective)

       

      The benefits of IOD:

       

      • Correct by construction signal to FPGA pin assignment

       

      • Generation of FPGA Symbols (Fractures)

       

      • Synchronization of the FPGA interface between the FPGA and PCB design domains

       

      • Automatic maintenance of the connectivity within the schematic as FPGA pin swaps are performed

       

      • PCB Optimization (using the flexibility of the FPGA IO to shorten PCB trace lengths and minimize PCB trace cross-overs)

       

      is consistent across both design flow styles. The "end result" is the same for both styles but the process for achieving the result is different.

       

      The Enterprise Connection:

       

      Personally, I would recommend the Schematic update flow style to any size company: small, medium & large for the simple reason that this style is the result of working with many customers across several years and consequently it provides more design structure flexibility. The only aspect of the design process automation that is not available is the automatic instantiation of the FPGA Symbol fractures in the design schematic.

       

      However, if you are working in an Enterprise level corporation the schematic update flow style is really the only viable process due to the support of the Central Library as well as the ability to promote the FPGA component to DMS.

       

      Sometimes, it is the corporate culture that dictates process.  For instance, if the only person (people) who is (are) allowed to add a component to the central library is (are) the librarian(s), then having the PCB functional engineer generate the FPGA symbol fractures and PDB is akin to swimming up-stream. With the schematic update flow style the resolution is simple: The Librarian uses IOD to generate the FPGA symbol fractures and PDB to create a part in the central library.  Subsequently the FPGA component is available to the PCB functional designer to instantiate in the design just like any other component they may use in the product design process.

       

      When the Librarian uses IOD in this manner they are using a distinct sub-set of the IOD command set to accomplish a specific purpose: create a generic FPGA component for inclusion in the central library that may be used across multiple design projects.  Since the Librarian is using IOD for the component generation process the PCB functional designer, FPGA designer and PCB physical designer never need to learn how to use IOD for generic symbol generation reducing the IOD commands that they need to be familiar with (reducing the amount of time required for them to learn to use the tool in the flow).

       

      This point is subtle but important: In the schematic generation flow the PCB functional engineer is creating the FPGA symbol (fractures) and using them locally within the context of the project. Therefore, the PCB functional engineer MUST be competent with the IOD command set for creating and maintaining project local FPGA symbol (fractures). If the PCB functional engineer determines that they want project specific (custom) FPGA symbol (fractures) they will re-generate the local symbols anytime there is a change to the connectivity of the design (this is an option in the schematic generation flow that is not available in the schematic update flow). However, this does require more user expertise with a larger command set within IOD.

       

      Personally, I like to keep things simple.  I would prefer to treat the FPGA component just like any other component in my product design AND be able to use IOD Optimization to leverage the flexibility of the FPGA IO to shorten PCB traces and minimize PCB trace cross-overs (minimize vias).  This is the reason I prefer and recommend the schematic update flow style when using I/O Designer... I only need to remember a few basic IOD commands and I am able to focus my energy on design tasks instead of PCB component maintenance tasks.

       

      Is it possible to mix IOD flow styles in one design project? It is, but it is also a recipie for disaster if you are not an expert user of IOD.  I strongly advise users to pick a flow style and stick with it.

       

      I