The second ADC was removed from the project, as the EV-AD7768-1FMCZ evaluation
board contains only one ADC. Therefore, all the IPs related to the
second ADC have been removed, too.
The data width supported by the spi IPs has been changed from 8 bits to
32 bits, therefore the axis_upscaler(util_axis_upscale_v1_0) and the
m_axis_samples_24(AXI4-Stream Data Width Converter) are no more necessary,
so they have been removed from the design.
The 24 bits width data transfer between the s_axis of axi_ad77681_dma
(AXI DMA Controller) and the offload_sdi of the spi_engine_offload is now made
directly.
Add commands to generate one extra file with resource utilization, in CSV format.
New commands executes only if ADI_GENERATE_UTILIZATION env variable is set.
In ZCU102 LA01_CC_P|N are connected to regional clock, but in order to
receive a device clock properly we have to use pin which is connected
to a global clock buffer. Luckily SYSREF is connected to global clock
pin; swap to port to receive the device clock correctly.
Also, swap the ports in both ZC706 and A10SOC carriers.
mclk now generated by ps not axi clkgen ip. ADAU1761 expects a free
running clock and the i2s driver was switching the axi clkgen ip off
which was causing issues.
Cleanup placement constraints and let the tool have more freedom to
place and route the design. This is possible only after balancing the
memory and system clocks.
Minimize skew on synchronous CDC timing paths between clocks originating
from the same MMCM source. (sys_mem_clk and sys_cpu_clk)
This is required mostly by the smart interconnect.
The CLOCK_DELAY_GROUP property must be applied directly to the output net of BUFGs.
"prepare_incremental_compile" is defined as a phony target, but is also a
prerequisite of a real target. This will lead to a complete project build
every time make is called.
To fix the issue the functionality of prepare_incremental_compile target
was included in the generic project build target.
Software has to know which TIA channel was used for a particular capture.
Define an additional dummy ADC channel which will provide this
information. Currently this channel is always enabled.
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.
Clear the reference checkpoint if the incremental compilation is not
selected through the make option. Other case the scripts will silently
use the reference.dcp checkpoint if that exists.
The scripts are looking for a previous run result, a routed design
checkpoint to use it as a reference during the incremental build flow.
Before clearing the project files, the scrips will save the reference dcp
file in the project folder.
If the reference dcp does not exists the build continues normally.
Proposed workflow:
1. Build your project normally with 'make' or place manually a
reference.dcp file in the Vivado project folder.
2. Do some minor modifications
3. Run the make with the following option:
make MODE=incr
4. Repeat steps 2-3
Using a common IP cache location for all the project will speed up
compile time of common blocks used in base designs. Example a MicroBlaze
core for VCU118 once compiled it will be reused on other projects.
Using a common IP cache will speed up re-compiles of every project in OOC
mode since the cache won't be cleared as with normal compile flow.
Having a clock assigned manually to the clk output pin of the axi_ad9361
let the Vivado timing engine to not ignore the clock insertion delay when
analyzing paths between clk_0 and the manually created clock that has
the same source (clk_0), resulting in timing failure.
In the current form, when connecting a master to the HP ports all
available slave address spaces are mapped to the master (DDR_*, PCIE*, OCM,
QSPI)
Let the PL masters have access only to the DDR_LOW and DDR_HIGH address
spaces to avoid unnecessary resource usage and increase timing margin.
Create the dacfifo/adcfifo infrastructure with procedures.
This will allow moving the parameters of the dac/adcfifo inside
the block design so it can be calculated based on other parameters.
Use the new util_cpack2 and util_upack2 cores. They have lower utilization
that the old util_cpack and util_upack cores.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new util_cpack2 and util_upack2 cores. They have lower utilization
that the old util_cpack and util_upack cores.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new util_cpack2 and util_upack2 cores. They have lower utilization
that the old util_cpack and util_upack cores.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new util_cpack2 and util_upack2 cores. They have lower utilization
that the old util_cpack and util_upack cores.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new util_cpack2 and util_upack2 cores. They have lower utilization
that the old util_cpack and util_upack cores.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new util_cpack2 and util_upack2 cores. They have lower utilization
that the old util_cpack and util_upack cores.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new util_cpack2 and util_upack2 cores. They have lower utilization
that the old util_cpack and util_upack cores.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new util_cpack2 and util_upack2 cores. They have lower utilization
that the old util_cpack and util_upack cores.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new util_cpack2 and util_upack2 cores. They have lower utilization
that the old util_cpack and util_upack cores.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new util_cpack2 and util_upack2 cores. They have lower utilization
that the old util_cpack and util_upack cores.
Signed-off-by: Matt Fornero <matt.fornero@mathworks.com>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new util_cpack2 and util_upack2 cores. They have lower utilization
that the old util_cpack and util_upack cores.
Signed-off-by: Matt Fornero <matt.fornero@mathworks.com>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new util_cpack2 and util_upack2 cores. They have lower utilization
that the old util_cpack and util_upack cores.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new util_cpack2 and util_upack2 cores. They have lower utilization
that the old util_cpack and util_upack cores.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new util_cpack2 and util_upack2 cores. They have lower utilization
that the old util_cpack and util_upack cores.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
When we improve timing by modifying the implementation strategies,
the general rule of thumb is "less is always more".
Timing did not fail in synthesis, so we leaving the synthesis
strategy in default.
After several parallel runs with various strategies, the
"Performance_Explore" strategy gave the best result for
implementation.
Each individual link of a multi-link has its own sync signal. The top level
sync port that is created by the ad_xcvrcon function is always a single bit
single though.
This results in only the sync signal of the first link being routed while
others are ignored.
To fix this make sure that for multi-link setups the sync port is a vector
port with the width equal to the number of links.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
- refclk and refclk_rst were used for ethernet IDELAY, but are not needed anymore
- muxaddr_out pins overlap with regular GPIOs in the Zed base design. The XADC mux GPIOs can be controlled through that. Cusomters that want to directly control the pins through XADC IP must modify the design
In default strategy we having a few path with small negative slack inside of
the MIG, due to the high UI clock (300MHz).
This new strategy solves this issue.
Adrian Costina
Stanca Pop
AndreiGrozav
Stefan Raus
Istvan Csomortani
Laszlo Nagy
Arpadi
StancaPop
István Csomortáni
Lars-Peter Clausen
Matt Fornero