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>
The DEGLITCH state of the RX state machine is a workaround for misbehaving
PHYs. It is an internal state and an implementation detail and it does not
really make sense to report through the status interface.
Rework things so that DEGLITCH state is reported as part of the CGS state
on the external status interface.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Add soft logic PCS that performs 8b10b encoding for TX and character
pattern alignment and 8b10b decoding for RX.
The modules are intended to be used in combination with a transceiver that
does not have these features implemented in hard logic PCS.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Add Qsys IP scripts as well as SDC constraint files for the ADI JESD204
peripherals. This allows them to be instantiated and used on Altera/Intel
platforms.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The Xilinx tools are quite forgiving when it comes to required signals on
standard interfaces, which is why it was possible to define a AXI streaming
interface without the required valid signal.
The Altera tools are more strict and wont allow this. Add a dummy valid
signal to the TX data interface to make the tools happy. For now the signal
does not do anything, in the future it might be used to detect an underflow
condition on the data interface and report this through the status
interface.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Currently the ILAS memory for the receive register map uses a shift
register with variable tap output for storing the ILAS information. This
maps very efficiently onto the primitives found in Xilinx FPGAs. But there
is no equivalent primitive in Altera FPAGs resulting in increased
utilization from having to implement the structure in pure logic.
Change the ILAS memory so it uses a simple dual port RAM for storing the
data. This has slightly increased utilization on Xilinx platforms (but
still good enough) and highly decreased utilization on Altera platforms.
One side effect of this change is that since the RAM output is synchronous
reading the ILAS memory registers will take one extra clock cycle.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Currently the reset for the link clock domain is generated internally in
the axi_jesd204_{rx,tx} peripheral. The reset is controlled by through the
register map.
Add an additional external reset for link clock domain. The link clock
domain is kept in reset if either the internal reset or the external reset
is asserted.
This for example allows the fabric to keep the domain in reset if the clock
is not yet stable.
The status of the external reset can be queried from the register map.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Name all CDC blocks following the patter i_cdc_${signal_name}. This makes
it clear what is going on.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the CDC sync_bits helper to synchronize the asynchronous external SYNC~
signal into the link clock domain, rather than open-coding this operation.
This makes it more explicit what is going on.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Which events will be exposed as IRQs and at what level of granularity will
need some additional through. Remove the two existing IRQ events for now
again. This will be added back later.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The up_cfg_ilas_data signal is a two dimensional array. There are 4
register entries for each lane. Model it as such rather than compressing it
down to a one dimensional array. This makes accessing the individual
entries a bit more straight forward and the code clearer.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The ilas_cfg_static.v is part of the jesd204_tx_static_config module.
Somehow a copy of that file made it into the jesd204_tx module where it is
completely unused. Remove the duplicated file.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Add a check to RX register map to confirm that the ILAS memory registers
return the correct values after the ILAS data has been received.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
This partially reverts commit a8ade15173.
Remove the nonsensical Makefile dependencies that got added by accident.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The generic Altera clock monitor constraints expect the instance to be
called i_clock_mon. Adjust the code accordingly.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
In this particular case the behaviour is the same with non-blocking and
blocking assignments, but that could change if the code is modified in the
future. To avoid any potentially issue due to this consistently use
non-blocking assignments.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The SYNC signal that gets reported through the status interface should be
the output (second stage) of the synchronizer circuit.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Make sure the core_cfg_transfer_en signal is declared before they are used.
Strictly speaking the current code is correct and synthesis correctly, but
declaring the signals make the intentions of the code more explicit.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Be more standard compliant and assign names to generate for-blocks. This is
required for Altera/Intel support.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
In some cases, the 'core_ilas_config_data' registers will be infered as
FDRE, instead of FDSE. Therefor a max delay definition, which are using
the S pin as its endpoint, it can become invalid, nonexistent.
Generalize the path, using the register itself as endpoint.
Always explicitly specify the signal width for constants to avoid warnings
about signal width mismatch.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The buffer delay should be 0 in the default configuration. The current
value of 0xb must have slipped in by accident.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use a single standalone counter that counts the number of beats since the
release of the SYNC~ signal, rather than re-using the LMFC counter plus a
dedicated multi-frame counter.
This is slightly simpler in terms of logic and also easier for software to
interpret the data.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
There are currently two sysref related events. One the sysref captured
event which is generated when an external sysref edge has been observed.
The other is the sysref alignment error event which is generated when a
sysref edge is observed that has a different alignment from previously
observed sysref edges.
Capture those events in the register map. This is useful for error
diagnostic. The events are sticky and write-1-to-clear.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The internal LMFC offset signals are in beats, whereas the register map is
in octets. Add the proper alignment padding to the register map to
translate between the two.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
For SYSREF handling there are now three possible modes.
1) Disabled. In this mode the LMFC is generated internally and all external
SYSREF edges are ignored. This mode should be used for subclass 0 when no
external sysref is available.
2) Continuous SYSREF. An external SYSREF signal is required and the LMFC is
aligned to the SYSREF signal. The SYSREF signal is continuously monitored
and if a edge unaligned to the previous edges is detected the LMFC is
re-aligned to the new edge.
3) Oneshot SYSREF. Oneshot SYSREF mode is similar to continuous SYSREF mode
except only the first edge is captured and all further edges are ignored,
re-alignment will not happen.
Both in continuous and oneshot signal at least one external sysref edge is
required before an LMFC is generated. All events that require an LMFC will
be delayed until a SYSREF edge has been captured. This is done to avoid
accidental re-alignment.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The ADI JESD204 link layer cores are a implementation of the JESD204 link
layer. They are responsible for handling the control signals (like SYNC and
SYSREF) and controlling the link state machine as well as performing
per-lane (de-)scrambling and character replacement.
Architecturally the cores are separated into two components.
1) Protocol processing cores (jesd204_rx, jesd204_tx). These cores take
care of the JESD204 protocol handling. They have configuration and status
ports that allows to configure their behaviour and monitor the current
state. The processing cores run entirely in the lane_rate/40 clock domain.
They have a upstream and a downstream port that accept and generate raw PHY
level data and transport level payload data (which is which depends on the
direction of the core).
2) Configuration interface cores (axi_jesd204_rx, axi_jesd204_tx). The
configuration interface cores provide a register map interface that allow
access to the to the configuration and status interfaces of the processing
cores. The configuration cores are responsible for implementing the clock
domain crossing between the lane_rate/40 and register map clock domain.
These new cores are compatible to all ADI converter products using the
JESD204 interface.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Istvan Csomortani
Lars-Peter Clausen
Adrian Costina
Rejeesh Kutty