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>
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>
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>
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>
Always explicitly specify the signal width for constants to avoid warnings
about signal width mismatch.
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>
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>
Lars-Peter Clausen