-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Timestamp featue #1010
Comments
Hi, some comments from my side
There is an issue with cpack when multiple samples are packed inside one beat (as you mentioned above). I have done some experiments in my private repo, where I extended cpack und upack to have two additional inputs.
I (temporarily) removed the abort feature from the axi_dmac so that I could implement the new stuff. The new stuff could be merged back into axi_dmac with abort feature. The main obstacle for me was that there are no testbenches for the abort feature while it adds a lot of complexity at the same time. I did not look at the new AXI_TDD or high speed JESD204 stuff yet. Will do that soon. |
I looked at the AD9361 and ADRV9002 data sheet. Both ICs only have 1 base band PLL. In that case the clock for all axi_dmac cores should have the same frequency, so they can be synchronized with a common reset signal. I dont know if there are any 2RX-2TX ICs that allow different sample rates at the same time. It was not so clear in the ADRV9008, ADRV9026, AD9988 data sheets (but I only looked briefly). |
Then you need to look closer. ADRV9002 can have unique (ish) rates for DACs and ADCs. Datasheet says:
While they have the same baseband PLL - the dividers can be unique. The same is true on the AD9081 - most times the ADC/DAC samples rates do not match. However - when they don't match - they all have their own sample clocks, and typically - their own DMAs... Timestamping is sort of the only want to keep things sync'ed. |
In that case it might be necessary to have a sync mechanism for the different timestamp counters inside the tx and rx axi_dmac. If after reset, the baseband PLL dividers are set up not at the same time, the rx and tx timestamp counter will have different values even when the final sample rate for tx and rx is the same. For my purpose (digital communication) it is not a problem if the rx and tx counters have different values, because I only need relative timing. Anyway I think it will be pretty easy to synchronize the timestamp counters, so not much to worry about now. |
This show outputs from my testbenches for cpack-axi_dmac combinations.
|
@acostina I would also put the timestamp trigger logic for TX inside the axi_dmac, because the axi_dmac should give some status about the transfer in the dma response. It would be difficult to pass for example "time passed" from a tdd core back to the axi_dmac core. Moreover, the timestamp fits architecturally well together with the rest of the dma descriptor data. |
This is the HDL side of the discussion here: analogdevicesinc/libiio#860
There is also the possibility instead extending AXI_DMAC to support all the new features, just to create an input with timestamp which can be read at the same time with the sync start and create a separate IP responsible with all the timestamping feature to reduce the complexity of maintaining the AXI_DMAC IP.
In my opinion, the above discussion doesn't cover cases when the number of samples per beat is higher than 1 (typical case with sampling rates over 200-350MSPS). In some cases, when the bandwidth of the DDR doesn't keep up with the data bandwidth from the converters we don't even have the sampling clock as an input of the DMA. Extending the data offload IP may be needed for these use cases.
On the TX side, we could extend the AXI_TDD (#975) to trigger transfer at a specific timestamp.
The PACK IPs would also need to be improved for clean implementation of this feature, right now when we want to do synchronized transfers between FPGAs and also as part of the phaser example [https://github.com/analogdevicesinc/plutosdr-fw/tree/pluto_phaser] we keep them in reset before the transfer which is not ideal.
The text was updated successfully, but these errors were encountered: