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.
Add support for specifying a set of parameter value pairs when
instantiating an IP core to the ad_ip_instance command. This has the
convenience of not having to repeatedly call ad_ip_parameter with the name
of the core that got just created for each parameter that needs to be set.
It is also useful for cases where some parameters have mutually exclusive
values and both (or more) have to be set at the same time.
This also slightly speeds things up. Whenever a parameter is changed the
core needs to be updated and post configuration scripts might run. When
setting all parameters at the same time this only happens once instead of
once for each parameter.
For example the following sequence
ad_ip_instance axi_dmac axi_ad9136_dma
ad_ip_parameter axi_ad9136_dma CONFIG.DMA_TYPE_SRC 0
ad_ip_parameter axi_ad9136_dma CONFIG.DMA_TYPE_DEST 1
ad_ip_parameter axi_ad9136_dma CONFIG.DMA_DATA_WIDTH_SRC 64
ad_ip_parameter axi_ad9136_dma CONFIG.DMA_DATA_WIDTH_DEST 256
can now be replaced with
ad_ip_instance axi_dmac axi_ad9136_dma [list \
DMA_TYPE_SRC 0 \
DMA_TYPE_DEST 1 \
DMA_DATA_WIDTH_SRC 64 \
DMA_DATA_WIDTH_DEST 256 \
]
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The loopback on the unused gpio inputs consumes routing resources
while does not gives any value for the software.
Connect these lines to zero instead.
Some projects use the ad_iobuf on IOs that are not bidirectional
producing synthesis warnings.
The change fixes warnings like:
[Synth 8-6104] Input port 'gpio_bd_i' has an internal driver
[Synth 8-6104] Input port 'gpio_status' has an internal driver
- connect unused GPIO inputs to loopback
- connect unconnected inputs to zero
- complete interface for system_wrapper instantiated in all system_top
fixes incomplet portlist WARNING [Synth 8-350]
fixes undriven inputs WARNING [Synth 8-3295]
The change excludes the generated system.v and Xilinx files.
- remove interrupts from system_top
- for all suported carriers:
- remove all interrupt bd pins
- connect to GND all initial unconnected interrupt pins
- update ad_cpu_interrupt procedure to disconnect a interrupt from GND
before connectiong it to another pin.
Just one VCC or GND xlconstant will be generated for each width. This
way we can avoid having a lot of xlconstant instances with the same
configuration.
Some FMC boards do utilize more than one transceiver quad but do not
necessarily use all transceivers in a quad. On such board is the
AD9694-500EBZ. Which uses two transceivers each in two adjacent quads.
This board can not be supported by instantiating a util_adxcvr with only 4
lanes. Since those 4 lanes would be packed into the same quad. Instead it
it is necessary to instantiate a util_adxcvr with 6 lanes. 4 lanes for the
first quad and 2 for the second.
To still to be able to connect such a util_adxcvr to a link layer with only
4 lanes allow to specify sparse lane mappings. A sparse mapping can have
less lanes than the util_adxcvr and some lanes will be left unconnected.
For example for the AD9694-500EBZ the lane mapping looks like the following:
ad_xcvrcon util_ad9694_xcvr axi_ad9694_xcvr ad9694_jesd {0 1 4 5} rx_device_clk
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Sometimes the output clock of the transceiver should not be used for the
device clock.
E.g. for deterministic latency with no uncertainty the device clock needs
to be sourced directly from a clock or transceiver reference clock input
pin.
Add an option to the ad_xcvrcon command to specify the device clock.
In case the same device clock is used for multiple JESD204 links, e.g. a TX
and a RX link only one reset generator is created.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
This change adds the TLAST signal to the AXI streaming interface
of the source side for Intel targets.
Xilinx based designs already have this since the tlast is part of the
interface definition.
In order to make the signal optional and let the tool connect a
default value to the it, the USE_TLAST_SRC/DEST parameter is
added to the configuration UI. This conditions the tlast port on
the interface of the DMAC.
Xilinx handles the optional signals much better so the parameter
is not required there.
There are random timing violations on the A10GX board using the
DAQ3 and DAQ2 projects.
Setting the synthesis/implementation strategy to "HIGH PERFORMANCE
EFFORT" increases the success rate of the timing closure significantly.
In the system top of the FMCOMMS5 projects, there are several GPIO lines, which
can not find in the constraint file, respectively gpio_open_15_15,
gpio_open_44_44 and gpio_45_45.
These are floating GPIO pins, as their names suggest. Delete all these wires and
update IOBUF instances.
Moved XCVR related connections to HP0, where the HP shares the MUX with the Video DMA
HP1 and HP2 are used for RX OS and RX DMAs, sharing the MUX. Usually they shouldn't run at the same time.
HP3 is used for TX DMA, sharing the MUX with the FPD DMA controller
All HPx and DMA buswidths have been increased to 128 bits
The HPx-DMA clock has been increased to 300 MHz
DAC FIFO address size has been increased to 17
In DUAL mode half of the data ports are unused and the unused inputs need
to be connected to dummy signals.
Completely hide the unused ports in DUAL mode to remove that requirement.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Connect the DAC data underflow pin (fifo_rd_underflow) of the DMA
to the dunf pin of the device core. This way the software can detect
underflows in the DAC data path.
Connect the DAC data underflow pin (fifo_rd_underflow) of the DMA
to the dunf pin of the device core. This way the software can detect
underflows in the DAC data path.
Connect the DAC data underflow pin (fifo_rd_underflow) of the DMA
to the dunf pin of the device core. This way the software can detect
underflows in the DAC data path.
The standard Makefile output is very noisy and it can be difficult to
filter the interesting information from this noise.
In quiet mode the standard Makefile output will be suppressed and instead a
short human readable description of the current task is shown.
E.g.
> make adv7511.zed
Building axi_clkgen library [library/axi_clkgen/axi_clkgen_ip.log] ... OK
Building axi_hdmi_tx library [library/axi_hdmi_tx/axi_hdmi_tx_ip.log] ... OK
Building axi_i2s_adi library [library/axi_i2s_adi/axi_i2s_adi_ip.log] ... OK
Building axi_spdif_tx library [library/axi_spdif_tx/axi_spdif_tx_ip.log] ... OK
Building util_i2c_mixer library [library/util_i2c_mixer/util_i2c_mixer_ip.log] ... OK
Building adv7511_zed project [projects/adv7511/zed/adv7511_zed_vivado.log] ... OK
Quiet mode is enabled by default since it generates a more human readable
output. It can be disabled by passing VERBOSE=1 to make or setting the
VERBOSE environment variable to 1 before calling make.
E.g.
> make adv7511.zed VERBOSE=1
make[1]: Entering directory 'library/axi_clkgen'
rm -rf *.cache *.data *.xpr *.log component.xml *.jou xgui
*.ip_user_files *.srcs *.hw *.sim .Xil .timestamp_altera
vivado -mode batch -source axi_clkgen_ip.tcl >> axi_clkgen_ip.log 2>&1
...
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Currently the individual IP core dependencies are tracked inside the
library Makefile for Xilinx IPs and the project Makefiles only reference
the IP cores.
For Altera on the other hand the individual dependencies are tracked inside
the project Makefile. This leads to a lot of duplicated lists and also
means that the project Makefiles need to be regenerated when one of the IP
cores changes their files.
Change the Altera projects to a similar scheme than the Xilinx projects.
The projects themselves only reference the library as a whole as their
dependency while the library Makefile references the individual source
dependencies.
Since on Altera there is no target that has to be generated create a dummy
target called ".timestamp_altera" who's only purpose is to have a timestamp
that is greater or equal to the timestamp of all of the IP core files. This
means the project Makefile can have a dependency on this file and make sure
that the project will be rebuild if any of the files in the library
changes.
This patch contains quite a bit of churn, but hopefully it reduces the
amount of churn in the future when modifying Altera IP cores.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Some IP core have files in their file list for common modules that are not
used by the IP itself. Remove those.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Currently the IP component dependency in the Makefile system is the Vivado
project file. The project file is only a intermediary product in producing
the IP component definition file.
If building the component definition file fails or the process is aborted
half way through it is possible that the Vivado project file for the IP
component exists, but the IP component definition file does not.
In this case there will be no attempt to build the IP component definition
file when building a project that has a dependency on the IP component.
Building the project will fail in this case.
To avoid this update the Makefile rules so that the IP component definition
file is used as the dependency. In this case the IP component will be
re-build if the component definition file does not exist, even if the
project file exists.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Removes a lot of boilerplate code.
Using the new scheme it is possible to add new projects or sub-projects
without having to re-generate any existing Makefiles.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The project top-level Makefile accept the all, clean and clean-all targets
and forward them to their sub-projects.
Create a common Makefile include that can be used to implement this
behavior. The shared Makefile collects all sub-directories that have a
Makefile and then forwards the all, clean and clean-all targets to them.
This is implemented by creating virtual targets for each combination of
sub-project and all, clean, clean-all targets in the form of
"$project/all", ... These virtual sub-targets are then listed as the
prerequisites of the project top-level Makefile targets.
This means there is no longer a need to re-generate top-level Makefiles
when a new project or sub-project is added.
It will also allow to remove a lot of boilerplate code.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
This reduces the amount of boilerplate code that is present in these
Makefiles by a lot.
It also makes it possible to update the Makefile rules in future without
having to re-generate all the Makefiles.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The project Makefiles for the Xilinx projects share most of their code. The
only difference is the list of project dependencies.
Create a file that has the common parts and can be included by the project
Makefiles.
This drastically reduces the size of the project Makefiles and also allows
to change the Makefile implementation without having to re-generate all
Makefiles.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The project Makefiles for the Altera projects share most of their code. The
only difference is the list of project dependencies.
Create a file that has the common parts and can be included by the project
Makefiles.
This drastically reduces the size of the project Makefiles and also allows
to change the Makefile implementation without having to re-generate all
Makefiles.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Laszlo Nagy
Istvan Csomortani
AndreiGrozav
Adrian Costina
Sergiu Arpadi
Lars-Peter Clausen
Matt Fornero