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.
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.
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.
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>
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>
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>
Laszlo Nagy
Istvan Csomortani
Lars-Peter Clausen
Rejeesh Kutty