Migrating a Project to another FPGA

You choose an FPGA when you create your project. But later, you may want to migrate your project to a different FPGA. The new FPGA you select may not have the same features as the existing one, and some resources may not have the same names. So when you choose a new FPGA in the Project Editor, the Efinity® software automatically performs a design check in the background to help you migrate the design. You see a message at the bottom of the main window that the software is checking for migration issues.

Note: Trion and Titanium FPGAs have different configuration settings. Therefore, when migrating designs from the Trion family to the Titanium family, the software resets any incompatible configuration settings to the default.

The software generates a detailed log of the interface changes it makes during the migration and saves it into the <project>/work_pt directory.

Automatic Migration

If the new FPGA you choose is similar to the existing one (for example, you want to change from the T13 in the BGA256 to the T20 in the BGA256), the software can migrate all the assignments automatically and gives a message that migration completed successfully. You do not need to do anything else.

If the two FPGAs have different interface resources (GPIO, PLLs, etc.) but they are pin and package compatible, the software migrates the assignments automatically. The user design instances will be preserved but some resources may be automatically reassigned.

Migrate Design Wizard

If the software cannot migrate automatically, it launches the Migrate Design wizard. This wizard helps you decide how to handle the changes. In the first pane, the wizard:
  • Shows the issues it found, for example, GPIO feature differences.
  • Asks if you want to create a new interface design or update your current one.
  • Lets you back up your existing interface design so you can go back to it if needed.

In the second pane, the wizard shows the assignments that have problems. If you decide to continue migration, the wizard opens the Interface Designer so you can fix the problems. You can also cancel to stop migration.

Note: If you cancel migration and keep the new FPGA setting, the Migrate Design wizard opens again the next time you run the Interface Designer.
Note: For help understanding the messages, refer to the "Design Check" topics in the Titanium Interfaces User Guide. These topics describe the messages the Interface Designer generates and gives suggestions on how to fix errors and warnings.

The outcome of design migration depends on the FPGAs involved because each FPGA has its own unique interface and resources, and each interface block supports specific features. Therefore, migrating the design from one FPGA to another is limited to the interface block support available in the destination FPGA.

Migrating a design from one family to another requires manual modification in the post-migrated design. Different families have different architectures, and therefore different features. However, the software tries to preserve the instances that have already been created if the interface block is supported in both FPGAs despite having a different feature set. In this case, some of the configuration settings may be reset to the default in the migrated design.

The possible outcomes for instances when migrating a design are:

  • The instance is retained but resource assignments are removed.
    • In most cases, the interface block instance is preserved but the assigned resource is removed because the resource does not exist in the destination FPGA or you are migrating between families.
    • The instance is retained but the feature set is different. Refer to the migration log in the wizard to understand the differences. For example, when migrating from Trion FPGAs to Titanium FPGAs, the GPIO instances are preserved but different, additional, or incompatible features are set to the default.
  • The instance is removed.
    • If the new FPGA does not support the interface block, the block is removed. For example, migrating a T20F324 design with LVDS RX instantiated to the T8F81 (which does not support LVDS RX) results in the LVDS RX instance being removed.
    • If the new FPGA has the same block but the block's features are completely different, the block is removed. For example, migrating a T120F576 design with DDR instantiated to the Ti180G529 (which supports DDR but with a completely different configuration) results in the DDR instance being removed.

The Device Setting stores information related to I/O banks and FPGA settings. In Titanium FPGAs, it also includes the Clock/Control configuration.

Device Settings are migrated as part of the design migration process. The outcome of the migration depends on the setting compatibility between the FPGAs. If the setting is not compatible, it is reset to the default value for the destination FPGA.

  • I/O Bank configuration is migrated if the setting is valid or applicable in the destination FPGA. For example, if Bank 1A exists in the destination FPGA, the voltage indicated for this bank is migrated if the destination FPGA Bank 1A supports the voltage value. If the destination FPGA Bank 1A does not support the voltage, Bank 1A in the migrated design is reset to the default voltage.
  • Clock/Control configuration does not exist in Trion FPGAs. Therefore, you cannot migrate any settings between Trion and Titanium FPGAs.