The timing exceptions for the debug paths are currently a bit to broad and
can include paths that should not have an exception.
All the debug signals are coming from the i_request_arb instance, so
include that in the match to avoid false positives.
For most projects this wont have been a problem since there is usually a
fair amount of slack on the paths that were affected by this. But in
projects with high utilization this might result in undefined behavior.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Fix the read side of the CDC data FIFO. The read address generation did not
function correctly.
Redesign the read side of the FIFO, and make sure that it becomes empty after
the DMA transfer ends; and never get stock in a cyclic mode.
The dac_last signal is not used anywhere in the module. Remove it and its
synchronization registers.
Fixes the following warnings:
[Synth 8-6014] Unused sequential element dac_dlast_reg was removed. ["axi_dacfifo_rd.v":372]
[Synth 8-6014] Unused sequential element dac_dlast_m1_reg was removed. ["axi_dacfifo_rd.v":373]
[Synth 8-6014] Unused sequential element dac_dlast_m2_reg was removed. ["axi_dacfifo_rd.v":374]
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Commit bfc8ec28c3 ("util_axis_fifo: instantiate block ram in async mode")
added the read-enable (reb) signal to the ad_mem block.
It didn't update the ad_mem instance in axi_dacfifo_address_buffer.v. This
results in the read-enable of the address_buffer being tied to 0.
Fix this by connecting the same signal that increments the read address.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The DMAC implementation guarantees that the expression `dma_valid &
dma_xfer_req` is always identical to just dma_valid.
When generating the util_dacfifo dma_wren_s signal the optimizer doesn't know
of this though and hence will route both signals into the LUT that drives
the write enable for the BRAMs.
Simplify the expression by removing dma_xfer_req from it. Considering this
can be a fairly high fan-out net and is typically the bottleneck for the
util_dacfifo timing this helps to improve the timing.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Some parts of the util_cdc library rely on dead logic elimination to remove
unused logic. Unfortunately with newer Vivado versions this results in
warnings about unused sequential elements being removed. Like:
WARNING: [Synth 8-6014] Unused sequential element cdc_sync_stage1_reg was removed.
To avoid this encase the logic in generate blocks that makes sure they are
not generated when not needed.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
This reverts commit 4b1d9fc86b "axi_dmac: Modified in order to avoid
vivado crash".
Vivado no longer crashes and this structure is much more efficient when it
comes to resource usage and timing. The intention here is to create a 1-bit
memory that is N entries deep and not a N bit signal.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The burst_count signal and its derived signals are not used until the
burst_count has been explicitly initialized by loading a transfer. There is
no need to have a reset.
This reduces the fan-out of the reset signal.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The data path register of the 2d_transfer module are qualified by the
corresponding valid signal. Their content is not used until they have been
explicitly initialized. There is no need to reset them explicitly.
This reduces the fan-out of the reset signal.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
There is no need to reset the data path in the address generator. The
values of the register on the data path are not used until they have been
explicitly initialized. Removing the reset simplifies the structure and
reduces the fan-out of the reset signal.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Xilinx tools don't allow to use $clog2() when computing the value of a
localparam, even though it is valid Verilog.
For this reason a parameter was used for BYTES_PER_BURST_WIDTH so far. But
that generates warnings from both Quartus and Vivado since the parameter is
not part of the parameter list.
Fix this by changing it to a localparam and computing the log2() manually.
The upper limit for the burst length is known to be 4k, so values larger
than that don't have to be supported.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
A larger store-and-forward memory provides better protection against worst
case memory interface latencies by being able to store more data before
over-/underflowing.
Based on empirical testing it was found that using a size of 4 bursts can
still result in underflows/overflows under certain conditions. These do not
happen when using a size of 8 bursts.
This change does not significantly increase resource consumption. Both on
Intel and Xilinx the block RAM has a minimum depth of 512 entries. With a
default burst length of 16 beats that allows for up to 32 bursts without
requiring additional block RAM.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The label for the store-and-forward memory size configuration option at the
moment is just "FIFO Size" and while the store-and-forward memory uses a
FIFO that is just a implementation detail.
Change the label to "Store-and-Forward Memory Size". This is more
descriptive as it references the function not the implementation.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
For correct operation the store-and-forward memory size must be a
power-of-two in the range of 2 to 32.
This is simple enough so we can list all values and let the IP Integrator
and QSYS perform proper validation of the parameter.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
This comment hasn't been true in a long long time. It does not have any
relation to the code around it anymore.
So just remove it.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
* jesd204: Add RX error statistics
Added 32 bit error counter per lane, register 0x308 + lane*0x20
On the control part added register 0x244 for performing counter reset and counter mask
Bit 0 resets the counter when set to 1
Bit 8 masks the disparity errors, when set to 1
Bit 9 masks the not in table errors when set to 1
Bit 10 masks the unexpected k errors, when set to 1
Unexpected K errors are counted when a character other than k28 is detected. The counter doesn't add errors when in CGS phase
Incremented version number
Commit e6aacd2f56 ("axi_dmac: Better support debug IDs when ID_WIDTH !=
3") managed to get the order of the IDs in the debug register wrong.
Restore the original order.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The cfg_links_disable register will mask the SYNC lines, disabled links
will always have a de-asserted SYNC (logic state HIGH).
The FSM will stay in CGS as long as there is one active link with an
asserted SYNC (logic state LOW).
Update the test bench to generate the SYNC signals in different clock
edges, so it can test all the possible scenarios.
A multi-link is a link where multiple converter devices are connected to a
single logic device (FPGA). All links involved in a multi-link are synchronous
and established at the same time. For a TX link this means that the FPGA receives
multiple SYNC signals, one for each link. The state machine of the TX link
peripheral must combine those SYNC signals into a single SYNC signal that is
asserted when either of the external SYNC signals is asserted.
Dynamic multi-link support must allow to select to which converter devices on
the multi-link the SYNC signal is propagated too. This is useful when depending
on the use case profile some converter devices are supposed to be disabled.
Add the cfg_links_disable[0x081] register for multi-link control and
propagate its value to the TX FSM.
A multi-link is a link where multiple converter devices are connected to a
single logic device (FPGA). All links involved in a multi-link are synchronous
and established at the same time. For a RX link this means that the SYNC signal
needs to be propagated from the FPGA to each converter.
Dynamic multi-link support must allow to select to which converter devices on
the multi-link the SYNC signal is propagated too. This is useful when depending
on the usecase profile some converter devices are supposed to be disabled.
Add the cfg_links_disable[0x081] register for multi-link control and
propagate its value to the RX FSM.
Split the register map code into a separate sub-module instead of having it
as part of the top-level axi_dmac.v file.
This makes it easier to component test the register map behavior
independently from the DMA transfer logic.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
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>
When the axi_ad9144 core is configured for DUAL mode two of the four
channels are unused. But there is still some residual logic left for those
unused channels that can't be removed by the optimizer.
Completely disable the unused channels by reducing the channel and lane
count. This slightly reduces utilization.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Replace the axi_ad9152 implementation with the new generic JESD204
interface DAC core. The replacement is functionally equivalent.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Replace the axi_ad9144 implementation with the new generic JESD204
interface DAC core. The replacement is functionally equivalent.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
For most of the DACs that use JESD204 as the data transport the digital
interface is very similar. They are mainly differentiated by number of
JESD204 lanes, number of converter channels and number of bits per sample.
Currently for each supported converter there exists a converter specific
core which has the converter specific requirements hard-coded.
Introduce a new generic core that has the number of lanes, number of
channels and bits per sample as synthesis-time configurable parameters. It
can be used as a drop-in replacement for the existing converter specific
cores.
This has the advantage of a shared and reduced code base. Code improvements
will automatically be available for all converters and don't have to be
manually ported to each core individually.
It also makes it very easy to introduce support for new converters that
follow the existing schema.
Since the JESD204 framer is now procedurally generated it is also very
easy to support board or application specific requirements where the lane
to converter ratio differs from the default (E.g. use 2 lanes/2 converters
instead of 4 lanes/2 converters).
This new core is primarily based on the existing axi_ad9144.
For the time being the core is not user instantiatable and will only be
used as a based to re-implement the converter specific cores. It will be
extended in the future to allow user instantiation.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Replace the axi_ad9680 implementation with the new generic JESD204
interface ADC core. The replacement is functionally equivalent.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Replace the axi_ad9250 implementation with the new generic JESD204
interface ADC core. The replacement is functionally equivalent, except that
the converter clock ratio is now correctly reported as 2 rather than 1 as
before.
Also the adc_rst output port is removed. It is not used in any design. The
current guidelines for the reset for the JESD204 subsystem is to use an
external reset generator.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Replace the axi_ad6676 implementation with the new generic JESD204
interface ADC core. The replacement is functionally equivalent, except that
the converter clock ratio is now correctly reported as 2 rather than 1 as
before.
Also the adc_rst output port is removed. It is not used in any design. The
current guidelines for the reset for the JESD204 subsystem is to use an
external reset generator.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
For most of the ADCs that use JESD204 as the data transport the digitial
interface is very similar. They are mainly differentiated by number of
JESD204 lanes, number of converter channels and number of bits per sample.
Currently for each supported converter there exists a converter specific
core which has the converter specific requirements hard-coded.
Introduce a new generic core that has the number of lanes, number of
channels and bits per sample as synthesis-time configurable parameters. It
can be used as a drop-in replacement for the existing converter specific
cores.
This has the advantage of a shared and reduced code base. Code improvements
will automatically be available for all converters and don't have to be
manually ported to each core individually.
It also makes it very easy to introduce support for new converters that
follow the existing schema.
Since the JESD204 deframer is now procedurally generated it is also very
easy to support board or application specific requirements where the lane
to converter ratio differs from the default (E.g. use 2 lanes/2 converters
instead of 4 lanes/2 converters).
This new core is primarily based on the existing axi_ad9680.
For the time being the core is not user instantiatable and will only be
used as a based to re-implement the converter specific cores. It will be
extended in the future to allow user instantiation.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The ADC DMA will never underflow and unsurprisingly the adc_dunf signal is
never used anywhere. It is very unlikely it will ever be used, so remove
it.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The DAC DMA will never overflow and unsurprisingly the dac_dovf signal is
never used anywhere. It is very unlikely it will ever be used, so remove
it.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Some designs choose to swap the positive and negative side of the of the
JESD204 lanes. One reason for this would be because it can simplify the
PCB layout. The polarity is in most cases also only applied to a subset of
the used lanes.
Add support for this to the util_adxcvr module. This done by adding new
parameter to the modules that allows to specify a per lane polarity
inversion. Each bit in the parameter corresponds to one lane. If the bit is
set the polarity is inverted for his lane. E.g. setting the parameter to
0xc will invert the 3rd and 4th lane.
The setting is forwarded to the Xilinx transceiver for the corresponding
lane.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Some designs choose to swap the positive and negative side of the of the
JESD204 lanes. One reason for this would be because it can simplify the
PCB layout. The polarity is in most cases also only applied to a subset of
the used lanes.
Add support for this to the adi_jesd204 and jesd204_phy for Altera modules.
This done by adding new parameter to the modules that allows to specify a
per lane polarity inversion. Each bit in the parameter corresponds to one
lane. If the bit is set the polarity is inverted for his lane. E.g. setting
the parameter to 0xc will invert the 3rd and 4th lane.
The setting is forwarded depending on whether soft or hard PCS is used to
either the soft PCS module or the transceiver block itself.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Add a parameter to the soft_pcs_loopback_tb that allows to test whether the
soft PCS modules work correctly when the lane polarity is inverted.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Some designs choose to swap the positive and negative side of the of the
JESD204 lanes. One reason for this would be because it can simplify the
PCB layout.
To support this add a parameter to the jesd204_soft_pcs_tx module that
allows to specify whether the lane polarity is inverted or not.
The way the polarity inversion is implemented is for free since it just
inverts the output mapping of the 8b10b encoder LUT tables.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Some designs choose to swap the positive and negative side of the of the
JESD204 lanes. One reason for this would be because it can simplify the
PCB layout.
To support this add a parameter to the jesd204_soft_pcs_rx module that
allows to specify whether the lane polarity is inverted or not.
The way the polarity inversion is implemented it is for free since it will
only invert the input mapping of the 8b10b decoder LUT tables.
The pattern align module does not care whether the polarity is inverted or
not since the pattern align symbols look the same in both cases.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
When the source and destination bus widths don't match a resize block is
inserted on the side of the narrower bus. This resize block can contain
partial data.
To ensure that there is no residual partial data is left in the resize
block after a transfer shutdown the resize block is reset when the DMA is
disabled.
Currently this is implemented by tying the reset signal of the resize block
to the enable signal of the DMA. This enable signal is only a indicator
though that the DMA should shutdown. For a proper shutdown outstanding
transactions still need to be completed.
The data that is in the resize block might be required to complete those
transactions. So performing the reset when the enable signal goes low can
lead to a situation where the DMA tries to complete a transaction but can't
do it because the data required to do so has been erased by resetting the
resize block. This leads to a dead lock and the system has to be rebooted
to recover from it.
To solve this use the sync_id signal to reset the resize block. The sync_id
signal will only be asserted when both the destination and source side
module have indicated that they are ready to be reset and there are no more
pending transactions.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
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.
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>
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>
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>
The DC filter implementation in library/common/dc_filter.v is Xilinx
specific as it uses the Xilinx DSP48 hard-macro. There is a matching Altera
specific implementation in library/altera/common/dc_filter.v.
Move the Xilinx specific implementation from the generic common folder to
the Xilinx specific common folder in library/xilinx/common/ since that is
where all other Xilinx specific common modules reside.
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>
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 library Makefiles for 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 library Makefiles.
This drastically reduces the size of the library 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>
In cases when a shallow FIFO is requested the synthesizer infers distributed RAM
instead of block RAMs. This can be an issue when the clocks of the FIFO are
asynchronous since a timing path is created though the LUTs which implement the
memory, resulting in timing failures. Ignoring timing through the path is not a
solution since would lead to metastability.
This does not happens with block RAMs.
The solution is to use the ad_mem (block RAM) in case of async clocks and letting
the synthesizer do it's job in case of sync clocks for optimal resource utilization.
Add a parameter to the control the clock source option of the MMCM. If
the MMCM has only one clock source the CLKSEL pin will be tied to VDD.
The previous version added a redundant path between the CLKSEL port and
register map.
This module upscale an n*sample_width data bus into a 16 or 32*n data
bus. The samples are right aligned and supports offset binary or two's
complement data format.
The up_xfer_cntrl and up_xfer_status modules have its own constraints files
in library/xilinx/common. Each IP which has an instance of these
modules, have to use these constraints files.
The following IPs were modified:
- axi_adc_decimate
- axi_adc_trigger
- axi_dac_interpolate
- axi_logic_analyzer
A couple of new parameters and new ports are missing in several
up_[adc|dac]_[common|channel] instance, and generates warnings. The rule of
thumb is to use full instantiations, defining all the existing parameter and
ports of the module.
Fix all the instantiation of up_[adc|dac]_[common|channel], by defining all its
parameters and ports.
The up_rstn is driven by s_axi_resetn, which is generated by a
Processor System Reset module. (connected to port peripheral_aresetn)
Therefor using this reset signal as an asynchronous reset is redundant,
and a bad design practice at the same time. Asynchronous reset should be
used if it's inevitable.
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 cores that handle the JESD204 ADC cores do not feature IQ correction
logic. The Q_OR_I_N parameter for the channel modules is unused, so remove
it.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The cores that handle the JESD204 ADC converters do not feature any direct
IO and subsequently no IO-delay blocks either. Remove the unused
IO_DELAY_GROUP parameter.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Bundle the TLAST signal in with the other AXIS slave signals to enable
easier connection between AXIS devices that use TLAST
Signed-off-by: Matt Fornero <matt.fornero@mathworks.com>
Add some limit TLAST support for the streaming AXI source interface. An
asserted TLAST signal marks the end of a packet and the following data beat
is the first beat for the next packet.
Currently the DMAC does not support for completing a transfer before all
requested bytes have been transferred. So the way this limited TLAST
support is implemented is by filling the remainder of the buffer with 0x00.
While the DMAC is busy filling the buffer with zeros back-pressure is
asserted on the external streaming AXI interface by keeping TREADY
de-asserted.
The end of a buffer is marked by a transfer that has the last bit set in
the FLAGS control register.
In the future we might add support for transfer completion before all
requested bytes have been transferred.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Commit ff50963c7f ("axi_ad9361- altera/xilinx reconcile- may be broken-
do not use") inverted the polarity of the TX feedback clock.
This exposed some issues in the existing drivers which can cause the
interface tuning to fail randomly under certain conditions.
To keep backwards compatibility with existing drivers restore the previous
behavior.
A separate fix will be applied to the drivers that resolves the issue that
has been exposed by the polarity inversion. So that interface calibration
works reliably under all conditions.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Assigning the value of a local parameter(localparam) to a parameter
will end up with a conflict(not highlighted by the tool). In this
case, the parameter type was defined as a string instead of an
integer. Furthermore, this scenario leads to an undesired choice
between primitive types.
The dma_last_beats is used by the Avalon Memory Mapped interface
controller, to define the last burst length.
Its value get stable after the last valid data of the DMA interface, and staying
stable until the positive edge of the DMA's xfer_req.
No need to condition the transfer of this register to avalon clock
domain.
The XFER_END state defines the end of a transaction, when the entire
data set is written or read to/from the DDRx memory.
A transaction can contain multiple Avalon bursts. Make sure that the FSM
goes back into staging phase at the end of each burst; also define a
signals which indicate the end of each burst for control.
The period_count should be updated once per clock cycle. This is not
enforced with the current implementation, which probably leads to
period_count being decremented on both m_axis_aclk edges.
A problem observed due to this is that the m_axis_tlast output is not
asserted or is asserted for a too short time for the consumer to
detect it.
Fix by letting the decrement (and thus the m_axis_tlast toggling)
happen only on the rising edge of the m_axis_aclk clock.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
The commit 6900c have added an additional register stage into the fifo read
data path, but the control signals (ready/valid/underflow) were not realigned
to the data. This can cause data lose or duplicated samples in some case.
Realign the control signals to the data.
The util_adxcvr supports GTX2, GTH3 and GTH4. The transceiver is selected
using the XCVR_TYPE parameter.
The axi_adxcvr on the other hand only has a configuration parameter to
indicate whether a GTX or GTH transceiver is used (GTH_OR_GTX_N). Since
there are some minor differences between GTH3 and GTH4 that software needs
to know about rename the GTH_OR_GTX_N to XCVR_TYPE and match use the same
semantics as util_adxcvr.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The dac_xfer_req should indicate one single thing, that the FIFO is in
read phase. Should not be affected by any signals, which indicates data
validity on any interface. (e.g. dac_valid)
This signal is not used by the device core, its main purpose is to
indicate the state of the interface for a posible intermediat processing
module.
Fix the reset of the dma_mem_waddr (write address register of the CDC
FIFO on DMA's clock domain). This solves the occasional invalid read backs after
multiple re-initialization of the PL_DDR_FIFO.
+ 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.
The first attempt (f3daf0) faild miserably. When the data_req signal
from the device had more than 1 cycle of deassert state, because of the
added latency of the data stream, the device got 'zeros' too.
In this fix, the DMA will hold the valid data on the bus, between two
consecutive data request. The bus is reseted just after all the data
were sent out.
The grey coder/decoder function was limited to 10 bits, and this
resulted an unwanted limitation of the FIFO size. Using this
module, the coder/decoder data width can be adjusted to the current
address width.
Reset the fifo_rd_data if the DMA does not have an active transfer.
Becasue all the DAC device cores are transfering the data from the FIFO
interface to the data interface without any validation signal, DMA needs to put
the data bus into a known state, to prevent the device core to send the
last known data again and again.
Add missing timing exceptions on paths between the DMA and DDR clock
domains. All these paths are properly synchronized using CDC in the HDL,
but are missing timing exceptions in the XDC file. This can lead to timing
errors when building a design using the axi_adc_fifo.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Istvan Csomortani
Lars-Peter Clausen
AndreiGrozav
Adrian Costina
Laszlo Nagy
Rejeesh Kutty
Matt Fornero
Luca Ceresoli