This commit was created by squashing the following commits, these
messages were kept just for sake of history:
ad9694_500ebz: Mirror the SPI interface to FMCB
ad9694_500ebz: Set transceiver reference clock to 250
ad9694_500ebz: Allow to configure number of lanes, number of converters
and sample rate
axi_ad9694: Fix number of lanes, it must be 2
ad9694_500ebz: Update the mirrored spi pin assignments
ad9694_500ebz: Gate SPI MISO signals based on chip-select
ad9694_500ebz: Set channel pack sample width
ad9694_500ebz: Change reference clock location
ad9694_500ebz: Remove transceiver memory map arbitration
ad9694_500ebz: Ensure ADC FIFO DMA_DATA_WIDTH is not larger ADC_DATA_WIDTH
ad9694_500ebz: Adjust breakout board pin locations
ad_fmclidar1_ebz: Rename the ad9694_500ebz project
ad_fmclidar1_ebz: Fix lane mapping
ad_fmclidar1_ebz: Delete deprecated files
ad_fmclidar1_ebz: Integrate the axi_laser_driver into the design
ad_fmclidar1_ebz: OTW is an active low signal
ad_fmclidar1_ebz: zc706: Fix iic_dac signals assignment
ad_fmclidar1_ebz: Switch to util_adcfifo
ad_fmclidar1_ebz: Enable synced capture for the fifo
ad_fmclidar1_ebz/zc706: Enable CAPTURE_TILL_FULL
ad_fmclidar1_ebz/zc706: Reduce FIFO size to 2kB
ad_fmclidar1_ebz: Laser driver runs on ADC's core clock
ad_fmclidar1_ebz_bd: Delete the FIFO instance
Because the DMA transfers are going to be relatively small (< 2kbyte),
the DMA can handle the data rate, even when the frequency of the laser
driver pulse is set to its maximum value. (200 kHz)
The synchronization will be done by connecting the generated pulse to
the DMA's SYNC input. Although, to support 2 or 1 channel scenarios, we
need to use the util_axis_syncgen module to make sure that the DMA
catches the pulse, in cases when the pulse width is too narrow. (SYNC is
captures when valid and ready is asserted)
Also we have to reset the cpack IP before each pulse, to keep the DMA buffer's
relative starting point in time fixed, when only 2 or 1 channel is
active.
Our internal repository was changed from phdl to ghdl. Update the
adi_env.tcl scripts and other scripts, which depends on the $ad_ghdl_dir
variable. This way the tools will see all the internal IPs too.
Vivado can not apply the IOB TRUE constraint to only one bit of a
registers. So these constraints will generate several CRITICAL WARNING.
Taking into consideration the maximum used frequencies and current
architecture these constraints are not critical.
Initial version of AD5758 SDZ evaluation board support on ZedBoard.
No critical warnings in the Vivado log.
Bitstream generation passing.
Bring-up on actual board not done.
In the latest system_top file we are not bringing out all the interrupt
signals from the block design. Delete all interrupt ports from the
system_wrapper instance.
Following projects were changed:
- AD5766_SDZ
- AD7134_FMC
- AD7616_SDZ
- AD77681EVB
- AD7768EVB
- ADAQ7980
Observation and RX should never run at the same time.
Given that there is no FIFO on the RX and OBS paths, they will use the higheste performance HP ports, which are HP1 and HP2
For all the Xilinx base design, define three global clock nets, which
are saved in the following three global variable: $sys_cpu_clk, $sys_dma_clk
and $sys_iodelay_clk.
These clock nets are connected to different clock sources depending of
the FPGA architecture used on the carrier. In general the following
frequencies are used:
- sys_cpu_clk - 100MHz
- sys_dma_clk - 200MHz or 250Mhz
- sys_iodelay_clk - 200MHz or 500Mhz
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.
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
Look for undefined clocks which do not show up in the timing summary
therefore can lead to silent failures.
If clocks are not defined they are not analyzed during the timing
checks.
This commit add support for the dual AD9208-DUAL-EBZ board.
The clocking scheme is different from the other projects.
The device clock (LaneRate/40) is no longer an output of the transceivers (RXOUTCLOCK),
it is received directly from the clockchip SCLKOUT9 output through the REFCLK1.
This is needed for deterministic latency where SYSREF must be sampled
with the device clock by meeting setup and hold time.
The two channels from each converter are merged together and transferred to the DDR with a single DMA.
It has all transceiver parameters set for a 15Gpbs lane rate and uses the QPLL.
REQUIRED HARDWARE CHANGES : The F1 2A fuse must be populated on the FMC
board.
Istvan Csomortani
Arpadi
Adrian Costina
István Csomortáni
AndreiGrozav
Laszlo Nagy
Lars-Peter Clausen