Forum: GNU Radio Modifying the USRP FPGA core

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Mark Porter (Guest)
on 2009-05-21 17:43
(Received via mailing list)
Hi,

Since the USB data rate is the limiting factor in my current setup I
figured
I would implement some functions on the FPGA itself since they are
likely to
be simple to implement. I have loaded the project in Quartus and have
been
looking at the Schematic for some time. I already figured I have to
configure with a reduced number of RX, TX channels to free up some FPGA
resources.

I was wondering where to put my extra logic in this diagram. To be more
precise, the logic will only be affecting the RX side and I don't mind
the
16-bit values coming out of USB, as long as it's processed with my
logic.

I was thinking about putting the logic between the rx_chain blocks and
the
rx_buffer i.e. taking the I and Q values coming out of the DDCs and
adding
an extra block to do my transformations. I am assuming the rx_buffer
only
takes the values presented to it and shifts them out USB according to
the
multi-channel scrambling *e.g.* I0, Q0, I1, Q1, etc.

Could you confirm/infirm that my proposed design is valid ? Will the
extra
block delay affect the functioning of the system ?

Thank you,
Philip B. (Guest)
on 2009-05-22 18:36
(Received via mailing list)
Mark Porter wrote:
> precise, the logic will only be affecting the RX side and I don't mind the
> 16-bit values coming out of USB, as long as it's processed with my logic.
>
> I was thinking about putting the logic between the rx_chain blocks and the
> rx_buffer i.e. taking the I and Q values coming out of the DDCs and adding
> an extra block to do my transformations. I am assuming the rx_buffer only
> takes the values presented to it and shifts them out USB according to the
> multi-channel scrambling *e.g.* I0, Q0, I1, Q1, etc.
>
> Could you confirm/infirm that my proposed design is valid ? Will the extra
> block delay affect the functioning of the system ?

Looking at:

http://gnuradio.org/trac/browser/gnuradio/trunk/us...

suggests that changing those assign statements to something like

user_processing(bb_rx_i0, bb_rx_q0, ch0rx, ch1tx)

and insert your code in user_processing.

You've already seen the resource limitations in the USRP1.

Philip
This topic is locked and can not be replied to.