I am looking at the feasibility of an OpenCPI application where sync between transmit and receive is deterministic. I have developed something similar using the UHD/RFNoC framework; where time_spec is given to a Tx stream, and then gating applied at the radio block against the master clock.
In OpenCPI - clearly the csts interface is designed to allow a similar timestamp to be streamed; but on the Tx side of the radio I was struggling to see whether anything gates this on the DRC by default. I couldn’t see an obvious TimeInterface in the likes of the AD9361 device workers… have I missed where this is done, or is it only accomplished by adding in something like the timegate_csts component, prior to entry into the DRC Tx Chain? If so, is some clock cycle determinism possibly lost due to the multiple FIFOs along this chain?
The digital radio controller (DRC) is an abstraction layer for control of radio functions. It’s essentially a proxy worker to control the radio functions both RCC and HDL.
You are right the CSTS is designed to handle this use case. The DRC has a property that enables and disables timestamping components that will instantiate control of these devices.
But yes in either case you will add the timegate_csts component. This device is in the control clock domain, you needed in the DAC clock domain you have to implement similar functionality but using the split clock domain feature of OpenCPI to maintain clock domain in the worker.
Thanks Aaron! We’ve gone down the route of using timegate and timestamp_inserter from the SDR library, prior to the hdl workers which are called out by the DRC. I do note that these look like they’ve got some changes incoming on the develop branch (e.g. further parameters).
This won’t get us full determinism I originally mentioned, but it may be close enough for certain applications we’re interested in, where the Tx/Rx is pulsed and hence FIFOs are typically empty and should be the same latency to traverse…
Was unsure if putting any gating/stamping further down the chain (i.e. closer to DAC/ADC workers) would break the expectations of the DRC for connectivity, and haven’t tried this yet.
It would eventually make for a nice example to see how time sync could be maintained in the DAC/ADC clock domains though, such that a coherent phase could be maintained for say radar or VNA-style applications! Will read up on how the split clock domain feature might enable this.
An example of a worker maintaining clock the ADC domains can be found in projects/assets/components/util_comps/ there’s a worker called timestamper_scdcd_csts.hdl . A modified version of the timegate_csts worker will need to be created to support the DAC side. scdcd stands for split clock and data clock domains.
We are considering developing a simple application for the examples project that uses both the timestamper and timegate components. This application would demonstrate a TDMA application. So far we are thinking of creating a simple two time slot configuration that would use two radios that can transmit receive on the same frequency. Would that be helpful? Open to suggestions, but trying to keep it simple as possible.
Thanks - we’ll have a look at the split worker. I think a simple application like you mention would be very useful as an example.
For the moment we’re planning to test a non split-clock version of a simple pulsed tx / rx timegated/stamped scheme, where we can then test the alignment achievable between Tx & Rx on a single radio using a pulsed signal generator.