The MAX_BYTES_PER_BURST option allows to configure the maximum bytes that
are part of a burst. This can be an arbitrary value.
At the same time there is a limit of how many bytes can be supported by the
memory buses. A AXI3 interface supports a maximum of 16 beats per burst
and a AXI4 interface supports a maximum of 256 beats per burst.
At the moment the it is possible to specify a MAX_BYTES_PER_BURST value
that exceeds what can be supported by the AXI memory-mapped bus. If that is
the case undefined behavior will occur and the DMAC will function
incorrectly.
To avoid this make sure that the MAX_BYTES_PER_BURST value does not exceed
the maximum that can be supported by the interfaces.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The width of the AXI burst length field depends on the AXI standard
version. For AXI3 the width is 4 bits allowing a maximum burst length of 16
beats, for AXI4 it is 8 bits wide allowing a maximum burst length of 256
beats.
At the moment the width of the length signals are determined by type of the
source AXI interface, even if the source interface type is not AXI. This
means if the source interface is set to AXI3 and the destination interface
is set to AXI4 the internal width of the signal for all interfaces will be
4 bits. This leads to a truncation of the destination bus length field,
which is supposed to be 8 bits.
If burst are generated that are longer than 16 beats the upper bits of the
length signal will be truncated. The result of this will be that the
external AXI slave interface (e.g. the DDR memory) and the internal logic
in the DMA disagree about burst length. The DMA will eventually lock up
when its internal buffers are full.
To avoid this issue have different configuration parameters for the source
and destination interface that configure the AXI bus length field width.
This way one of the interfaces can be configured for AXI3 and the other for
AXI4 without interfering with each other.
Fixes: commit 495d2f3056 ("axi_dmac: Propagate awlen/arlen width through the core")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
This commit fixes the following warning from the IP packaging flow:
"[IP_Flow 19-801] The last file in file group "Synthesis" should be an HDL file:
"axi_dmac_constr.ttcl". During generation the IP Flow uses the last file to
determine library and other information when generating the top wrapper file.
If possible, please make sure that non-HDL files are located earlier in the list
of files for this file group."
Having the ttcl or other non HDL file at the end of the file group causes issues
when the project preferred language is set to VHDL. Since the synthesis file group
is set to "xilinx_anylanguagesynthesis" the tool tries to guess the type of wrapper
to be generated for that IP based on the last file from the file group.
If the file is non HDL then he defaults to the preferred language (this case VHDL)
Due some issue when the tool tries to create a VHDL wrapper for an IP that has
a Verilog top file with boolean parameters set from the IP packager he fails.
After we reorder the files after each non HDL file addition
he will create a correct Verilog wrapper for it with all parameters
which can be integrated in a VHDL system top file without issues.
Fixes the following warning:
[BD 41-1731] Type mismatch between connected pins: /util_fmcomms11_xcvr/tx_out_clk_0(clk) and /axi_ad9162_core/tx_clk(undef)
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
When the DMAC is used in async clock domains the data FIFO instantiate
an ad_mem component to handle properly the clock crossing.
For Intel, this mode is used only in FMCJESDADC1 designs but without this
an error could appear in other projects too if the user reconfigures the core.
The set_false_path constraint targeted to the *ram* cells of the dmac
matched several intra clock domain paths where the timing analysis got
ignored resulting in intermitent data integrity issues.
Exposed AXI3 interface on the Intel version of the IP for UI and feature consistency.
Some of the signals that are defined as optional in the AMBA standard
are marked as mandatory in Qsys in case of AXI3. Because of this such signals
were added to the interface of the DMAC and driven with default values.
For Xilinx in order to keep existing behavior the newly added signals
are hidden from the interface.
New parameters are added to define the width of the AXI transaction IDs;
these are hidden from the UI; We can add them to the UI if the fixed size
of the IDs will cause port incompatibility issues.
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.
Fix the following warnings that are generated by Quartus:
Warning (10230): Verilog HDL assignment warning at ad_sysref_gen.v(68): truncated value with size 32 to match size of target (8)
No functional changes.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Fix the following warnings that are generated by Quartus:
Warning (10036): Verilog HDL or VHDL warning at ad_datafmt.v(69): object "sign_s" assigned a value but never read
Move the sign_s and signext_s signals into the generate block in which
they are used.
No functional changes.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Fix the following warnings that are generated by Quartus:
Warning (10236): Verilog HDL Implicit Net warning at util_dacfifo.v(257): created implicit net for "dac_mem_ren_s"
Warning (10230): Verilog HDL assignment warning at util_dacfifo.v(166): truncated value with size 32 to match size of target (10)
Warning (10230): Verilog HDL assignment warning at util_dacfifo.v(266): truncated value with size 32 to match size of target (10)
Warning (10230): Verilog HDL assignment warning at util_dacfifo.v(268): truncated value with size 32 to match size of target (10)
No functional changes.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Not all echo implementations support escape characters and newline
insertion. Make sure quiet.mk does not use escape characters to generate
newlines and instead split the output over multiple echo commands to get
the same effect.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The primary use-case of the DMA controller is in non-2D mode. Make this the
default, since allows projects to instantiate the controller with the
default configuration without having to explicitly disable 2D support.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
All the file names must have the same name as its module. Change all the
files, which did not respect this rule.
Update all the make files and Tcl scripts.
Most of the cores are fully covered by the generic constraint files. When
the constraints where moved from the core specific to the generic
constraint files some empty core constraints files where left around. These
don't do anything, so remove them.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
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>
The include files are currently only implicitly added to the component file
list. Do it explicitly as this will make sure that they show up in the
generated Makefile dependency list.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Adrian Costina
Lars-Peter Clausen
Laszlo Nagy
Istvan Csomortani