Koen, Sorry, yes, you are correct, DUC is now implemented as an RFNoC block itself in current UHD versions.
And no, there is no architectural reason that time needs to originate in the host, you can create those packets in the USRP, but I’m not the best person to give you a style guide on how to do that in RFNoC. Perhaps the RFNoC siggen block will be a good model for you to follow as a tutorial? -Ian > On Jun 17, 2018, at 9:55 AM, Ian Buckley <i...@ionconcepts.com> wrote: > > Koen, > Sorry, yes, you are correct, recent >> On Jun 15, 2018, at 1:06 AM, TIMMEN Koen <koen.tim...@thalesaleniaspace.com >> <mailto:koen.tim...@thalesaleniaspace.com>> wrote: >> >> Ian, >> >> Thank you for the clear explanation. >> >> Luckily for me, I will not have to deal with bursts as I simple transmit I/Q >> samples that fit into a single sample. By the way, they are generated >> internally to the FPGA on a custom module. >> >> What you said about the radio is useful, however it raises a new question: >> you said that the Radio block streams to the DUC stages.. but, as I >> understand it you will need a separate DUC block for that correct? And >> normally you place that block before a Radio Tx block? So then the order of >> blocks will be Source à DUC à Radio. Or am I way off now? >> >> And you said that when I want a packet to contain a time value in the CHDR, >> I will have to enable this on the host? I assume it should also be able to >> let a custom rfnoc block do this internally to the USRP. In that way, I can >> generate a sample and give it a time stamp I want it to be transmitted on >> and then offload to the radio, which will handle timely transmission. >> >> Thank you for your patience. >> >> >> Kind regards, >> >> Koen >> >> >> >> De : Ian Buckley [mailto:i...@ionconcepts.com <mailto:i...@ionconcepts.com>] >> Envoyé : mercredi 13 juin 2018 20:18 >> À : TIMMEN Koen >> Cc : Michael West; Neel Pandeya; usrp-users@lists.ettus.com >> <mailto:usrp-users@lists.ettus.com> >> Objet : Re: [USRP-users] vita time >> >> 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 >> <mailto: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
