I would leave everything as-is in the USRP *except* for the logic the describes the phase accumulator to the DDS (CORDIC). I would replace this logic with logic that generates the desired Chirp response using the CORDIC.
Are you referring to b200_core -> radio_legacy -> duc_chain -> cordic_z24 ? If so, I see constants for 24 bit wide phase ( localparam c00…..c23) , do I have to change the values of these constants to form the desired chirp? Is there any guide or examples on how to use the cordic for this FPGA to form a chirp? I would then stream a constant sample value to the USRP in operation which would set the amplitude of my generated Chirp. By streaming a constant sample value to USRP, do you mean by using the UHD to input constant values? If I wanted to make this slightly more complicated to offer programability of the generated Chirp without rebuilding the FPGA, then I would repurpose the incoming sample stream to drive the programable aspects of my phase accumulator, and hard code the amplitude to a constant value. This way I would avoid having to write any host side software to control custom programming registers in the USRP. Do I still have to use the cordic to generate the chirp? There’s no way I can use the Xilinx DDS Coregen to get this working right? From: Ian Buckley [mailto:[email protected]] Sent: Thursday, 3 May 2018 4:12 AM To: Yeo Jin Kuang Alvin (IA) Cc: Derek Kozel; [email protected] Subject: Re: [USRP-users] B210 FPGA Code Yeo Jin Kuang Alvin, In reply to your original question the data passing over the GPIF interface is packetized data; It contains sample data and control/status data with protocol overhead. It is 32bits due to the design constraints of the FX3. It is transformed to 64bits in the FPGA for maximum code reuse of the same Ettus FPGA code used in all products. The data passing through tx_codec_d is raw (real time) sample data. In answer to your other questions: You are free to discard all the sample data sent over the GPIF interface from the host *ONCE* it has been de-packetized and turned into a raw sample stream…..this is because UHD running on the host will expect to see ACK style protocol communication with the USRP and this is generated by the logic that produces the raw sample stream form the packet stream. You are free to insert whatever new DSP logic you wish inside the DSP but you *must* produce one complex sample output every DSP clock cycle towards the DAC. For the DDS to function in it’s intended purpose, to provide digital frequency translation of your baseband signal before it is sent to the DAC, then yes, it must run at the master clock rate. Now if I were set the same design problem as you, to produce a H/W generated Chirp from a B210 here’s what I might do to generate the least possible amount of design work for myself. I would leave everything as-is in the USRP *except* for the logic the describes the phase accumulator to the DDS (CORDIC). I would replace this logic with logic that generates the desired Chirp response using the CORDIC. I would then stream a constant sample value to the USRP in operation which would set the amplitude of my generated Chirp. If I wanted to make this slightly more complicated to offer programability of the generated Chirp without rebuilding the FPGA, then I would repurpose the incoming sample stream to drive the programable aspects of my phase accumulator, and hard code the amplitude to a constant value. This way I would avoid having to write any host side software to control custom programming registers in the USRP. YMMV, remember this is a suggestion, custom changes to the FPGA don’t have any support. -Ian On May 2, 2018, at 2:14 AM, Yeo Jin Kuang Alvin (IA) via USRP-users <[email protected]<mailto:[email protected]>> wrote: Hi, Thanks for the reply! If lets say I would like to bypass all these from the GPIF_D to the tx_codec_d and implement my own signal to the tx_codec_d straight, will I get the same output? Output going into DAC is the same as output transmitting out from DAC. Second question is, must the clock rate of the DDS in the FPGA be the same as the master_clock_rate? Thank you in advance! From: Derek Kozel [mailto:[email protected]] Sent: Thursday, 26 April 2018 6:39 PM To: Yeo Jin Kuang Alvin (IA) Cc: [email protected]<mailto:[email protected]> Subject: Re: [USRP-users] B210 FPGA Code Hello Yeo Jin Kuang Alvin, I am not Ettus' expert in the B210 FPGA, but it would be highly unusual if there were arbitrary bit width changes. I believe that the GPIF bus is 16 bits of I and Q in parallel. The FX3 GPIF bus definition is included in the source and you can use Cypress's tools to look at the configuration of the bus in addition to the FPGA source code. There is considerable DSP implemented in the FPGA, including the decimation, interpolation, and frequency shifting operations. At minimum you would have to make changes to the UHD driver to remove support for those features if you bypass them. My apologies if I've missed this in another email, but what is your goal with these changes? Regards, Derek On Thu, Apr 26, 2018 at 10:18 AM, Yeo Jin Kuang Alvin (IA) via USRP-users <[email protected]<mailto:[email protected]>> wrote: Hi everyone! For the FPGA source code written for b210, I noticed that the input to the GPIF_D that is 32 bits, and then in went through some FIFOs up converting to 64 bits and then down to 12 bits output (tx_codec_d). May I know what is the purpose of up converting and then down convert again? Will it affect anything if I remove all these and just connect GPIF_D (32 bits) input and take 12 bits MSB (truncation) and connect directly to tx_codec_d (12 bits) ? Thanks in advance! _______________________________________________ USRP-users mailing list [email protected]<mailto:[email protected]> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com _______________________________________________ USRP-users mailing list [email protected]<mailto:[email protected]> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
