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>
Make sure the req_gen_valid and req_gen_ready signals are 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>
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.
Increase the width of wvalid_counter, should be equal with awlen width.
The wvalid_counter needs to count from zero to the required burst
length. The maximum burst length is 255, so the width of the counter
have to be 8 bits. axi_last_beats will get the last axi burst length.
The fifo will ask for a new data from the DDR, if the current
level is lower than the high threshold. This will prevent overflow.
By deleting the lower threshold, we can avoid ocassional underflows,
when the DAC rate is closer to the max DDRx rate.
All verilog file are using the Verilog-2001 standard to define
and/or declare ports. Definin a port width with a local parameter
is a bad practive, when this standard is used. Some simulators
will crash. Try to avoid it.
Fix the dma_ready mux in top module, and the dma_ready_out reset
logic in axi_dacfifo_wr module. Also, both write and read addresses
of the async CDC fifo (inside the axi_dacfifo_wr) should be reset
before a dma transaction starts.
The mb_intrs signal is never driven, it is a leftover of an earlier version
of the file, remove it.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
If the streaming bit is set, after the trigger condition is met
data will be continuosly captured by the DMA. The streaming bit
must be set to 0 to reset triggering.
If the streaming bit is set, after the trigger condition is met,
data will be continuosly captured by the DMA. The streaming bit
must be set to 0 to reset triggering.
The DAQ3 does not use a 1-to-1 lane mapping for the DAC JESD204 link.
Provide the proper mapping when setting up the transceiver connections.
Without this the payload data will be mapped incorrectly and the
transmitted signals are scrambled.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
In non-streaming mode we want direction changes to be applied immediately.
The current code has a typo and checks the wrong signal. overwrite_data
holds the configured output value of the pin, whereas overwrite_enable
configures whether the pin is in streaming or manual mode.
For correct operation the later signal should be used to decide whether a
direction change should be applied. Otherwise the direction change will
only be applied if the output value of the pin is set to logic high.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
When using non-broadcast access to the GT DRP registers lane filtering is
done on both sides. The ready and data signals are filtered in the in the
axi_adxcvr module and the enable signal is filtered in the util_adxcvr
module. This works fine as long as both sides use the same transceiver IDs.
E.g. channel 0 of the axi_adxcvr module is connected to channel 0 of the
util_adxcvr module.
But this is not always the case. E.g. on the ADRV9371 platform there are
two RX axi_adxcvr modules (RX and RX_OS) connected to the same util_adxcvr.
The first axi_adxcvr uses lane 0 and 1 of the util_adxcvr, the second uses
lane 2 and 3.
Non-broadcast access for the first RX axi_adxcvr module works fine, but
always generates a timeout for the second axi_adxcvr module. This is
because lane 0/1 of the axi_adxcvr module is connected to lane 2/3 of the
util_adxcvr and when ID based filtering is done both can't match at the
same time.
To avoid this perform the filtering for all the signals in the axi_adxcvr
module. This makes sure that the same base ID is used.
This also removes the sel signal from the transceiver interfaces since it
is no longer used on the util_adxcvr side.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Lars-Peter Clausen
Istvan Csomortani
Adrian Costina
AndreiGrozav
Rejeesh Kutty