308 lines
13 KiB
ReStructuredText
308 lines
13 KiB
ReStructuredText
.. _porting_project:
|
|
|
|
Porting ADI's HDL reference designs
|
|
===============================================================================
|
|
|
|
In general, a given reference design for an FMC board is deployed to just a few
|
|
carriers, although several :git-hdl:`FPGA boards <projects/common>`
|
|
are supported in ADI's HDL repository. The simple reason behind this practice is
|
|
that it would create a tremendous maintenance workload, that would require a lot
|
|
of human resources, and would increase the required time for testing. The
|
|
general rule of thumb is to support a given project with a fairly popular
|
|
carrier (e.g. ZC706 or A10SoC), which is powerful enough to showcase the board
|
|
features and maximum performance.
|
|
|
|
All the HDL projects were designed to maximize source code reuse, minimize
|
|
maintainability and simplify portability. The result of these design goals is
|
|
that porting a given project to another carrier is fairly simple if the user
|
|
respects a couple of guidelines.
|
|
|
|
The main scope of this wiki page is to discuss these guidelines and provide
|
|
simple indications for users who wants to port a project to a non-supported
|
|
carrier.
|
|
|
|
Quick Compatibility Check
|
|
-------------------------------------------------------------------------------
|
|
|
|
.. note::
|
|
|
|
All ADI's FPGA Mezzanine Cards (FMC) are designed to respect all the
|
|
specifications and requirements defined in the ANSI/VITA 57.1 FPGA Mezzanine
|
|
Card Standard (if not otherwise stated on board's wiki page). If the new FPGA
|
|
carrier is fully compliant with this standard, there will be no obstacles
|
|
preventing the user to port the project to the required carrier card.
|
|
|
|
There are two types of FMC connectors: LPC (Low Pin Count) and HPC (High Pin
|
|
Count). In general, an FMC board is using the FMC connector type that has enough
|
|
pins for the required interfaces between the I/O devices and FPGA. A carrier
|
|
with an FMC HPC connector can host FMC boards with an LPC or HPC connector, but
|
|
a carrier with an FMC LPC can host a board just with an FMC LPC connector.
|
|
|
|
.. tip::
|
|
|
|
First, always check out the already available :git-hdl:`base designs <projects/common>`.
|
|
If your board is present among our supported base designs, you do not need to
|
|
verify the following things and you can jump to the Project creation
|
|
section.
|
|
|
|
The most important things to check before porting are related to the ANSI/VITA
|
|
57.1 standard (the list is not necessarily exhaustive):
|
|
|
|
- Power and ground lines - 3P3V/3P3VAUX/12P0V/GND
|
|
- VADJ - adjustable voltage level power from the carrier, each board has a
|
|
specific requirement for VADJ
|
|
- Dedicated pins for clock signals - all the clock dedicated pins should be
|
|
connected to a clock capable pin of the FPGA (I/O pin which is capable to
|
|
receive and/or transmit a clock signal)
|
|
- Dedicated pins for transceiver lines (DPx_[M2C|C2M]_[P|N])
|
|
|
|
.. attention::
|
|
|
|
To check all the requirements, please refer to the ANSI/VITA 57.1 standard.
|
|
The above few hints do not cover all the FMC standards and you
|
|
may miss something that can prevent the porting of the project.
|
|
|
|
|
|
.. tip::
|
|
|
|
Make sure that you have reviewed all the documentation and design files in
|
|
order to know the electrical specifications and/or requirements of the
|
|
FMC board. If you're not sure, ask!
|
|
|
|
Base design files
|
|
-------------------------------------------------------------------------------
|
|
|
|
At :ref:`architecture` it is described a generic base design and possible
|
|
components of it. The user should look at it as a suggestion only.
|
|
|
|
.. tip::
|
|
|
|
In :git-hdl:`/projects/common </projects/common>`/<carrier_name>
|
|
you can find templates for the *system_top.v*, *Makefile*, etc. to help you
|
|
when creating a new project.
|
|
|
|
Example with a Xilinx board
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
In this section, we are presenting all the necessary steps to create a base
|
|
design for the Xilinx ZCU102 development board.
|
|
|
|
First, you need to create a new directory in *~/projects/common* with the name
|
|
of the carrier.
|
|
|
|
.. code:: bash
|
|
|
|
cd projects/common
|
|
mkdir zcu102
|
|
|
|
The **zcu102** directory must contain the following files:
|
|
|
|
- **zcu102_system_bd.tcl** - This script describes the base block design
|
|
- **zcu102_system_constr.xdc** - I/O constraint file for the base design. It
|
|
will contain I/O definitions for GPIO, switches, LEDs or other peripherals of
|
|
the board
|
|
- MIG configuration file (if needed) - This file can be borrowed for the golden
|
|
reference design of the board
|
|
- Other constraints files if needed
|
|
|
|
You should define the board and its device in the project flow script
|
|
:git-hdl:`projects/scripts/adi_project_xilinx.tcl`
|
|
by adding the following lines to the beginning of the **adi_project_create**
|
|
process:
|
|
|
|
.. code:: tcl
|
|
|
|
if [regexp "_zcu102$" $project_name] {
|
|
set p_device "xczu9eg-ffvb1156-1-i-es1"
|
|
set p_board "xilinx.com:zcu102:part0:1.2"
|
|
set sys_zynq 2
|
|
}
|
|
|
|
.. tip::
|
|
|
|
The valid board parts and parts can be retrieved by running the
|
|
following commands in Tcl console: **get_parts** and **get_board_parts**. Run
|
|
the commands like **join [get_parts] \\n**, so each part name will be listed on
|
|
a separate line.
|
|
|
|
The **sys_zynq** constant variable should be set in the following way:
|
|
|
|
- 0 - 7 Series FPGA (e.g. Kintex7, Virtex7)
|
|
- 1 - Zynq7000 SoC
|
|
- 2 - Zynq Ultrascale+ SoC
|
|
|
|
Example with an Intel board
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
To create a new base design for a given Intel FPGA carrier board, the following
|
|
steps should be taken (the A10SoC carrier was used as an example).
|
|
|
|
The following files should be created or copied into the directory:
|
|
|
|
- **a10soc_system_assign.tcl** - global and I/O assignments of the base design
|
|
- **a10soc_system_qsys.tcl** - the QSYS base design
|
|
|
|
You should define the board and its device in the flow script
|
|
:git-hdl:`projects/scripts/adi_project_intel.tcl`,
|
|
by adding the following lines to the beginning of the **adi_project_altera**
|
|
process:
|
|
|
|
.. code:: tcl
|
|
|
|
if [regexp "_a10soc$" $project_name] {
|
|
set family "Arria 10"
|
|
set device 10AS066N3F40E2SG
|
|
set system_qip_file system_bd/system_bd.qip
|
|
}
|
|
|
|
Project files
|
|
-------------------------------------------------------------------------------
|
|
|
|
Project files for Xilinx boards
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
To follow the project framework as much as possible, the easiest way is to copy
|
|
all the projects files from an already existing project and modifying those
|
|
files to support the new carrier. A project for a Xilinx FPGA board should
|
|
contain the following files:
|
|
|
|
- **system_project.tcl** - This script is creating the actual Vivado project
|
|
and runs the synthesis/implementation of the design. The name of the carrier
|
|
from inside the file, must be updated.
|
|
|
|
- **system_bd.tcl** - In this file is sourced the *base* design's Tcl script
|
|
and the *board* design's Tcl script. Again, the name of the carrier must be
|
|
updated.
|
|
|
|
- **system_constr.xdc** - Constraint file of the board design. Here are defined
|
|
the FMC I/O pins and board specific clock signals. All the I/O definitions
|
|
must be updated, with the new pin names.
|
|
|
|
- **system_top.v** - Top wrapper file, in which the system_wrapper.v module is
|
|
instantiated, and a few I/O macros are defined. The I/O port of this Verilog
|
|
module will be connected to actual I/O pads of the FPGA. The simplest way to
|
|
update the *system_top* is to let the synthesis fail and the tool will tell
|
|
you which ports are missing or which ports are redundant. The first thing to
|
|
do after the failure is to verify the instantiation of the system_wrapper.v.
|
|
This file is a tool generated file and can be found at
|
|
*<project_name>.srcs/sources_1/bd/system/hdl/system_wrapper.v*. Fixing the
|
|
instantiation of the wrapper module in most cases eliminates all the errors.
|
|
If you get errors that you cannot fix, ask for support.
|
|
|
|
- **Makefile** - This is an auto-generated file, but after updating the carrier
|
|
name, should work with the new project without an issue.
|
|
|
|
Project files for Intel boards
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
To follow the project framework as much as possible the easiest way is to copy
|
|
all the projects file from an already existing project and modifying those files
|
|
to support the new carrier. A project for an Intel FPGA board should contain the
|
|
following files:
|
|
|
|
- **system_project.tcl** - This script is creating the actual Quartus project
|
|
and runs the synthesis/implementation of the design. It also contains the I/O
|
|
definitions for the interfaces between the FMC board and FPGA. The carrier
|
|
name and all the I/O pin names inside the file, must be updated.
|
|
|
|
- **system_qsys.tcl** - In this file is sourced the *base* design's Tcl script
|
|
and the *board* design's Tcl script. Again, the name of the carrier must be
|
|
updated.
|
|
|
|
- **system_constr.sdc** - Contains clock definitions and other path constraints
|
|
|
|
- **system_top.v** - Top wrapper file of the project. The I/O ports of this
|
|
Verilog module will be actual I/O pads of the FPGA. You must make sure that
|
|
the base design's I/Os are updated (delete nonexistent I/Os or add new ones).
|
|
The simplest way to update the *system_top* is to let the synthesis fail and
|
|
the tool will you tell which ports are missing or which ports are redundant.
|
|
|
|
- **Makefile** - This is an auto-generated file, but after updating the carrier
|
|
name, it should work with the new project without an issue.
|
|
|
|
Tips
|
|
-------------------------------------------------------------------------------
|
|
|
|
Generating the FMC I/O constraints
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The easiest way of writing the constraints for FMC I/O pins is making use of the
|
|
script :git-hdl:`projects/scripts/adi_fmc_constr_generator.tcl`.
|
|
|
|
Required setup:
|
|
|
|
- Carrier common FMC connections file
|
|
(:git-hdl:`projects/common <projects/common>`/<carrier>/<carrier>_<fmc_port>.txt)
|
|
- Project common FMC connections file
|
|
(:git-hdl:`projects`/<project>/common/<project>_fmc.txt)
|
|
|
|
.. tip::
|
|
|
|
In cases where these files don't already exist, you can make your own
|
|
by following some existing ones as an example.
|
|
For project common files, you can easily make them following :ref:`creating_fmc`.
|
|
|
|
Calling the script:
|
|
|
|
To use this script you can source it in any tcl shell or simply call the
|
|
adi_fmc_constr_generator.tcl with argument(s) <fmc_port>. But before sourcing or
|
|
calling it, your current directory needs to be
|
|
:git-hdl:`projects`/<project>/<carrier>
|
|
|
|
For example:
|
|
|
|
- :code:`tclsh ../../scripts/adi_fmc_constr_generator.tcl fmc0`
|
|
(the project uses only one FMC port at a time)
|
|
- :code:`tclsh ../../scripts/adi_fmc_constr_generator.tcl fmc0 fmc1`
|
|
(the project uses two FMC ports at a time)
|
|
|
|
If sourced without argument(s) then you can simply call gen_fmc_constr
|
|
<fmc_port>.
|
|
|
|
For example:
|
|
|
|
- :code:`gen_fmc_constr fmc0` (the project uses only one FMC port at a time)
|
|
- :code:`gen_fmc_constr fmc0 fmc1` (the project uses two FMC ports at a time)
|
|
|
|
.. note::
|
|
|
|
The fmc port name can be deduced from the common carrier file name
|
|
(:git-hdl:`projects/common <projects/common>`/<carrier>/<carrier>_<fmc_port>.txt).
|
|
|
|
The generated file will appear in the current directory as **fmc_constr.xdc**
|
|
(Xilinx board) or **fmc_constr.tcl** (Intel board). If ran from an open Vivado
|
|
project, the generated file will be automatically added to the project.
|
|
|
|
.. _creating_fmc:
|
|
|
|
Creating carrier common FMC connections
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
To create a carrier common FMC connections file:
|
|
|
|
#. Open the space divided .txt file corresponding to the desired connector type,
|
|
either with a text editor or importing in a spreadsheet editor
|
|
(with Excel, export as .prn).
|
|
:git-hdl:`docs/user_guide/sources/fmc.txt`,
|
|
:git-hdl:`docs/user_guide/sources/fmc_hpc.txt`,
|
|
:git-hdl:`docs/user_guide/sources/fmc+.txt`.
|
|
#. Fill the table by replacing the **#**'s where it's needed.
|
|
#. Save as .txt inside :git-hdl:`projects`/<project_name>/common/.
|
|
#. Clean up the file by removing the lines containing **#** for system_top_name.
|
|
#. Rearrange the lines following one of the existing examples.
|
|
#. To generate empty lines, leave an empty line in the .txt file.
|
|
To generate comments, the line should start with **#** sign.
|
|
#. Run the script as :code:`tclsh /path/to/script {fmc_conn}`
|
|
(e.g. :code:`tclsh ../../scripts/adi_fmc_constr_generator.tcl fmc0`).
|
|
|
|
* Current directory needs to be hdl/projects/<project_name>/<carrier>.
|
|
* If used from an open project, the generated file would be added to the project;
|
|
otherwise it will appear in the current directory.
|
|
* If the carrier has only one FMC port, the script can be called without parameters.
|
|
* If the carrier has more FMC ports, the script should be called with:
|
|
|
|
* One parameter indicating the FMC port: fmc_lpc/hpc, fmc0/1, fmcp0/1
|
|
(see projects/common/<carrier>/\*.txt).
|
|
* Two parameters indicating both FMC ports in the desired order for projects
|
|
that use both FMC connectors.
|