2023-09-06 18:38:30 +00:00
|
|
|
.. _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
|
2023-07-20 13:04:46 +00:00
|
|
|
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
|
2023-09-06 18:38:30 +00:00
|
|
|
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
|
2023-07-20 13:04:46 +00:00
|
|
|
specifications and requirements defined in the ANSI/VITA 57.1/57.4 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 three types of FMC connectors: LPC (Low Pin Count), HPC (High Pin
|
|
|
|
Count) and FMC+ (VITA 57.4).
|
2023-09-06 18:38:30 +00:00
|
|
|
|
2023-07-20 13:04:46 +00:00
|
|
|
In general, an FMC board is using the FMC connector type that has enough
|
2023-09-06 18:38:30 +00:00
|
|
|
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::
|
|
|
|
|
2023-07-20 13:04:46 +00:00
|
|
|
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
|
2023-09-06 18:38:30 +00:00
|
|
|
section.
|
|
|
|
|
|
|
|
The most important things to check before porting are related to the ANSI/VITA
|
2023-07-20 13:04:46 +00:00
|
|
|
57.1/57.4 standard (the list is not necessarily exhaustive):
|
2023-09-06 18:38:30 +00:00
|
|
|
|
|
|
|
- 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::
|
|
|
|
|
2023-07-20 13:04:46 +00:00
|
|
|
To check all the requirements, please refer to the ANSI/VITA 57.1/57.4
|
|
|
|
standard.
|
2023-09-06 18:38:30 +00:00
|
|
|
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::
|
|
|
|
|
docs: links, drop part, fixups, codeowners
Drop part role, use generic adi instead for root adi domain links.
For future reference, the snipped used was:
find ./docs/projects -type f -exec sed -i 's/:part:/:adi:/g' {} \;
Drop Containerfile.
Add option to validate links status (e.g. 200, 404), intended mostly for CI
use to check if a page has disappeared from the internet.
Validate links uses coroutines to launch multiple tasks concurrently,
but do it in bundles to avoid being rate limited.
Fixup regmap styling.
Add imoldovan, jmarques, spop, lbarbosa as docs codeowners.
Remove branch field for links to the hdl repo.
Change git role to display full path.
Fixup ZedBoard link label, remove IP List, add SYSID_ROM dokuwiki link
in ad716_sdz project.
Signed-off-by: Jorge Marques <jorge.marques@analog.com>
2023-11-13 15:42:46 +00:00
|
|
|
In :git-hdl:`projects/common <projects/common>`/<carrier_name>
|
2023-09-06 18:38:30 +00:00
|
|
|
you can find templates for the *system_top.v*, *Makefile*, etc. to help you
|
|
|
|
when creating a new project.
|
|
|
|
|
2023-07-20 13:04:46 +00:00
|
|
|
Example with an AMD Xilinx board
|
2023-09-06 18:38:30 +00:00
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
In this section, we are presenting all the necessary steps to create a base
|
2023-07-20 13:04:46 +00:00
|
|
|
design for the AMD :xilinx:`ZCU102` development board.
|
2023-09-06 18:38:30 +00:00
|
|
|
|
2023-07-20 13:04:46 +00:00
|
|
|
First, you need to create a new directory in ``hdl/projects/common`` with the name
|
2023-09-06 18:38:30 +00:00
|
|
|
of the carrier.
|
|
|
|
|
|
|
|
.. code:: bash
|
|
|
|
|
2023-07-20 13:04:46 +00:00
|
|
|
~/hdl$ cd projects/common
|
|
|
|
~/hdl/projects/common$ mkdir zcu102
|
2023-09-06 18:38:30 +00:00
|
|
|
|
|
|
|
The **zcu102** directory must contain the following files:
|
|
|
|
|
2023-07-20 13:04:46 +00:00
|
|
|
- **zcu102_system_bd.tcl** - this script describes the base block design
|
2023-09-06 18:38:30 +00:00
|
|
|
- **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
|
2023-07-20 13:04:46 +00:00
|
|
|
- MIG configuration file (if needed) - this file can be borrowed from the
|
|
|
|
golden reference design of the board
|
2023-09-06 18:38:30 +00:00
|
|
|
- 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
|
2023-07-20 13:04:46 +00:00
|
|
|
- 2 - Zynq UltraScale+ SoC
|
|
|
|
- 3 - Versal
|
2023-09-06 18:38:30 +00:00
|
|
|
|
|
|
|
Example with an Intel board
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
To create a new base design for a given Intel FPGA carrier board, the following
|
2023-07-20 13:04:46 +00:00
|
|
|
steps should be taken (the `A10SoC`_ carrier was used as an example).
|
2023-09-06 18:38:30 +00:00
|
|
|
|
|
|
|
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
|
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
|
2023-07-20 13:04:46 +00:00
|
|
|
Project files for AMD boards
|
2023-09-06 18:38:30 +00:00
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
To follow the project framework as much as possible, the easiest way is to copy
|
2023-07-20 13:04:46 +00:00
|
|
|
all the projects files from an already existing project and to modify those
|
|
|
|
files to support the new carrier.
|
|
|
|
|
|
|
|
A project for an AMD FPGA board should contain the following files:
|
2023-09-06 18:38:30 +00:00
|
|
|
|
2023-07-20 13:04:46 +00:00
|
|
|
- **system_project.tcl** - this script is creating the actual Vivado project
|
2023-09-06 18:38:30 +00:00
|
|
|
and runs the synthesis/implementation of the design. The name of the carrier
|
|
|
|
from inside the file, must be updated.
|
|
|
|
|
2023-07-20 13:04:46 +00:00
|
|
|
- **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
|
2023-09-06 18:38:30 +00:00
|
|
|
updated.
|
|
|
|
|
2023-07-20 13:04:46 +00:00
|
|
|
- **system_constr.xdc** - constraints 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.
|
|
|
|
|
|
|
|
- **Makefile** - this is an auto-generated file, but after updating the carrier
|
2023-09-06 18:38:30 +00:00
|
|
|
name, should work with the new project without an issue.
|
|
|
|
|
|
|
|
Project files for Intel boards
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
2023-07-20 13:04:46 +00:00
|
|
|
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 to modify those
|
|
|
|
files to support the new carrier.
|
|
|
|
|
|
|
|
A project for an Intel FPGA board should contain the following files:
|
2023-09-06 18:38:30 +00:00
|
|
|
|
2023-07-20 13:04:46 +00:00
|
|
|
- **system_project.tcl** - this script is creating the actual Quartus project
|
2023-09-06 18:38:30 +00:00
|
|
|
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.
|
|
|
|
|
2023-07-20 13:04:46 +00:00
|
|
|
- **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.
|
2023-09-06 18:38:30 +00:00
|
|
|
|
2023-07-20 13:04:46 +00:00
|
|
|
- **system_constr.sdc** - contains clock definitions and other path constraints
|
2023-09-06 18:38:30 +00:00
|
|
|
|
2023-07-20 13:04:46 +00:00
|
|
|
- **system_top.v** - top wrapper file of the project. The I/O ports of this
|
2023-09-06 18:38:30 +00:00
|
|
|
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.
|
|
|
|
|
2023-07-20 13:04:46 +00:00
|
|
|
- **Makefile** - this is an auto-generated file, but after updating the carrier
|
2023-09-06 18:38:30 +00:00
|
|
|
name, it should work with the new project without an issue.
|
|
|
|
|
|
|
|
Tips
|
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
|
|
|
|
Generating the FMC I/O constraints
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
2023-07-20 13:04:46 +00:00
|
|
|
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`.
|
2023-09-06 18:38:30 +00:00
|
|
|
|
|
|
|
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:
|
|
|
|
|
2023-07-20 13:04:46 +00:00
|
|
|
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>.
|
2023-09-06 18:38:30 +00:00
|
|
|
|
|
|
|
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)
|
|
|
|
|
2023-07-20 13:04:46 +00:00
|
|
|
If sourced **without argument(s)**, then you can simply call ``gen_fmc_constr
|
|
|
|
<fmc_port>``.
|
2023-09-06 18:38:30 +00:00
|
|
|
|
|
|
|
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**
|
2023-07-20 13:04:46 +00:00
|
|
|
(AMD board) or **fmc_constr.tcl** (Intel board). If ran from an open Vivado
|
2023-09-06 18:38:30 +00:00
|
|
|
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
|
2023-07-20 13:04:46 +00:00
|
|
|
(see **projects/common/<carrier>/\*.txt**).
|
2023-09-06 18:38:30 +00:00
|
|
|
* Two parameters indicating both FMC ports in the desired order for projects
|
|
|
|
that use both FMC connectors.
|
2023-07-20 13:04:46 +00:00
|
|
|
|
|
|
|
.. _A10SoC: https://www.intel.com/content/www/us/en/products/details/fpga/development-kits/arria/10-sx.html
|