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.
Lars-Peter Clausen
Adrian Costina
Istvan Csomortani
Laszlo Nagy
Rejeesh Kutty
AndreiGrozav
Matt Fornero
Luca Ceresoli