When using a non-maximum sampling rate the data is captured earlier by two
samples.
After the initial trigger jitter fix, a low latency/utilization was
desired(one sample delay for the trigger detection). After adding the
instrument trigger an equal latency between ADC and LA was required, hence the
need for a two sample delay on the trigger path. The delay was implemented
as two clock cycle delays not two sample delays.
This commit fixes this issue and offers a more robust design.
A trigger jitter was added by fix on the external trigger input. It
manifests at input sampling frequencies lower than the maximum frequency.
Added the required reset and CE(valid) signal to the last output
stages of the trigger to obtain the desired functionality for all
sampling rates.
The extra delay was added on the trigger and data paths to compensate
for the logic analyzer changes.
The extra delay will be also seen on the m2k daisy chain. The
delay between devices will be increased from 3 to 4 samples delay.
Fix external trigger for low sampling rates.
Because the external trigger can be a short pulse at high decimation rates
there is a high chance that the pulse will be missed.
xsim does not like if a register or wire is used before their
definition. Make sure the every register and wire is defined before it's
used the first time.
In Subclass 1 mode, we need to use a separate clock (device clock) to
drive the link and transport layer of the interface. Implement the
required infrastructure for this scenario.
The clock domain crossing will be done in by the TX|RX_FIFO in the PCS.
In Subclass 1 mode an external device clock (core clock) is used,
instead of the PCS output clock, to drive the link and transport layer.
Define an additional parameter, which can be used to enable clock input
port for the PHY module, which can be used as rx|tx_coreclkin source.
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.
- 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).
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.