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>
Istvan Csomortani
Adrian Costina
AndreiGrozav
Sergiu Arpadi
Laszlo Nagy
Lars-Peter Clausen
Matt Fornero