The width of the parameter `device_cfg_octets_per_multiframe` doesn't match the width in the submodules and corresponding slave module jesd204_tx, resulting in a warning generated during validation in Vivado. This patch increases the width of this parameter in axi_jesd204_tx.
This module creates sync header alignment described in section 7.6.1 of
the JESD 204C specification.
The alignment relies on the bitslip capability of the connected
transceiver.
Create a common 'run_tb.sh' script to be called by every testbench.
Unify file and testbenches names.
Fix util_pack/cpack_tb.
Add parameters '-batch' and '-gui' for modelsim and xsim simulators (default is gui)
Add ascript for that generates output in xml format (used by CI tools).
get_cell on i_lmfc/cdc_sync_stage1_reg doesn't return anything because design was updated.
This generates a CRITICAL WARNING and since the constraint it not necessary anymore, it can be deleted.
Dual clock mode is introduced in link layer to support different
datapath widths on the transport layer than on physical layer.
- Link clock : lane rate / 40 for input datapath width of 4 octets 8b10b
- Device clock : Link clock * input data path width / output datapath width
Supports four clock configurations, single or dual clock mode with or
without external device clock.
The configuration interface reflects the dual clock domain.
Add parameter that describes interface to link layer, this must be
integer multiple of octets per frame.
Add parameter that describes interface to user/DMA, this must be
multiple of bytes so software can process the samples easier.
Make synthesis parameters accessible for the drivers.
Rework implementation to reflect the parameters of the actual core and
not of the AXI interfacing core.
To support deterministic latency with non-power of two octets per frame
(F=3,6) the interface width towards the transport layer must be resized
to match integer multiple of frames.
e.g Input datapath width = 4; Output datpath width = 6;
for F=3 one beat contains 2 frames
for F=6 one beat contains 1 frame
The width change is realized with a gearbox.
Due the interface width change the single clock domain core is split
in two clock domains.
- Link clock : lane rate / 40 for input datapath width of 4 octets 8b10b
- lane rate / 20 for input datapath width of 8 octets 8b10b
- lane rate / 66 for input datapath width of 8 octets 64b66b
- Device clock : Link clock * input data path width / output datapath width
Interface to transport layer and SYSREF handling is moved to device clock domain.
The configuration interface reflects the dual clock domain.
If Input and Output datapath width matches, the gearbox is no longer
required, a single clock can be connected to both clocks.
In order to keep resource utilization low and for better timing closure
allow disabling of the character replacement logic.
If the parameter is set the frame alignment monitoring is limited to links
where scrambling is on.
Add support to JESD204 RX and TX core for 8-byte 8b/10b link mode,
and frame alignment character replace/insert with or without scrambling.
Add support for xcelium simulator to jesd204/tb
Increased cores minor version.
Allow channels received from dma to re-map to other channels, e.g. allowing
broadcasting the same channel to all channels.
The feature is selectable with synthesis parameter and disabled by default.
When the link is disabled the events can be ignored.
This is required by the free running event counter that can catch
invalid events during startup cased for example by an invalid link clock.
If the lane looses synchronization due invalid characters or disparity
error the lane alignment monitor checks random input which results in
irrelevant reporting of frame alignment error.
If all lanes are synchronized (CGS state machine is in DATA phase) for long
enough therefore the link is also synchronized/DATA phase reset the error
counter since the accumulated values during INIT/CHECK are irrelevant.
These errors are handled by the per-lane CGS state machine.
All errors accumulated during INIT/CHECK phase of CGS are relevant only
if the link is unable to reach the DATA phase.
The link stays in DATA phase unless software resets it,
so all errors accumulated during the DATA phase are relevant.
The previous implementation of the de-glitch only delayed the assertion
of the SYNC phase by 64 clock cycles with the DEGLITCH state but if meanwhile
one of the lanes got into a bad state cgs_ready de-asserted the state machine
continued to go SYNCHRONIZED (DATA) state.
This change extends the required number of consecutive cycles while all lanes
must stay in data phase before moving the link to SYNCHRONIZED state from 8 to 256;
This increases the reliability of link bring-up without needing extra
link restarts from software side.
Adrian Costina
Robin Getz
Laszlo Nagy
Isaac T
Istvan Csomortani
Iacob_Liviu
Alin-Tudor Sferle
stefan.raus
Matt Blanton
Josh Blum