[USRP-users] Description of Timestamp & I/Q samples out of the radio & CHDR
ianb at ionconcepts.com
Wed Dec 10 13:39:32 EST 2014
Try referring to this document for now, its written from an IC design perspective.
On Dec 10, 2014, at 6:06 AM, seb fenn via USRP-users <usrp-users at lists.ettus.com> wrote:
> Many thanks for your answers.
> When you refer to 'The Manual' are you referring to this:
> The point I was trying to make that I am attempting to add custom logic into the FPGA fabric itself. To successfully do this, I need to know EXACTLY the format of data returned over the AXI bus (CHDR data). Looking at software APIs doesn't tell me how this data is structured on the AXI streaming bus, or what it means. For example I need to know which entry in the packet the timestamp is so I can trap it in my logic (I think it is the second word BTW).
> Unless I am completely missing some source of information, it feels as though all I can do is simulate the radio in a VHDL/Verilog testbench, assuming I can work out how to configure it in my testbench. (Or try to work it out from the Verilog).
> BTW I have just come across this:
> Which explains the CHDR format in more detail than I have previously seen.
> Many thanks
>> Hey Sebastian,
>> thanks for checking out RFNoC. I have answers inline.
>> On 12/10/2014 11:22 AM, seb fenn via USRP-users wrote:
>>> Can someone please refer me to some accurate documentation, or
>>> describe, the structure of (CHDR) data coming out of the radio and
>>> into the RFNoC network. In particular:
>> CHDR is described in the manual. You'll need to use your local build of
>> the UHD manual when working with RFNoC.
>>> a) What is the format of the timestamp
>> It counts ticks.
>>> b) Where is the timestamp is the packet
>> See the manual. Also, I recommend the CHDR dissectors for wireshark.
>>> c) How the I and Q samples are arranged in the 64 bit words d) Size
>>> and coding of the I/Q samples (e.g. 16 bit signed?)
>> CHDR does by itself not define the data type; the assumption is that the
>> the block knows what to do with the data.
>> For our typical operations, we use 16-bit signed (as indicated by the
>> "sc16" data description).
>>> e) What is a trailer (as indicated by bit 62 in the header)
>> CHDR does not have a trailer. Bit 62 is part of the packet type (see the
>>> I am coding up blocks to include in the FPGA fabric, not writing
>> Until we've finished all of our RFNoC goals, you'll probably need to do
>> both -- although for starters, adding an XML stub in
>> uhd/usrp/rfnoc/blocks/ will probably do.
>>> And is there more information on CHDR? I have gleaned some from
>>> simulations and the paper "Simplifying FPGA Design with a Novel
>>> Network on Chip Architecture". But could do with some more complete
>>> descriptions. For example I don't understand why the Packet Size
>>> field in Context Packets in various testbenches (e.g. noc_shell_tb.v)
>>> is set to 16. And there seems to be a three word acknowledgment of a
>>> write to the NoC Shell address space. What is the meaning of the data
>>> in these words, I have guessed some of it , but would like
>> 'context package' is actually a VITA-49 term. It still means the same
>> here, although in CHDR, we can know name all the packet types specifically.
>>> I have seen
>>> https://github.com/EttusResearch/uhd/wiki/RFNoC:--Specification , but
>>> more information would be welcomed. For example is there any guidance
>>> on the usage of the "Upstream Flow Control: Cycles per ACK" and
>>> "Downstream Flow Control: Buffer size" registers? Some of this
>>> information seems inaccurate, for example the " Upstream Flow
>>> Control: Packets per ACK" register seems to be tied low.
>>> Thanks in advance. The RFNoC approach seems a great innovation but
>>> working out how to add my own logic is proving something of a slog at
>>> the moment and I'd welcome more documentation.
>> At this time, all we can offer is the entirety of our sources. Also, the
>> C++ API documentation is fairly complete, and also answers some of your
>> questions on nomenclature.
>> I guess what you really want is a step-by-step tutorial, and I agree it
>> would be nice to have all that. But doing that is would be a waste of
>> everyone's time until all APIs etc. have been finalized -- also, it
>> would slow down the active development, which is still going on at full
>> pace, be assured!
> This message is intended for the use only of the person(s) (‘Intended Recipient’) to whom it is addressed. It may contain information that is privileged and confidential. Accordingly any dissemination, distribution, copying or other use of this message or any of its content by any person other than the Intended Recipient may constitute a breach of civil or criminal law and is strictly prohibited. If you are not the Intended Recipient, please contact the sender as soon as possible.
> TRL Technology Limited is a private company registered in England with the company number 1705039 whose registered office is at Sigma Close, Shannon Way, Tewkesbury GLOS. GL20 8ND, UK.
> USRP-users mailing list
> USRP-users at lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users