Re: [Discuss-gnuradio] FPGA in USRP

[Brian Padalino]

On 6/14/07, S Mande <address@hidden> wrote:
> Hi All,
>
>  I have worked with VHDL for 3 years and would want to make use my knowledge
> to do some research in Software defined Radio.
>
>  I have a very different problem from most of the other postings. I am
> actually looking for a 'problem'.
>
>  For the past one month I have been Googling to see the research
> problems/constraints of USRP's. There were many different implementation
> ideas (of software defined radio's)on the web. But, most of these ideas are
> in general (.i.e. different ways to implement software defined radio) and
> not related to implementation on USRP. I was looking for research topics
> related to USRP. --> But, I didn't find a specific answer as to how FPGA's
> power could be harnessed to make USRP a more powerful tool. <--
>
>  I request you members to give your inputs as to what you would want to do
> with the existing Altera's Cyclone FPGA on USRP, to make USRP a more
> powerful tool!

For all open tickets for the USRP you can check this page:
 
http://www.gnuradio.org/trac/query?status=new&status=assigned&status=reopened&component=usrp&order=priority

The inband signaling is already being worked on by Thibaud within the
FPGA.  You can check the inband_lib directory under the usrp/fpga
directory for what he already has working.

There have been a lot of people who want easier access to the digital
IO pins on the daughtercards.

I think Automatic Gain Control within the hardware would probably be a
very good way to figure things out, but I am not sure how daughtercard
dependent that might be.  Matt would have a better idea of the
specifics of how that might want to get done in a generic way.

There have also been a number of people who would like to perform FFTs
within the FPGA instead of bringing the sample stream.  Being able to
mux functionality might be fun, but there probably isn't enough
resources for all of that within the original USRP board.

Moreover, you could always grep for TODO within the Verilog source to
see what features might have to be revisited for optimization.  I
believe the CIC filters are not optimized and can possibly release
maybe 10% of resources if they are optimized.

Obviously other people should chime in as well!  Those are just the
things I can think of off the top of my head.

Brian