Define a MIMO_ENABLE parameter for the core, which will insert
and additional de-skew logic to prevent timing issues coming from
the clock skew differences of two or multiple AD9361.
Add support for the Arria 10 SoC development kit to the dac_fmc_ebz
project.
This allows to use the following FMC boards on the Arria 10 SoC development
Kit carrier:
* AD9135-FMC-EBZ
* AD9136-FMC-EBZ
* AD9144-FMC-EBZ
* AD9152-FMC-EBZ
* AD9154-FMC-EBZ
* AD9171-FMC-EBZ
* AD9172-FMC-EBZ
* AD9173-FMC-EBZ
Note that the board in its default configuration is not fully compatible with the
mentioned FMC boards and some slight re-work moving some 0 Ohm resistors is
required. The rework concerns the LA01 and LA05 pins, which by default are
not connected to the FPGA. The changes required are:
LA01_P_CC
R612: R0 -> DNI
R610: DNI -> R0
LA01_N_CC
R613: R0 -> DNI
R611: DNI -> R0
LA05_P
R621: R0 -> DNI
R620: DNI -> R0
LA05_N
R633: R0 -> DNI
R632: DNI -> R0
The main differences between AD9144-FMC-EBZ and AD9172-FMC-EBZ are:
* The DAC txen signals are connected to different pins
* The polarity of the spi_en signal is active low instead of active high
* The maximum lane rate is up to 15.4 Gpbs
To accommodate this all 4 possible txen signals as well as the spi_en
signal are connected to GPIOs. Software can decide how to use them
depending on which FMC board is connected.
Note that each carrier has a maximum supported lane rate. Modes of the
AD9172 (and similar) that exceed the carrier specific limit can not be used
on that carrier. The limits are as following:
* A10SoC: 14.2 Gbps
Add a generic project for the AD91xx-FMC-EBZ DAC boards connected to the
ZCU102 and ZC706 carrier boards.
The project is called dac_fmc_ebz as the intention is to support all DAC
FMC evaluation boards with this project since they are sufficiently similar
to be supported by the same design.
This project will successively extended to add support for more boards.
The desired DAC device and JESD operation mode must be selected from the following
file:
./common/config.tcl
This design can support the following FMC boards which are all pin
compatible:
* AD9135-FMC-EBZ
* AD9136-FMC-EBZ
* AD9144-FMC-EBZ
* AD9152-FMC-EBZ
* AD9154-FMC-EBZ
* AD916x-FMC-EBZ
* AD9171-FMC-EBZ
* AD9172-FMC-EBZ
* AD9173-FMC-EBZ
Note that the AD9152-FMC-EBZ only uses the first 4 lanes, whereas all other
boards use 8 lanes.
This project assumes that the transceiver reference clock and SYSREF are
provided via the clock distribution chip that is found on the
ADxxxx-FMC-EBZ board.
In terms of pin connections between the FPGA and the FMC board the
AD9172-FMC-EBZ is very similar to the AD9144-FMC-EBZ.
The main differences are:
* The DAC txen signals are connected to different pins
* The polarity of the spi_en signal is active low instead of active high
* The maximum lane rate is up to 15.4 Gpbs
To accommodate this 5 txctrl signals as well as the spi_en signal are connected
to GPIOs. Software can decide how to use them depending on which FMC board
is connected.
Note that each carrier has a maximum supported lane rate. Modes of the
AD9172 (and similar) that exceed the carrier specific limit can not be used
on that carrier. The limits are as following:
* ZC706: 10.3125 Gbps
* ZCU102: 15.4 Gbps (max AD9172 lanerate)
* SPI and GPIOs to PMOD header support
Connect a SPI interface and some GPIOs to the PL PMOD headers on the zcu102
and zc706 carriers.
This is can be used to control additional external hardware like a clock
chip or an analog front-end.
This is especially useful on FMC boards that do not feature a clock
generator chip.
The pin out is:
PMOD 1: SPI clock
PMOD 2: SPI chipselect
PMOD 3: SPI MOSI
PMOD 4: SPI MISO
PMOD 7: GPIO 0
PMOD 8: GPIO 1
PMOD 9: GPIO 2
PMOD 10: GPIO 3
The GPIOs are mapped at offset 48-51 of the EMIO GPIOs.
Add a clock crossing bridge for the interfaces that runs on a different
clock than the emif_user_clk.
This way we can simplify the main interconnect, and prevent occasional
timing violations.
The process ad_xcvrcon has a device_clk attribute which can be used to
connect a custom device clock to the XCVR. Fix the proc call so we can
simplify the block design script.
The process ad_xcvrcon has a device_clk attribute which can be used to
connect a custom device clock to the XCVR. Fix the proc call so we can
simplify the block design script.
After the previous commit that removed the interconnects from HP ports
in order to reduce utilization. The directly connected DMAs were not
assigned to a specific range and address.
Let the measured transfer length to be cleared at the end of each
transfer, other case in cyclic mode the counter will overflow and will
not present any useful information.
Once xfer_request is set the DMA must accept samples in the same clock
cycle if the fifo_wr_en signal is asserted.
If the req_valid asserts faster than the ID gets synchronized over the
the xfer request asserts without being ready to accept data.
This can lead to overflow assertion when using a FIFO like interface.
This patch addresses the following issue:
In case of transfers with multiple segments, if TLAST asserts on the last
beat of a non-last segment while more descriptors are queued up,
the completions for the queued segments may be missed causing timeout in
processes that wait for transfer completions.
This patch addresses the following issue:
In 2D mode when consecutive partial transfers occur, and the latter is
very short, will interfere with the completion mechanism of the first
transfer leading to uncompleted segments and unreported partial
transfers.
Allow the top level files to have parameters.
Pass the parameters from system_project.tcl to the Vivado/Quartus project and
to the block design scripts through ad_project_params variable.
Usage:
1. create a project with a list of parameters:
adi_project_xilinx my_project [list PARAM_A PARAM_A_VALUE PARAM_B PARAM_B_VALUE]
or
adi_project_altera my_project [list PARAM_A PARAM_A_VALUE PARAM_B PARAM_B_VALUE]
2. access the parameter in QSYS or block design through the $ad_project_params variable
e.g
set PARAM_A $ad_project_params(PARAM_A)
set PARAM_B $ad_project_params(PARAM_B)
3. In system_top.v use PARAM_A and PARAM_B as parameters/generics
Istvan Csomortani
Laszlo Nagy
Lars-Peter Clausen
AndreiGrozav
Adrian Costina