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 > <usrp-users@lists.ettus.com> 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:derek.ko...@ettus.com > <mailto:derek.ko...@ettus.com>] > Sent: Thursday, 26 April 2018 6:39 PM > To: Yeo Jin Kuang Alvin (IA) > Cc: usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com> > 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 > <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> 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 > 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
