Koen OK a few low level H/W and CHDR hints to help you along: “Time” when we talk about the H/W and how it’s implemented is a 64bit value that counts in units of 1/master_clock_rate which for X310 is generally 5nS.
The reference for time is a 64bit counter that’s driven from a block called “timekeeper.v” and you will see this time value passed around X310 generally called “vita_time”. This counter can be set/reset via UHD API calls such as “set_time”now/set_time_next_pps/set_time_unknown_pps” CHDR packets can optionally contain a 64bit time value as part of the header, and a bit in the header indicates if the time field is present. When this field is present it represents an absolute time value for the first sample in the packet. In general you will see time present in most CHDR packets, for example the radio tags all RX samples with the time. From a transmit perspective, there is a stateful concept of “bursts”, that is the radio can either be idle or actively transmitting. After startup the TX Radio is in an idle state, and host software will generally use API calls to adjust the absolute “vita_time” to closely track host time-of-day or exactly track GPS time if it is available. When a sample packet arrives at the radio with a time field inside, the radio compares this time value with the current “vita_time” and providing that the packets time value is still in the “future” will start buffering arriving sample packet data in order until the time field of that first packet matches the “vita_time” as it advances. At this point the state of the radio becomes active, and it will start streaming de-packetized data into the DUC stages and hence out into the analog transmitter. To leave the active state, ceasing transmission, and return to the idle state, a bit in a CHDR packet header signals end-of-burst (EOB) and the last sample in this packet shall represent a transition of radio state back to idle. From the user application perspective then you need to annotate a time value into your initial CHDR packet to the radio that is still “in the future” and has a time delta from the current vita_time such that allowance is made for that packet to arrive at the radio in a timely fashion. From then on your application will need to generate CHDR packets at a rate that matches or exceeds the sample rate. When you are done transmitting the last packet you generate will have the EOB bit set. A lot of this functionality is presumably already provided in the noc_shell to abstract you from the details, someone else who is RFNoC conversant will need to comment on that mechanism though. -Ian > On Jun 12, 2018, at 11:56 PM, TIMMEN Koen <koen.tim...@thalesaleniaspace.com> > wrote: > > Hello again, > > Thank you for answering my question. I do still have a few questions though. > > What do the timestamps in each packet serve for exactly? Are you talking > about the CHDR packets here? I saw that in the CHDR format ‘fractional time’ > was optional, but did not understand how to activate this option. I assumed > it would be handled internally in the AXI wrapper and NoC shell. But as I > understand now, one has to write his own code that adds this part of the > payload? > > My original plan was based on what you suggest as well, to make the time > available in a register and upon reaching some future start time, my block > will transmit the corresponding sample. However, this does not answer the > question of where to find the value to store inside the register and update > it as time actually progresses. Is it as simple as coding a counter and > counting the number of passed clock cycles? > > Sorry if I seem to ask for the obvious, it’s all still relatively new to me. > > Kind regards, > > Koen > > > > De : Michael West [mailto:michael.w...@ettus.com > <mailto:michael.w...@ettus.com>] > Envoyé : lundi 11 juin 2018 23:59 > À : TIMMEN Koen > Cc : Neel Pandeya; Ian Buckley (i...@ionconcepts.com > <mailto:i...@ionconcepts.com>); usrp-users@lists.ettus.com > <mailto:usrp-users@lists.ettus.com> > Objet : Re: [USRP-users] vita time > > Hi Koen, > > The way to achieve what you want is to set the device time and then have your > signal generator put timestamps in each packet relative to that time. To > tell your custom block what time to use, you can have a user register that > you also program with the time (or some future start time). > > Regards, > Michael > > On Wed, Jun 6, 2018 at 11:24 PM, TIMMEN Koen via USRP-users > <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: > Hello, > > My block is a signal generator and each sample needs to be transmitted at an > accurately known instant. The samples themselves do not need to hold this > information. > > The device I am using is the X310. > > What Neel Pandeya is suggesting sounds like exactly what I’m trying to do. > > Thank you for your responses. > > Regards, > > Koen Timmen > > > De : Neel Pandeya [mailto:neel.pand...@ettus.com > <mailto:to%3aneel.pand...@ettus.com>] > Envoyé : jeudi 7 juin 2018 06:14 > À : TIMMEN Koen > Cc : usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com> > Objet : Re: [USRP-users] vita time > > Hello Koen: > > As Ian requested, could you please provide additional detail on exactly what > you're trying to do? > > Are you merely trying to access the 64-bit FPGA VITA time from within the > RFNoC block? > > Which device are you using? > > --Neel Pandeya > > > > > On 5 June 2018 at 09:24, Ian Buckley via USRP-users > <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: > Koen, > Can you expand a little on the functionality you need pls, its not fully > clear enough to me to make a suggestion. > Are you trying to extract time from incoming samples or apply time to samples > you are processing? > -Ian > > > On Jun 5, 2018, at 7:36 AM, TIMMEN Koen via USRP-users > <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: > > Hello all, > > Currently I’m working on a RFNoC block that requires a known time reference, > but I have trouble making this value available. Ideally I would like to have > the value available in a register designated to the block. > > As I understand, a time reference is available through the CHDR, but.. not > all the time? It is optional I read in the manual. Is this a toggle that can > be set by the user? > > Or is there another way that I am able to obtain the device time reference > available in a user register? > > Kind regards, > > Koen > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com> > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com> > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
