The first attempt (f3daf0) faild miserably. When the data_req signal
from the device had more than 1 cycle of deassert state, because of the
added latency of the data stream, the device got 'zeros' too.
In this fix, the DMA will hold the valid data on the bus, between two
consecutive data request. The bus is reseted just after all the data
were sent out.
The grey coder/decoder function was limited to 10 bits, and this
resulted an unwanted limitation of the FIFO size. Using this
module, the coder/decoder data width can be adjusted to the current
address width.
Reset the fifo_rd_data if the DMA does not have an active transfer.
Becasue all the DAC device cores are transfering the data from the FIFO
interface to the data interface without any validation signal, DMA needs to put
the data bus into a known state, to prevent the device core to send the
last known data again and again.
Add missing timing exceptions on paths between the DMA and DDR clock
domains. All these paths are properly synchronized using CDC in the HDL,
but are missing timing exceptions in the XDC file. This can lead to timing
errors when building a design using the axi_adc_fifo.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Export the reset signal for the link clock domain. This can be used by
external logic that is in the link clock domain to reset itself.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Enabling the phase alignment mode of the FPLL seems to break manual
re-calibration, which is required when changing the lane rates. The
calibration seems to select the wrong VCO frequency band and the PLL no
longer locks.
Disable phase alignment mode for now, this has a negative effects on
deterministic latency, but it is better than not working at all.
Waiting for feedback from Altera/Intel on how to make manual re-calibration
work in phase alignment mode.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
To be able to check the FPLL re-configuration arbitration status from
software enable the avmm_busy flag in the register map.
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>
Adrian Costina
Istvan Csomortani
AndreiGrozav
STEVE KRAVATSKY
Lars-Peter Clausen
Rejeesh Kutty