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>
The TX side runs on QPLL, and the RX and RX_OS runs on CPLL by default.
The OUTCLK frequency is the same as the REFCLK.
The main reason of this modification is that the links should come up
without any DPR access, after power up, using the default reference clock
configuration (122.88 MHz).
This way the user do not need to modify the block design, just
set the required rate in system_bd.tcl.
This commit does not contain any functional changes.
Explicitly select MIO 52 and 53 pins to be part of MDIO port.
MIO_52_PIN (MDIO 0 Clock, Output)
MIO_53_PIN (MDIO 0 Data, Input/Output)
After the tool version change, this pins where by default connected
as MIO GPIOs.
Explicitly disable the "Transfer Start Synchronisation Support"
since the sync lines are not connected in this project.
If the sync input line (s_axi_user[0] or fifo_wr_sync) are not connected,
Vivado 2017.4.1 no longer connects them to the defaultValue defined
in the axi_dmac ip (1). Instead he uses the defaulValue field defined
in the interface definition which in case of both interfaces is 0;
Loop back the unused GPIO pins, and add all the SPI interface to system
wrapper instance.
The following system_top modules were changed:
- ad738x_fmc
- ad7616_sdz
- ad77681evb
- ad77681evb
- ad7768evb
- ad9739a_fmc
- ad9434
- adrv9739
- fmcadc5
- ad6676evb
- ad9265
- ad5766
- fmcomms5
- m2k
The constraint where added to remove timing problems on the reset path.
The constraint paths do not match anymore. The resets are used in a synchronous
way so we don't need the timing exceptions anyway.
Projects affected by this change:
- daq3
- adrv9739
- ad6676evb
- fmcadc5
- daq2/kcu105
- fmcadc2
- adrv9371x
- fmcomms11/zc706
- fmcjesdadc1
By default every base design has a SPI interface (hard or soft). In
case of soft IPs (xilinx), the input registers of the interface by default have
the IOB attribute set to TRUE. If the interface are not used, the tool will
generate a critical warning, stating that IOB registers are not connected to
an IO buffer.
The following constraints are disabling the above setup for every base
design, which using a soft SPI IP.
Set the properties to mirror the hardware configuration so
the Vivado tools can provide warnings if there are any conflicts
between configuration pin settings, such as an IOSTANDARD
on a multi-function configuration pin that conflicts with the
configuration voltage.
see:
https://www.xilinx.com/support/documentation/user_guides/ug570-ultrascale-configuration.pdf
The following base constraints were updated:
- kcu105
- kc705
- vc707
- ac701
To reduce compilation time use default stratagies for synthesis and
implementation. If a project will require custom strategies, enable it
just for that particular project.
This modification will affect both Intel and Xilinx projects.
Vivado sometimes generates semi-valid or invalid warnings and critical warnings.
In the past these messages were silenced, by changing its message severity.
These setups were scattered in multiple scripts. This commit is an attempt
to centralize it and make it more maintainable and easier to review it.
The script specifies the OUT_CLK_SEL and SYS_CLK_SEL parameter values as
binary numbers. But the tools will interpret them as decimal number
resulting in the wrong selection for OUT_CLK_SEL. Specify the parameter
values as decimal values to avoid this.
This is not a critical issue since software will overwrite this setting at
system boot-up. But it should be fixed anyway.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The script specifies the OUT_CLK_SEL and SYS_CLK_SEL parameter values as
binary numbers. But the tools will interpret them as decimal number
resulting in the wrong selection for OUT_CLK_SEL. Specify the parameter
values as decimal values to avoid this.
This is not a critical issue since software will overwrite this setting at
system boot-up. But it should be fixed anyway.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Fixes the following warning:
[Synth 8-2611] redeclaration of ansi port rx_sysref is not allowed
This is a leftover of commit 1c23cf4621 ("all: Update verilog files to
verilog-2001").
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Fixes the following warnings:
[Synth 8-2611] redeclaration of ansi port txnrx_0 is not allowed
[Synth 8-2611] redeclaration of ansi port enable_0 is not allowed
[Synth 8-2611] redeclaration of ansi port enable_1 is not allowed
[Synth 8-2611] redeclaration of ansi port txnrx_1 is not allowed
This is a leftover of commit 1c23cf4621 ("all: Update verilog files to
verilog-2001").
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Make sure that the axi_adxcvr instances are configured with the same
transceiver type as the util_adxcvr.
This is necessary for software to be able to detect the transceiver type
and support dynamic reconfiguration.
It is also necessary for correct eye scan support in the axi_adxcvr block.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Make sure that the axi_adxcvr instances are configured with the same
transceiver type as the util_adxcvr.
This is necessary for software to be able to detect the transceiver type
and support dynamic reconfiguration.
It is also necessary for correct eye scan support in the axi_adxcvr block.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Fix the location assignment of the transceiver blocks to get the correct
lane mapping.
Note that the comments indicating the expected lane mapping are correct,
but the actual transceiver location assignments were not.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The external reference clock runs at 122.88 MHz by default. This means that
the QPLL feedback divider needs to be set to 80 so that the VCO is inside
the locking range (9.8 GHz - 16.375 GHz).
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
DAC data underflow from the DMA, was not connected to anything. This
signal should be connected to the util_rfifo, which will forward it to
the device core.
+ Build both the read and write logic around an FSM
+ Consistent naming of registers and wires
+ Add support for burst lenghts higher than one, current burst lenght
is 64
+ Fix all the bugs, and make it work (first bring up with
adrv9371x/a10soc)
If the ADI_HDL_DIR or ADI_PHDL_DIR are set on Windows platforms, an
invalid TCL character (e.g. backslash) may be used as a file separator,
causing issues with the build / library scripts.
Normalize the paths before using them as global TCL variables.
Add support for the AD-FMCDAQ2-EBZ on the Arria10 SoC development board platform.
In its default configuration the Arria10 SoC development board is not fully
compatible with the AD-FMCDAQ2-EBZ and a slight rework is necessary,
changing the position of four 0 Ohm resistors:
R610: DNI -> R0
R611: DNI -> R0
R612: R0 -> DNI
R613: R0 -> DNI
R620: DNI -> R0
R632: DNI -> R0
R621: R0 -> DNI
R633: R0 -> DNI
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Rework the peripheral address to match the updated semantics of
ad_cpu_interconnect, which expects that the addresses are in the range of
0x00010000 - 0x001fffff. This includes updating the base addresses as well
as compressing the used address range to fit into the 2Mb window.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The DDR memory reference clock on the A10SoC development board is
differential. Currently the EMIF core it is configured for single-ended
configuration, which causes it to generate incorrect IOSTANDARD
constraints. Those incorrect constraints get overwritten again in
system_assign.tcl, so things are working, but this generates a warning when
building the design
Configure the EMIF core correctly and remove the manual constraint overwrite since
they are no longer necessary.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
There is no guarantee that the external reset de-assertion is synchronous
to the sys_clk, yet the clock bridge marks the reset de-assertion as
synchronized to the clock. This can cause recovery or removal timing
violations for the registers affected by this reset signal and potentially
bring the system into an invalid state after the reset is de-asserted.
Mark the reset as not synchronized to the clock signal, this will make sure
that Qsys inserts the proper reset synchronizers where required.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Currently the TX lane mapping is implemented by having to connect tx_phy_s_* to
the tx_ip_s_* and the tx_phy_d_* to the tx_ip_d_* signals in the system
qsys file in the desired order.
Re-work things so that instead the lane mapping is provided through the
TX_LANE_MAP parameter. The parameter specifies in which order logical lanes
are mapped onto the physical lanes.
The appropriate connections are than made inside the core according to this
parameter rather than having to manually connect the signals externally.
In order to generate a 1-to-1 mapping the TX_LANE_MAP parameter can be left
empty.
This change slightly reduces the boiler-plate code that is necessary to
setup the transceiver.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
+ Add a HDL parameter for the PPS receiver module :
PPS_RECEIVER_ENABLE. By default the module is disabled.
+ Add the CMOS_OR_LVDS_N and PPS_RECEIVER_ENABLE into the CONFIG
register
+ Define a pps_status read only register, which will be asserted, if the free
running counter reach a certain fixed threshold. (2^28) The register can
be deasserted by an incomming PPS only.
Some of the standard Quartus components (especially the Merlin cores) generate
quite a few synthesis warnings. Lets assume these are false positives and
disable the warnings.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The PLL frequency must be half of the lane rate and the core clock rate
must be lane rate divided by 40. There is no other option, otherwise things
wont work.
Instead of having to manually specify PLL and core clock frequency derive
them in the transceiver script. This reduces the risk of accidental
misconfiguration.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
While things seem to work fine with only specifying the the IO standard for
the positive side of differential signals Quartus will issue a warning
about incomplete constraints if the IO standard is not specified for the
the neagtive side as well. To avoid these warnings add the missing
constraints.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Fix a copy and paste error and specify the IO_STANDARD for all gpio_bd_i
rather than twice for half of them.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Both the sys_hps.f2sdram_clock and the sys_dma_clk.clk signal are in the
same clock domain. They are both driven by the same clock. And even though
qsys is capable of detecting this it seems qsys interconnect is not able to
infer this and inserts a extra clock domain crossing bridge between the DMA
and the HPS AXI system memory interface.
To avoid this connect the sys_dma_clk.clk to the sys_hps.f2sdram_clock so
that all components are driven by the same qsys clock signal.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Qsys allows to query to query the clock domain that is associated with a
clock input of a peripheral. This allows to automatically detect whether
the different clocks of the DMAC are asynchronous and CDC logic needs to be
inserted or not.
Auto-detection has the advantages that the configuration parameters don't
need to be set manually and the optional configuration will be choose
automatically. There is also less chance of error of leaving the settings
in a wrong configuration when e.g. the clock domains change.
In case the auto-detection should ever fail configuration options that
provide a manual overwrite are added as well.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Both the sys_hps.f2sdram_clock and the sys_dma_clk.clk signal are in the
same clock domain. They are both driven by the same clock. And even though
qsys is capable of detecting this it seems qsys interconnect is not able to
infer this and inserts a extra clock domain crossing bridge between the DMA
and the HPS AXI system memory interface.
To avoid this connect the sys_dma_clk.clk to the sys_hps.f2sdram_clock so
that all components are driven by the same qsys clock signal.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the sys_dma_clk clock module for clock and reset signals of the data
path, rather than using the A10GX specific sys_ddr3_cntrl signals. This
enables compatibility for all Altera/Intel platforms.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The mb_intrs signal is never driven, it is a leftover of an earlier version
of the file, remove it.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The DAQ3 does not use a 1-to-1 lane mapping for the DAC JESD204 link.
Provide the proper mapping when setting up the transceiver connections.
Without this the payload data will be mapped incorrectly and the
transmitted signals are scrambled.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Provide the correct lane mapping for the DAQ2 DAC lanes which do not follow
a 1-to-1 mapping between physical and logical lanes due to PCB layout
constraints.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Add a parameter to the ad_xcvrcon function that allows to provide a mapping
between logical and physical lanes. By default if no lane map is provided
the logial and physical lanes are mapped 1-to-1. If a lane map is provided
logical lane $n is mapped onto physical lane $lane_map[$n].
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Convert the FMCOMMS11 project to the ADI JESD204 link layer cores. The
change is very straight forward, but a matching change on the software side
is required.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Convert the FMCJESDADC1 project to the ADI JESD204 link layer core. The
change is very straight forward, but a matching change on the software side
is required.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Convert the FMCADC4 project to the ADI JESD204 link layer core. The change
is very straight forward, but a matching change on the software side is
required.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Convert the FMCADC2 project to the ADI JESD204 link layer core. The change
is very straight forward, but a matching change on the software side is
required.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Convert the DAQ3 project to the ADI JESD204 link layer cores. The change is
very straight forward, but a matching change on the software side is
required.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Convert the DAQ2 project to the ADI JESD204 link layer cores. The change is
very straight forward, but a matching change on the software side is
required.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Convert the ADRV9371 project to the ADI JESD204 link layer cores. The
change is very straight forward, but a matching change on the software side
is required.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Convert the AD6676EVB project to the ADI JESD204 link layer core. The
change is very straight forward, but a matching change on the software side
is required.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Let the ad_xcvrcon handle the ADI JESD204 link layer cores. The function
will detect the JESD204 core vendor and connect the appropriate signals
based on it. This means it can still be used with the Xilinx JESD204 core
as well.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
When trying to use ad_cpu_interconnect to connect to a AXI interface that
is a outer port of a hierarchy this will fail at the moment as it kind find
the matching clock and reset signals.
Add support for traversing into the hierarchy and find the final target AXI
port inside the hierarchy. Then find the matching clock and reset and
traverse them back the corresponding hierarchy outer ports.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Move the CDC helper modules to a dedicated helper modules. This makes it
possible to reference them without having to use file paths that go outside
of the referencing project's directory.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The util_cpack core is currently not used by the M2K project. Refresh the
Makefiles to reflect this.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
All the hdl (verilog and vhdl) source files were updated. If a file did not
have any license, it was added into it. Files, which were generated by
a tool (like Matlab) or were took over from other source (like opencores.org),
were unchanged.
New license looks as follows:
Copyright 2014 - 2017 (c) Analog Devices, Inc. All rights reserved.
Each core or library found in this collection may have its own licensing terms.
The user should keep this in in mind while exploring these cores.
Redistribution and use in source and binary forms,
with or without modification of this file, are permitted under the terms of either
(at the option of the user):
1. The GNU General Public License version 2 as published by the
Free Software Foundation, which can be found in the top level directory, or at:
https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html
OR
2. An ADI specific BSD license as noted in the top level directory, or on-line at:
https://github.com/analogdevicesinc/hdl/blob/dev/LICENSE
Currently the DAC FIFO size for the ZC706 DAQ2 project is 16kB. This is
quite a limiting size for practical applications. Increase the size to 1MB
to allow loading larger waveforms.
In this configuration the DAC FIFO will use half of the available BRAM
cells in the FPGA. This still leaves quite a few BRAMs available for
user application logic added to the design. If a user design should run out
of BRAMs nevertheless they can reduce the FIFO size, if not required by the
application, to free up some cells.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
If a parameter value is defined as a string binary (e.g. "001001000000"),
it can confuse the tool, and the value may be used as a decimal number.
To prevent this issue and to improve readability converting all the binary
constants into hexadecimal.
Configure the interconnect and offload modules inorder to activate
its interfaces. In the past, these interfaces did not have any
parameter dependencies, so this configuration were not required.
It seems that there are some dependencies between the fir compiler
cores parameters. With the old order of the parameter settings,
the tool throws the following warning:
CRITICAL WARNING: [BD 41-237] Bus Interface property TDATA_NUM_BYTES
does not match between /processing/sequencer/i_q_filtered(4)
and /processing/lpf/M_AXIS_DATA(5)
Depending on the configuration of the clock source type of the input clock
the clocking wizard will instantiate all kinds of buffers on the input
clock signal.
For these particular projects there is no need to add any kind of buffer
since the source is already coming from a global clock buffer. So set the
configuration accordingly.
Avoids the following warning:
[Opt 31-32] Removing redundant IBUF since it is not being driven by a
top-level port. i_system_wrapper/system_i/sys_audio_clkgen/inst/clkin1_ibufg
Resolution: The tool has removed redundant IBUF. To resolve this
warning, check for redundant IBUF in the input design.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
There is no need for the audio clock to be phase aligned to its source
clock. When phase alignment is disabled the MMCM uses an internal feedback
path without requiring external resources, so disable it.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Instead of manually specifying the input clock frequency let the core infer
it automatically. This makes it more straight forward to change the clock
frequency.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Neither the reset nor the locked signal is used in this design, so disable them. Avoids warnings about unconnected pins.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Depending on the configuration of the clock source type of the input clock
the clocking wizard will instantiate all kinds of buffers on the input
clock signal.
For these particular projects there is no need to add any kind of buffer
since the source is already coming from a global clock buffer. So set the
configuration accordingly.
Avoids the following warning:
[Opt 31-32] Removing redundant IBUF since it is not being driven by a
top-level port. i_system_wrapper/system_i/sys_audio_clkgen/inst/clkin1_ibufg
Resolution: The tool has removed redundant IBUF. To resolve this
warning, check for redundant IBUF in the input design.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
There is no need for the audio clock to be phase aligned to its source
clock. When phase alignment is disabled the MMCM uses an internal feedback
path without requiring external resources, so disable it.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Instead of manually specifying the input clock frequency let the core infer
it automatically. This makes it more straight forward to change the clock
frequency.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The input clock frequency of the axi_clkgen was changed from 200 MHz to
100 Mhz. Update the divider settings accordingly to keep the standard
default output frequency of 148.5 MHz.
The incorrect divider settings did not affect operation of the design since
software reprograms them at startup anyway, but changing them avoids the
following warning:
[DRC 23-20] Rule violation (AVAL-46) v7v8_mmcm_fvco_rule1 - The current computed target frequency, FVCO, is out of range for cell i_system_wrapper/system_i/axi_hdmi_clkgen/inst/i_mmcm_drp/i_mmcm. The computed FVCO is 445.455 MHz. The valid FVCO range for speed grade -1 is 600MHz to 1200MHz. The cell attribute values used to compute FVCO are CLKFBOUT_MULT_F = 49.000, CLKIN1_PERIOD = 10.00000, and DIVCLK_DIVIDE = 11 (FVCO = 1000 * CLKFBOUT_MULT_F/(CLKIN1_PERIOD * DIVCLK_DIVIDE)).
This violation may be corrected by:
1. The timer uses timing constraints for clock period or clock frequency that affect CLKIN1 to set cell attribute CLKIN1_PERIOD, over-riding any previous value. This may already be in place and, if so this violation will be resolved once Timing is run. Otherwise, consider modifying timing constraints to adjust the CLKIN1_PERIOD and bring FVCO into the allowed range.
2. In the absence of timing constraints that affect CLKIN1, consider modifying the cell CLKIN1_PERIOD to bring FVCO into the allowed range.
3. If CLKIN1_PERIOD is satisfactory, modify the CLKFBOUT_MULT_F or DIVCLK_DIVIDE cell attributes to bring FVCO into the allowed range.
4. The MMCM configuration may be dynamically modified by use of DRP which is recognized by an ACTIVE signal on DCLK pin.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
There is no need for the audio clock to be phase aligned to its source
clock. When phase alignment is disabled the MMCM uses an internal feedback
path without requiring external resources, so disable it.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Depending on the configuration of the clock source type of the input clock
the clocking wizard will instantiate all kinds of buffers on the input
clock signal.
For these particular projects there is no need to add any kind of buffer
since the source is already coming from a global clock buffer. So set the
configuration accordingly.
Avoids the following warning:
[Opt 31-32] Removing redundant IBUF since it is not being driven by a
top-level port. i_system_wrapper/system_i/sys_audio_clkgen/inst/clkin1_ibufg
Resolution: The tool has removed redundant IBUF. To resolve this
warning, check for redundant IBUF in the input design.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Instead of manually specifying the input clock frequency let the core infer
it automatically. This makes it more straight forward to change the clock
frequency.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
For the M2K standalone version we run the interface clock at a lower rate
to reduce the power consumption. While this is not necessary on the ZED
board we also run the interface at a lower rate for consistency.
Currently the video DMA on the ZED board uses the interface clock for the
data path as well. This is now too slow to support 1080p@60Hz so move it
over to a faster clock.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Instead of manually specifying the input clock frequency let the core infer
it automatically. This makes it more straight forward to change the clock
frequency.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
At the moment the PS7 is using three PLLs to generate its clocking tree.
One for the DDR, one for the ARM and one for the IO. This allows to run all
components at their respective maximum clock and extract maximum
performance from all components.
With some slight modifications it is possible to trade maximum performance
for a reduction in power consumption by using the same PLL for all three
sets of components and disabling the other two PLLs.
The CPU is now running at 500MHz rather than 666MHz and the DDR memory at
500MHz rather than 533MHz. This reduces power consumption by ~125mW.
This is OK since neither of them is a bottleneck for overall system
performance.
In addition software will downclock the CPU to 250MHz when full performance
is not required.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The 200 MHz clock was only used as the IODELAY controller clock. Since the
design does not use any IODELAYs anymore this clock can be removed.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The debug register logic for the DMA take up a fair amount of resources.
Disabling them frees up space in the FPGA and also helps a bit with power.
Since those registers are mainly useful in development and not so much in
production the change shouldn't have any visible external effects.
It is possible to re-enable the debug registers by setting DEBUG_BUILD=1.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The global reset signals are only asserted for a short moment during system
startup and deasserted during normal operation, which is the case we care
about for power analysis. Giving them a static switching probability
indicating that they are always de-asserted will yield better results for
power analysis.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The RX datapath has a lot of things (IQ correction, DC filter, ...) that
take up a lot of space which are all not really needed in this project. So
disable the RX datapath.
It was previously enabled because the ad9963 core did not perform
sign-extension on the ADC data signal when the datapath was disabled. But
this has now been addressed.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
At the moment the register map fabric and DMA system memory side are
clocked by the 100MHz sys_cpu_clk. While this works fine that is a lot
faster than the clock has to run. There are only a few 100 register map
accesses per seconds at most and they are not on timing critical paths. The
penalty from clocking them at a lower rate is negligible for the overall
system performance.
The maximum clock rate for the DMAs is determined by the throughput
requirements. This is 200 Mbytes/s for the logic analyzer, pattern
generator and each of the DAC DMAs and 400 Mbytes/s for the ADC DMA.
The DMA datapath width is 64-bit so the required clock rates are 25MHz and
50MHz respectively. Some headroom is required to accommodate for occasional
bubble cycles on the data bus and the difference in reference clocks for
the converter and processing system.
The sys_cpu_clk is reduced to 27.8MHz which is fast enough for all but the
ADC DMA. For the ADC DMA a new clock domain running at 55.6 MHz is
introduced.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The MMCM generating the logic analyzer clock unfortunately consumes a
disproportionately large amount of power compared to the rest of the
design.
Replace it by sourcing the logic analyzer clock from one of the Zynq FCLKs.
The IO PLL is running anyway so the power requirement is much lower.
For the time being this means we loose the ability to source the clock from
an external pin. But that feature is not supported by software at the
moment anyway. We'll bring it eventually when required.
This changes reduces power consumption by roughly 100mW.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
We always have both ADC channels enabled and the cpack core takes up a fair
amount of space, so remove it for now. Might come back later when we really
need it.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new axi_rd_wr_combiner module to ... the read and write DMA
interfaces into a single interface. This allows the AXI interconnect
completely optimize itself away and reduce the overall resource utilization
of the project.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
ad_cpu_interconnect will make sure to connect the clock and the reset of
the AXI interface. Remove the redundant manual assignments.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Xilinx recommends that all synchronizer flip-flops have
their ASYNC_REG property set to true in order to preserve the
synchronizer cells through any logic optimization during synthesis
and implementation.
Because the S_AXI interface of the axi_adxcvr core was infered
using the process adi_ip_properties, the interface address range
has changed from 4k to 64k. As a result, all the addresses of
the axi_adxcvr cores were changed and realigned.
The ADV7511 samples the parallel data bus at the rising edge of sample
clock. Generate the clock so that the falling edge is aligned to updating
the bus data. This creates larger timing margins on each side of the
sampling edge and makes the design more robust.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Increase the RX DMA FIFO to be able to better compensate for momentarily
memory bus contention. This has shown to resolve occasional overflows that
would occur under high system memory load.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Connect the HDMI RX core output clock to the DMA rather than connecting the
HDMI RX input clock directly. This will allow the HDMI RX core to modify
the clock and e.g. insert clock buffers or similar.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The ADV7611 is rated for a maximum clock rate of 165MHz. Increase the clock rate constraint to match this.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
There is a bug in the ps7 component specification that causes critical
warnings to appear in the build log if DMA interface 0 is disabled, but any
other DMA interface is enabled.
Work around this issue by using DMA interface 0 and 1 instead of 1 and 2
for the I2S DMA.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>