Migrating Xilinx Projects

Tue 1 Jul 2014

I recently was given the task of updating a legacy Xilinx EDK v. 10.1 project based on the Processor Local Bus (PLB) architecture. The following are some of my notes written in a more concise manner. It is by no means a step by step guide. The information online regarding the update process is lacking at best and therefore this document might offer some insight.

Be aware that since Xilinx EDK v. 14.*, PLB systems are no longer supported. As such, if there are hardware limitations or other reasons you can’t convert your project to Advanced eXtensible Interface (AXI) architecture you’ll be limited to using Xilinx EDK v. 13.4 or older.

There are two ways to approach this problem:

  1. Use the automatic migration tools.
  2. Re-create the project in the newer version of Xilinx.

Using the automatic update wizard will typically cause Xilinx EDK to crash unless you are updating from the previous major release. However, a report will pop-up that will give you an idea of which libraries have been replaced and which don’t exist. This is extremely useful because Xilinx libraries are hard coded (e.g., a newer version of the library will have a different name and therefore will need to be changed in the custom HDL code). Hence, the second method will be considered in this notebook.

Initial Assessment of the System

In the event that there is no documentation you will need to find out the structure of the system. That includes both Xilinx libraries and any custom PCORES. The easiest method for acquiring that information is to first open the legacy project in the version that it was created. In addition to the above the address layout and the User Constraints File (UCF) may be useful.

Using this information you should be able to create a base project that defines the parameters of your platform. It should be trivial to add native Xilinx cores. Adding custom PCORES from previous releases requires a bit more work.

Updating and Adding Custom PCORES

Assuming you have the older versions of the custom PCORES you will first need to copy them to the new project directory. The automatic wizard for adding custom PCORES tends to fail because of the aforementioned issue. Trying to compile the project at this point will yield errors because it perceives the older libraries as missing.

Unfortunately, Xilinx renames their libraries with version names (e.g., plbv46_slave_single_v1_00_a has been renamed to plbv46_slave_single_v1_01_a with no major changes in the actual software – however, using the former will not work in newer versions). Henceforth, you will need to update any custom PCORE HDL code to reflect these changes. You might also need to accommodate for any unsupported legacy libraries in that code.

As has been mentioned above, the editing has to be done by hand. The files that need to be changed are:

  1. All *.vhd files found under pcores/custom_pcore_name/hdl/vhdl
  2. All *.pao files found under pcores/custom_pcore_name/data

It is also of importance to check that those libraries still operate under the same assumptions as when the code of the custom cores was written (to that extent it’s necessary to read the datasheets of the legacy versions and contrast them with the datasheets of the newer versions making sure that no major discrepancies exist in the operation of the library).

Refresh the user repository in order for Xilinx to read these changes. At this point you should have setup all your PCORES according to the old project (e.g., addresses in memory, frequency of operation, etc.)

Creating the User Constraints File (UCF)

Theoretically, as long as you kept all the options equivalent to the older version the UCF should be the same. However, note that the Xilinx automatically generated constraints may have changed. Only include constraints for IP cores (Xilinx or Custom) that you added manually. Additionally, constraints which involve vectors have changed from being zero indexed to being one indexed (i.e., \(0, \cdots, (n-1)\) became \(1, \cdots, n\)) in newer versions.

Generating the Bitstream File

If you are confident that the above parts of the project have been correctly updated the final step is to generate the bitstream of your project (Hardware → Generate Bitstream). This is the file that you will eventually flash to the FPGA. Usually, this step takes a while and most of the time you will come across errors. Research the error codes, fix the errors; lather, rinse, repeat until you have successfully compiled your project. Flash it to your FPGA and test for its correct operation.