Add a interface definition for the link interface that combines the valid,
ready and data signals into a AXI streaming interface.
This allows to connect the interface to the JESD204 link layer peripheral
in one go without having to manually connect each signal.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Some modes produce only one sample per channel per beat, e.g. when M=2*L.
In this case the pattern output needs to alternate between the two patterns
from beat to beat.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
All channels have a copy of the same logic to generate the PN sequences.
Sharing the PN sequence generator among all channels slightly reduces the
resource utilization of the core.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Only the N (where N is the size of the PN sequence) MSB bits of the reset
state of the PN generator should be set to 1. All other bits should be
initialized following the PN generator sequence.
Otherwise the first set of samples contain an incorrect PN sequence.
This does not increase the complexity of the PN generator, all reset values
are still constant.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
All the inputs to the framer are registered. And the framer itself does not
have any combinatorial logic, it just re-orders the wire numbering of the
individual bits.
Currently the framer module adds a output register stage, but since there
is no logic in the framer this just means that these registers are directly
connected to the output of the previous register stage.
Remove the extra pipeline register. This slightly reduces utilization and
pipeline delay of the core.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Remove unused register from the ad_ip_jesd204_tpl_dac_channel module.
Commit commit 92f0e809b5 ("jesd204/ad_ip_jesd204_tpl_dac: Updates for
ad_dds phase acc wrapper") removed all users of those registers.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
All parameters are DAC related since this is a peripheral that handles
DACs. Having DAC as a prefix on some of the parameter names is a bit
redundant, so remove them.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use a relative path for all IP local files. This is the common style
throughout the HDL repository and also makes it easier to move the
directory around.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Assign a unique value to each lane's error count register and verify that
the correct value is returned for the right lane.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The RX register map testbench currently fails because the expected value
for the version register was not updated, when the version was incremented.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The loopback testbench currently fails, because the cfg_links_disable signal is not connected to the RX side of the link.
Fix this.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
In case when the SYSREF is connected to an FPGA IO which has a limitation
on the IOB register IN_FF clock line and the required ref clock is high
we can't use the IOB registers.
e.g. the max clock rate on zcu102 HP IO FF is 312MHz but ref clock is 375MHz;
If IOB is used in this case a pulse width violation is reported.
This change makes the IOB placement selectable in such case or
for targets which don't require class 1 operation.
Typically only one of the character error conditions is true at a time. And
even if multiple errors were present at the same time we'd only want to
count one error per character.
For each character track whether at least one of the monitored error
conditions is true. Then count the number of characters for which at least
one error condition occurred. And finally add that sum to the total numbers
of errors.
This results in a slightly better utilization.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
When the link is explicitly disabled through the control interface reset
the error statistics counter.
There is usually little benefit to preserving until after the link has been
disabled. If software is interested in the values it can read them before
disabling the link. Having them reset makes the behavior consistent with
all other internal state of the jesd204 RX peripheral, which is reset when
the link is disabled.
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
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.
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>
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>
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>
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.
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>
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>
Lars-Peter Clausen
Laszlo Nagy
AndreiGrozav
Adrian Costina
Istvan Csomortani