UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 

Device Migration

Xilinx Employee
Xilinx Employee
1 0 1,393

If you already have a design and want to target the design to another part, this blog post will help you to identify the steps that would be needed for the migration.

This post does not cover targeting to a totally different family, where the parts are totally different in terms of the underlying components. 

You should refer to specific Migration Guides for such migration, such as UltraScale to Versal migration.This post is for migrating across families which are generally similar.

RTL portion of your design:

The pure RTL constructs in your Verilog/VHDL code should not require any change.

Most instantiated primitives should not need any change. Vivado tool flow will replace the instantiated primitives with the equivalent ones for the targeted part.

There may be some specific primitives which may not be re-targetable depending on your combination of original part selection and the

re-targeted part. In such cases, you will need to manually find out the closest equivalent functionality, and replace the primitive.

Take the RTL through one round of synthesis. Do not worry yet about the right timing constraints or, even optimal synthesis.

Now, look carefully at the synthesis log file. If you get messages related to certain primitives that could not be understood by synthesis, these are the primitives that you need to manually replace.

Also look at Critical Warnings, if certain primitives have been re-targeted, but, functionality is no longer being guaranteed.

Using synthesis log file to identify primitives that may need change provides you with a quick way, rather than having to go through all your RTL files.

 

IP portion of your design:

If your design has IPs, you first need to check, if the same IP is still available on the re-targeted device.

Most of the soft-IPs should be available on your new target device. However, the hard-IP may or may not be available, depending on the target device chosen. 

The first thing that you want to do is to “Upgrade” your IP.

Review the IP documentation and/or the ip_upgrade.log file, which should contain details on what parameters/pinouts got changed. Ip_upgrade.log file is found in your project directory.

For all your IPs, you should quickly review the parameter customization. In general, your customization for the IP should be retained. However, in the new architecture, there might be some additional parameters, or, some parameters that no longer are applicable/available. You want to see that with the current set of parameter customization, you still have the desired functionality of each IP.

Similarly, pin-outs could have also been modified. You need to review the pin-outs and if needed, change the connectivity to the instantiation of the IPs.

And, “Generate Output Products” – for the new part.

Even if you had the “Generate Output Products” done prior to change of parts, those output products may no longer be meaningful, and, need to be regenerated.

 

IPI/BD portion of your design:

IPI/BD portion of your design should be very similar to the IP Portion.

First check, if the IPs being used in your BD are also available in the target architecture.

For the BD portion of your design, run “Report IP Status”, and, Upgrade the suggested IPs. In general, it should suggest an Upgrade for all IPs being used in the BD.

Review the ip_upgrade.log file, which should contain details on what parameters/pinouts got changed. Ip_upgrade.log file is found in your project directory.

Check on parameterization of each IP. Some new parameters may have been introduced, or, some old ones may no longer be valid. Similarly, pin-outs may have been modified.

If pinouts got changed, you should be able to make use of Connection Automation to add missing connections.

Once the BD is ready for the new architecture, “Validate BD” and “Generate Output Products” for the BD after successful validation.

Check that the BD level pin-outs are still unchanged. Else, revisit the HDL where the BD is instantiated and update the connectivity of the BD.

 

IO Planning:

Depending on the pinout of your new device, redo the I/O Planning, if needed.

 

Implementation Steps:

The entire set of Implementation – including synthesis should be done afresh for the new part, once the IPs (either from the Catalog or the BD) have been Upgraded.

Any implementation strategy, directive, floorplan/LOC constraints should be reviewed if they are still relevant, or even valid.

 (Acknowledgments are due to Glen English, from CortexRF for suggesting the topic, as well as confirming that the flow works fine on his migration effort).


About the Author:

Sanjay Churiwala is a Sr. Director at Xilinx with technical expertise in STA, clock domain crossing/synchronization, power, synthesis, simulation, rule-based static checkers, cell characterization and modeling, and Xilinx design tools. 
The recipient of several international patents, he has also written multiple technical books, published by Springer, New York and Europe. In addition, he has also published many articles and papers in trade journals, conferences, and popular newspapers in multiple countries. He is also a regular contributor to the Xilinx Adaptable Advantage Blog.