This commit reverts part of the changes done in the following commit:
- ff50963c7f -
"axi_ad9361- altera/xilinx reconcile- may be broken- do not use"
The above mentioned commit introduced latency variations on the Rx path
at different sample rates, or within the same sample rate after sample
rate changes. The variation is caused by multiple positions of the frame
detection combined with a free running toggle (rx_valid) that is not synchronized
with the actual samples.
Having a single frame detection position eliminates the latency
variation.
When having multiple 936x in parallel, this change enables the use of source
synchronous received clock from the master as sampling clock for other slaves.
This will eliminate skew between the interfaces since the data delays
are going to be tuned against the master clock after a multi-chip
synchronization (MCS) is done. This eliminates the clock crossing from
the slave to master domain inside the FPGA.
Sync the two valid signals to keep a fixed phase relationship between
the Rx ant Tx channels, this way avoiding +/- 1 sample differences
on the Tx-Rx latency between consecutive transfers.
The pulse period had a fixed value. Therefore, in order to be able
to configure it from the software, a 32b register pulse_period_reg
was added in axi_spi_engine. Also, to generate the pulse, the
output register pulse_gen_loadc was added.
Cleanup placement constraints and let the tool have more freedom to
place and route the design. This is possible only after balancing the
memory and system clocks.
Minimize skew on synchronous CDC timing paths between clocks originating
from the same MMCM source. (sys_mem_clk and sys_cpu_clk)
This is required mostly by the smart interconnect.
The CLOCK_DELAY_GROUP property must be applied directly to the output net of BUFGs.
- Add parameter for input data delay time to easily match the one of the
adc_trigger.
- Change the trigger delay path to match between the internal and
external(adc_trigger delays).
"prepare_incremental_compile" is defined as a phony target, but is also a
prerequisite of a real target. This will lead to a complete project build
every time make is called.
To fix the issue the functionality of prepare_incremental_compile target
was included in the generic project build target.
The ready signal of the SYNC interface should be always 1'b1,
regardless of ASYNC_SPI_VALUE.
Drive the ready with one in both branches of the ASYNC_SPI_CLK
generate block.
Currently trigger out pin is hold for 1ms in the next translation(t+1)
state(0 or 1). But not in the state that follows (t+2). This commit
fixes this issue and simplifies the logic.
The previous channel sync mechanism was simply holding the transmission by
pulling down the dma_rd_en of the two DMAs for each channel(set reg 0x50). After a
period of time (that will take the two DMAs to have the data ready to move)
the dma_rd_en was set for both channels, resulting in a synchronized start.
This mechanism is valid when the two channels are streaming the same
type of data (constant, waveform, buffer or math) at close frequencies.
Streaming 10MHz on a channel and 100KHz on the second one will result
in different interpolation factors being used for the two channels.
The interpolation counter runs only when the dma_transfer_suspended(reg 0x50)
is cleared. Because of this, different delays are added by the interpolation
counter one DMA with continuous dma_rd_en will have data earlier than the
one with dma_rd_en controlled by the interpolation counter. Furthermore,
because the interpolation counter value is not reset at each
dma_transfer_suspended, the phase shift between the 2 channels will
differ at each start of transmission.
To make the transfer start synced immune to the above irregularities a
sync_transfer_start register was added (bit 1 of the 0x50 reg).
When this bit is set and the bit 0(dma_transfer_suspended) is toggled,
the interpolation counters are reset. Each channel enables it's DMA until
valid data is received, then it waits for the adjacent channel to get valid data.
This mechanism will be simplified in a future update by using a streaming
interface between the axi_dac_interpolate and the DMAs that does not require
the probing of the DMA.
The decimation module controls the valid signal. The whole triggering mechanism
is active only when the valid signal is active.
In the case of low sampling rates, the valid signal is active once every
n clock cycles. If an external trigger condition is fulfilled and the data valid
signal is low at the time, that trigger will be ignored by the DMA.
To solve this issue, the trigger is held high until the valid is asserted.
And it stays high for at least one clock cycle.
The trigger signal that goes to the DMA(fifo_wr_sync) does not pass through
the variable fifo, for this reason, a 3 clock cycles delay is required, to
keep in sync the data with the trigger.
On the other hand, to be able to cascade the axi_logic_analyzer with
axi_adc_trigger, there should be small delays on the trigger path, for this
reason the trigger_out_adc was created.
Remove the extra delays on the trigger_i(external trigger pins).
- Add embedded trigger as an option. The use of the embedded trigger as an
option in the data stream is done for further processing, keeping the data
synchronized with the trigger.
When instrument (module) trigger is desired (logic_analyzer - adc_trigger),
a small propagation time is required, hence the need to remove the
util_extract(trigger extract) module from the data path.
- Add more options for the IO triggering. This will open the door for multiple
M2k synchronization(triggering).
trigger_o mux:
1 - trigger flag (from regmap)
2 - external pin trigger (Ti)
3 - external pin trigger (To)
4 - internal adc trigger
5 - logic analyzer trigger
The signal passed to trigger_o must not be delayed, but the new value has to be
kept for a short period, 1ms (100000 clock cycles), to reduce switch noises in
the system.
The axi_adc_trigger handles 3 output triggers:
- trigger_o - external trigger (1 clock cycle delay)
- trigger_out - signals on dmac/fifo_wr_sync the start of a new transfer.
A variable fifo depth is present in the data path, which delays the data
arriving at the DMA with 3 clock cycles. By coincidence, the external trigger
is synchronized and detected on 3 clock cycles. To get a maximum optimization
the trigger_out will be delayed with 3 clock cycles for internal triggers and
directly forwarded in the case of an external trigger.
- trigger_out_la (cascade trigger for logic_analyzer - m2k example)
Because the trigger_out_la must have a small delay, to get a realible
instrument triggering mechanism, a 1 delay clock cycle must be added on the
trigger paths, to avoid creating a closed combinatorial loop.
Increase pcore version. The major version 3 is used to describe the instrument
trigger updates.